OSV withdrew 157 malware reports after automated detections incorrectly marked trusted npm and PyPI packages as malicious. The important part is the path: bad records entered a public vulnerability database, then reached tools that consume OSV data for scanning, policy, SBOMs, registry checks, and CI/CD gates.
What happened#
OSV, the OpenSSF-backed vulnerability database, withdrew 157 malicious-package reports on May 26 after false positives hit packages in the npm and PyPI ecosystems.
The rollback happened in OpenSSF’s repository for OSV-format malware records. According to Socket, the pull request began as a withdrawal for a FastAPI 0.136.3 report, then expanded into a larger cleanup across npm and PyPI. The final rollback left 157 OSV reports withdrawn.
The affected set was not limited to obscure packages. Socket names FastAPI and @tanstack/start-storage-context, along with a broader tail of MCP servers, AI tools, CLI packages, framework forks, component libraries, and API clients.
That matters because OSV is not just a website where researchers read advisories. Its structured records are meant to be consumed automatically. Security scanners, dashboards, policy engines, SBOM tools, registry controls, and CI/CD systems can all treat OSV data as input. If the record says “malware,” a downstream tool may stop a build before a human has checked whether the label is correct.
The FastAPI case shows the weak point#
The FastAPI record was titled as malicious code in the PyPI package and attributed the report to Amazon Inspector, according to Socket. The claim centered on an added undocumented dependency or optional dependency group that looked suspicious to the detection system.
The record reportedly framed the dependency as “typosquat-shaped” and possible evidence of dependency confusion or namespace abuse.
That is a signal worth checking. It is not, by itself, proof of malware.
Socket notes that the withdrawn record did not identify a malicious payload in FastAPI. It did not point to install-time execution, credential theft, command-and-control behavior, exfiltration, or attacker infrastructure. On the available facts, the jump from suspicious dependency metadata to a public malicious-code record was the failure.
This is the core lesson. Automated systems can be good at finding anomalies. They are worse at deciding when an anomaly deserves a malware label that will propagate through enforcement tooling.
Amazon Inspector appears central, but attribution is messy#
Many of the withdrawn JSON records point to Amazon Inspector, AWS’s automated vulnerability management service. Socket reports that OpenSSF added Amazon Inspector as an automated source for the repository in October 2025, with authentication to an OpenSSF-controlled AWS role that could ingest malicious-package reports from an Amazon Inspector bucket.
That created a path from automated Amazon Inspector reports into OSV-format malware records.
In the rollback discussion, Chi Tran wrote: “We have paused our automation and taking actions.” That line is short, but it says enough. The automated path was paused after the false positives were identified.
Attribution should not be flattened beyond the source. Socket says FastAPI’s withdrawn record credited Amazon Inspector as the finder and listed it as the source for version 0.136.3. But not all 157 records were uniformly attributed. Some appear cleanly tied to Amazon Inspector. Others preserve older origins from prior confirmed compromises or other reporting sources, then include newer disputed entries.
@tanstack/start-storage-context is one of those mixed cases in Socket’s reporting. The package had earlier compromise context, while the disputed 1.167.4 version was part of the May 26 false-positive cleanup. That distinction matters. A package can have real historical compromise context and still receive a false positive for a later version.
Malware labels are operationally heavier than CVEs#
A false vulnerability advisory is annoying. A false malware advisory can become an incident.
Most vulnerability alerts can be triaged against version ranges, severity, reachability, exposure, and deployment context. Teams may decide to patch, defer, suppress, or document why the alert is not relevant.
A malware alert lands differently. It suggests active compromise. It can trigger package removal, emergency reviews, credential-rotation discussions, incident-response workflows, and questions to maintainers before the underlying claim has been verified.
That is why this rollback was more than a metadata cleanup. If a CI gate or dependency policy engine treated the OSV record as authoritative, a trusted package could be blocked. If a dashboard surfaced it to security teams, maintainers could be forced to prove a negative: that their release was not malicious after the public record had already said it was.
The automation did not just misclassify packages. It shifted work onto maintainers and consumers downstream.
What security teams should check#
Teams that consume OSV data directly or through scanners should check whether any alerts from May 26 were tied to the withdrawn reports.
Practical checks:
- Review CI/CD failures or dependency blocks around May 26 involving npm or PyPI malware records.
- Reconcile any “malicious package” findings against the current OSV record state, not cached scanner output.
- Check whether internal policy engines treat OSV malware reports as automatic deny rules.
- Separate true compromise history from disputed version-specific reports, especially for packages with mixed attribution.
- Look for suppressions or emergency exceptions created during the false-positive window and clean them up if no longer valid.
The goal is not to distrust OSV. OSV is useful because it is open, structured, and easy to integrate. The same properties make bad records move fast.
What not to overclaim#
This incident does not show that the named packages were compromised. Socket’s reporting says the records were withdrawn as false positives.
It also does not prove that automated malware detection is useless. Suspicious dependency changes, typosquat-like naming, and namespace confusion patterns can be meaningful signals. The problem is promotion. A signal became a public malware record without enough validation for the operational weight that label carries.
The better standard is straightforward: automated detections can enter a review queue quickly, but public malware records that feed enforcement systems need stronger evidence, clearer attribution, and a correction path that works at the same speed as propagation.
Open security data is infrastructure now. Its failure mode is no longer just a bad advisory page. It is a blocked build, a paged responder, and a maintainer explaining why a trusted release was never malware in the first place.