The ongoing npm supply chain attacks have claimed another victim. The popular 'is' package, a fundamental type-checking utility in the JavaScript ecosystem, was compromised after attackers successfully phished and hijacked an old maintainer's account. This incident represents an escalation in the phishing campaign that previously compromised eslint-config-prettier and several other widely-used packages.

The Attack Timeline

On July 19, 2025, malicious versions of the 'is' package were published to npm, including versions 3.3.1 and 5.0.0. This attack was part of the ongoing phishing campaign targeting npm maintainers. However, the attack vector was particularly cunning: the threat actors first compromised an old maintainer of the package through phishing, then manipulated npm's ownership system to gain control.

Jordan Harband, a prominent JavaScript maintainer who oversees hundreds of npm packages, revealed how he was inadvertently drawn into the attack.

Jordan Harband's Account of the Attack

The details of how this compromise occurred are particularly concerning. Jordan Harband shared his experience on Bluesky:

‍

The attack unfolded through a sophisticated deception:

1. The original maintainer's npm account was hijacked (likely through the ongoing phishing campaign)
2. This maintainer was removed from the 'is' package on npm
3. The hijacked account owner contacted the current maintainer. team via email, claiming npm had removed them due to not having 2FA enabled
4. The old maintainer was re-added to the account
5. The next morning, the attackers used this restored access to publish malicious versions 3.3.1 and 5.0.0

As the maintainer noted in follow-up posts, the malicious code went unnoticed for six hours - longer than usual. The attackers managed to publish both version 3.3.1 and later version 5.0.0, likely using a pre-existing session.

‍

This multi-stage attack expertly exploited the trust between maintainers and the lack of proper notifications in npm's ownership system.

The Human Factor in Supply Chain Security

This incident highlights a critical vulnerability in open source maintenance: the human element. The attackers didn't need to compromise technical systems or find zero-day vulnerabilities. Instead, they:

1. Used phishing to hijack the original maintainer's npm account
2. Created a believable story about npm removing the account due to lack of 2FA
3. Leveraged the trust between maintainers to regain package access

The sophisticated nature of this attack demonstrates:

• Attackers' deep understanding of npm's governance model and maintainer relationships
• Exploitation of legitimate grievances about npm's notification systems
• The effectiveness of social engineering even against experienced maintainers
• How personal responsibilities (like volunteering at a swim meet) can delay detection of attacks

Immediate Actions for Developers

If you have the 'is' package in your dependencies:

Check your package versions immediately

1. Affected versions: 3.3.1 and 5.0.0
2. Run npm ls is to check your installed version

Remediate if compromised

1. Remove node_modules entirely
2. Clear npm cache: npm cache clean --force
3. Update package-lock.json to exclude malicious versions
4. Reinstall dependencies with safe versions (3.3.0 or 3.3.2+)

Audit your environment

1. Check for unauthorized network connections
2. Review browser security settings (Chrome users should check for security warnings)
3. Rotate all npm tokens and credentials
4. Consider full system reinstallation if compromise is suspected

For StepSecurity Enterprise Customers

The following steps are applicable only for StepSecurity enterprise customers. If you are not an existing enterprise customer, you can start our 14 day free trial by installing the StepSecurity GitHub App to complete the following recovery step.

Discover Pull Requests upgrading to compromised npm packages

We have added a new control specifically to detect pull requests that upgraded to these compromised packages. You can find the new control on the StepSecurity dashboard.

Use StepSecurity Artifact Monitor to detect software releases outside of authorized pipelines

StepSecurity Artifact Monitor provides real-time detection of unauthorized package releases by continuously monitoring your artifacts across package registries. This tool would have flagged the eslint-config-prettier incident by detecting that version 9.1.1 was published outside of the project's authorized CI/CD pipeline. The monitor tracks release patterns, verifies provenance, and alerts teams when packages are published through unusual channels or from unexpected locations. By implementing Artifact Monitor, organizations can catch supply chain compromises within minutes rather than hours or days, significantly reducing the window of exposure to malicious packages.

Learn more about implementing Artifact Monitor in your security workflow at StepSecurity Artifact Monitor

Use StepSecurity Harden-Runner to detect compromised dependencies in CI/CD

StepSecurity Harden-Runner adds runtime security monitoring to your GitHub Actions workflows, providing visibility into network calls, file system changes, and process executions during CI/CD runs. In cases like the eslint-config-prettier compromise, Harden-Runner would detect and alert on suspicious behavior such as unexpected network connections to malicious domains or unauthorized file modifications during the build process. The tool creates an audit trail of all activities within your workflows, enabling rapid forensic analysis when investigating potential security incidents. By hardening your CI/CD pipelines with runtime monitoring, you can prevent compromised dependencies from executing malicious code in your build environment. The following screenshot shows how Harden-Runner detected the tj-actions supply chain incident.

Implement Harden-Runner in your workflows by following this guide

‍

The Broader Impact

The 'is' package is not just another npm module - it's a fundamental utility used across the JavaScript ecosystem. Its compromise potentially affects thousands of projects and millions of installations. The attack demonstrates how targeting foundational packages can create massive blast radius effects in modern software supply chains.

Looking Forward

As these attacks continue to evolve, the JavaScript community must adapt its security practices. The attackers are exploiting the trust-based relationships that make open source collaboration possible.

The npm ecosystem needs:

• Better notification systems for ownership changes
• Enhanced verification processes for maintainer additions
• Improved anomaly detection for package publications
• Stronger default security configurations

Until these systemic improvements are implemented, every developer and organization using npm packages must remain vigilant and implement defense-in-depth strategies to protect their software supply chains.

For ongoing updates about this and related supply chain security incidents, follow our blog.