npm incorrectly applied security-holder metadata to multiple one-character packages, including letters, numbers, and the - package.

Socket reviewed public npm registry metadata and found several affected packages had been assigned 0.0.1-security or 0.0.1-security.0 versions, with the latest dist-tag moved to the security placeholder. Older package versions remained available.

npm confirmed the markings were not intentional and that they are working on rolling it back.

“This happened due to a bug in our tooling and was a mistake. We are looking into it,” an npm representative said in response to Socket’s inquiry.

npm also shared a list of affected package names, which included:

• c
• r
• w
• - (the package exists in the registry, but its npm package page is currently inaccessible due to a bug in npm’s website)
• m
• p
• i
• n
• 3
• 2
• x
• 6
• 4

The affected packages showed the same general pattern: npm added a security-holder-style version and moved latest to that placeholder, while older versions remained present in the registry.

That made the incident look unusual. The 0.0.1-security convention is typically associated with packages npm has taken over or reserved for security reasons, often after a package is removed or replaced.

In this case, npm said the change was caused by a tooling bug.

No Public Evidence of Package Compromise#

Socket did not find public evidence, based on registry metadata alone, that the affected one-character packages had been compromised.

The registry changes appeared to be metadata-level changes made across multiple package names, rather than malicious updates published by package maintainers. The affected names included long-standing short packages and package names made up of a single number or symbol.

Older versions remaining available was another signal that this did not look like a standard malicious-package removal.

What Developers Should Check#

Teams that depend on any of the affected packages should check whether their lockfiles captured a placeholder version during the affected window.

Look for 0.0.1-security or 0.0.1-security.0 in:

• package-lock.json
• yarn.lock
• pnpm-lock.yaml
• other package manager lockfiles

The practical impact appears limited, but developers who installed any affected packages during the window may want to verify that their dependency manager resolved the intended version rather than the temporary security placeholder.

This incident was caused by an npm tooling bug, not a confirmed compromise of the affected packages.

But registry metadata still affects the software supply chain. Dist-tags determine what package managers install by default, and security-holder versions are treated as a strong warning signal by developers and security tools.

When that metadata is applied incorrectly, it can create confusion even when package code has not changed. We will update this post as we learn more about the cause and resolution of this bug.

Update, June 9, 2026, 21:21 UTC: npm has confirmed “These packages versions have been fixed now.” The affected one-character packages no longer appear to be marked as security holders.