On 12 July 2018, an attacker took over the npm account of an ESLint maintainer and published malicious versions of two packages, eslint-config-eslint 5.0.2 and eslint-scope 3.7.2. eslint-scope was a dependency of older ESLint versions and of the latest babel-eslint and webpack at the time. Its new version ran a postinstall script that downloaded code from Pastebin and sent the contents of each installer's .npmrc file, where npm publishing tokens are usually kept, to the attacker. According to ESLint's postmortem, the maintainer had reused their npm password on other sites and had no two-factor authentication, and the attacker generated a fresh npm token to publish. The malicious version was live for about two hours before npm removed it. npm said access tokens for about 4,500 accounts could have been obtained, revoked all tokens created before a cut-off that day, and said it had found no evidence that any were obtained or used.
Key takeaways
- The attacker logged in to an ESLint maintainer's npm account with a password the maintainer had reused elsewhere, generated an npm token and published two malicious package versions, according to ESLint's postmortem.
- The payload targeted machine credentials: it read the
.npmrcfile on every machine that installed eslint-scope 3.7.2 and sent the npm tokens in it to the attacker. - npm said tokens for approximately 4,500 accounts could have been obtained and revoked every token issued before a cut-off on 12 July, causing load problems on npmjs.com while it did so.
- npm said it found no evidence that any tokens were actually obtained or used. The two malicious versions were unpublished the same day.
- The identity lesson: one maintainer's password can mint a publishing token, and a publishing token can harvest thousands more, so registry accounts need strong authentication and short-lived tokens.
At a glance
| Organisations | ESLint project; npm, Inc. (registry operator); users of eslint-scope, babel-eslint and webpack |
|---|---|
| When | 12 July 2018, from 09:49 UTC (first malicious publish) to 12:37 UTC (eslint-scope 3.7.2 removed); token revocation the same evening |
| Attacker | Unknown |
| Entry point | An ESLint maintainer's npm account, accessed with a password reused on other sites and not protected by two-factor authentication |
| Identities abused | An npm authentication token the attacker generated in the maintainer's account; npm publishing tokens targeted in installers' .npmrc files |
| Impact | Malicious eslint-scope 3.7.2 and eslint-config-eslint 5.0.2 published; tokens for about 4,500 accounts potentially exposed and all tokens issued before the cut-off revoked; no evidence of stolen tokens being used, according to npm |
| Category | NHI. Incident class: confirmed NHI breach (publishing token created from a hijacked account and used to ship a token stealer) |
What happened
ESLint's postmortem, published the same day, sets out the chain. "The maintainer whose account was compromised had reused their npm password on several other sites", and the account did not have two-factor authentication. The ESLint team believes the attacker obtained the email address and password from a breach at another site. Early on 12 July the attacker generated an authentication token in the account. At 09:49 UTC they published eslint-config-eslint 5.0.2, an internal configuration package with little outside use, containing a malicious postinstall script. They unpublished it at 10:25 and, at 10:40, published eslint-scope 3.7.2 with the same script.
The script downloaded further code from pastebin.com and ran it. That code read the user's .npmrc file, which typically holds the token used to publish packages, and sent it to the attacker. A user reported the problem on the eslint-scope issue tracker at 11:17 UTC. "The published code seems to steal npm credentials," ESLint's Kevin Partington told BleepingComputer. The Pastebin link was taken down at 12:27, and npm unpublished eslint-scope 3.7.2 at 12:37 after an ESLint maintainer contacted them. At 17:41 ESLint published eslint-scope 3.7.3 containing the code of the clean 3.7.1, so that caches would pick up a safe version.
npm's status page said "the vector for this compromise was stolen credentials from one of the authorized publishers". Because anyone who installed the malicious version could have lost their own publishing token, npm invalidated every token created before a cut-off on 12 July, then reported that the mass invalidation had caused load problems on npmjs.com. In its incident report, npm said "access tokens for approximately 4,500 accounts could have been obtained" before it closed the window, and that "we have not found evidence that any tokens were actually obtained or used to access any npmjs.com account during this window." npm's chief technology officer, C.J. Silverio, stressed to BleepingComputer that "This morning's incident did not happen because of an npmjs.com breach".
ESLint apologised: "We, the ESLint team, are sorry for allowing this to happen." Its recommendations included not reusing passwords, enabling npm two-factor authentication, auditing who can publish, taking care with services that auto-merge dependency upgrades, and using lockfiles to prevent unexpected installs.
Timeline
| Date | Event |
|---|---|
| 12 July 2018 | Early morning: the attacker logs in to the maintainer's npm account and generates an authentication token. |
| 12 July 2018 | 09:49 UTC: malicious eslint-config-eslint 5.0.2 published; it is unpublished at 10:25. |
| 12 July 2018 | 10:40 UTC: malicious eslint-scope 3.7.2 published; a user reports it at 11:17. |
| 12 July 2018 | 12:27 to 12:37 UTC: the Pastebin payload is taken down and npm unpublishes eslint-scope 3.7.2. |
| 12 July 2018 | Afternoon and evening: ESLint publishes its postmortem and a clean 3.7.3; npm revokes all tokens issued before its cut-off. |
| 18 July 2018 | G DATA reports that about 4,500 accounts had to re-authenticate. |
How it happened: the identity attack path
- Reused password. The maintainer's npm password had been reused on other sites, and ESLint believes it came from a third-party breach.
- No second factor. The npm account had no two-factor authentication, so the password alone was enough to log in.
- Token minted. The attacker generated a new npm authentication token, a machine credential that could publish without further checks.
- Malicious publish. The token was used to publish eslint-config-eslint 5.0.2 and eslint-scope 3.7.2 with a postinstall script.
- Token harvesting. Every install ran the script, which sent the installer's
.npmrcnpm token to the attacker, creating a path to compromise further packages. - Registry-wide revocation. npm removed the package and revoked all tokens issued before the cut-off, closing the window on any tokens that had been stolen.
Impact
- Confirmed: two malicious package versions published from a hijacked maintainer account, one of them a dependency of widely used tools, for about two hours in the case of eslint-scope 3.7.2.
- Potential: npm said tokens for approximately 4,500 accounts could have been obtained, which could have let the attacker publish malicious versions of other packages.
- Not found: npm said it had no evidence that any tokens were actually obtained or used to access npmjs.com accounts.
- Disruption: every npm user with a token issued before the cut-off had to re-authenticate and regenerate tokens used in build systems.
What this means for NHI governance
The eslint-scope incident is an early, clear case of the publishing-token chain that drives many later package registry attacks. A human password opened the account, but the damage depended on machine credentials at both ends: a newly minted token that could publish without a second factor, and the tokens stored in plain text on developer and CI machines that the payload set out to collect. Each stolen publishing token is a potential next victim, which is why npm had to revoke tokens across the whole registry rather than for one account.
The same approach has been repeated at much larger scale since, most visibly by the Shai-Hulud npm worm in 2025, which stole publishing tokens and used them to spread automatically. The defences are the same: phishing-resistant MFA on registry accounts, short-lived or trusted-publishing credentials instead of long-lived tokens on disk, and the ability to revoke and reissue tokens quickly. See our CI/CD Pipeline Identity Security Guide and Token and Session Security Guide. Weeks later, Homebrew's GitHub token exposure showed the same risk in a build server.
Recommendations
- Enforce strong MFA on package registry accounts. Require two-factor authentication for login and for publishing, especially for maintainers of popular packages. See our MFA Guide.
- Replace long-lived publishing tokens with short-lived ones. Use trusted publishing from CI with workload identity where the registry supports it, and scope any remaining tokens to specific packages. See the CI/CD Pipeline Identity Security Guide.
- Keep tokens out of plain-text dotfiles on shared machines. Inject registry tokens at build time from a secrets manager instead of leaving them in
.npmrc. See our Secrets Management Guide. - Restrict install-time scripts. Disable or allowlist postinstall scripts in CI, and use lockfiles so new versions are not pulled in silently.
- Audit who can publish. Remove inactive maintainers and review publish rights regularly.
- Be ready to revoke at scale. Know how to rotate every registry token your organisation uses in one step. See the Leaked Credential Response Playbook.
Frequently asked questions
What happened with eslint-scope 3.7.2?
On 12 July 2018 an attacker used a hijacked ESLint maintainer's npm account to publish eslint-scope 3.7.2 with a postinstall script that sent the installer's npm token from their .npmrc file to the attacker. npm removed it about two hours after it was published.
How was the ESLint maintainer's npm account compromised?
According to ESLint, the maintainer had reused their npm password on several other sites and had not enabled two-factor authentication. The attacker logged in, generated an npm token and used it to publish the malicious versions.
Why did npm revoke everyone's tokens?
Anyone who installed the malicious version could have had their own npm token stolen. npm said tokens for about 4,500 accounts could have been obtained, so it invalidated every token created before a cut-off that day. It said it found no evidence that any tokens were actually obtained or used.
Related NHI Mgmt Group resources
Shai-Hulud npm Worm 2025 · Rspack npm compromise · Homebrew GitHub Token Exposure 2018 · CI/CD Pipeline Identity Security Guide · Token and Session Security Guide
How NHI Mgmt Group can help
Publishing tokens are some of the most powerful machine credentials a development team holds. We help organisations find where registry tokens live, move to short-lived publishing and set up the monitoring and revocation needed when a package is hijacked. See our NHI and AI agent security training.
References
- ESLint: Postmortem for Malicious Packages Published on July 12th, 2018 (12 July 2018)
- npm: Incident report: npm, Inc. operations incident of July 12, 2018 (12 July 2018)
- npm Status: Compromised version of eslint-scope published (12 July 2018)
- BleepingComputer: Compromised JavaScript Package Caught Stealing npm Credentials (12 July 2018)
- G DATA: Credential re-use: NPM JS revokes 4500 access tokens (18 July 2018)