OSV, the OpenSSF-backed vulnerability database, withdrew 157 malicious-package reports on May 26 after automated detections incorrectly flagged npm and PyPI packages as malware, pushing bad records for trusted projects into OSV-consuming security tools and CI/CD systems.

The rollback happened in OpenSSF’s malicious-packages repository, where OSV-format records for malicious packages are maintained. A PR titled “Withdraw FastAPI v0.136.3 and other FPs reports,” began with a false-positive withdrawal for FastAPI 0.136.3, then expanded into a much larger cleanup across npm and PyPI. The final commit changed one still-active record under osv/malicious and moved the rest into osv/withdrawn, leaving 157 withdrawn OSV reports in the rollback.

The withdrawn records spanned both npm and PyPI ecosystems, including FastAPI, Strawberry GraphQL, @tanstack/start-storage-context, @nx/key, @ctrl/plex, rdflib, qontract-reconcile, massive, notebook-intelligence, pulumi-vcd, art-template, and a long tail of MCP servers, AI tools, CLI packages, framework forks, component libraries, and API clients. Follow-on commits throughout May 26 expanded the cleanup to additional false-positive reports across the same clusters, along with many smaller packages.

These were not harmless metadata edits. OSV records feed scanners, dashboards, policy engines, SBOM tooling, registry controls, and CI/CD gates. A bad malware record in that path can stop builds, trigger incident response, and force maintainers to show their projects were not compromised after the alert has already propagated.

FastAPI Flagged for Suspicious Dependency#

The withdrawn OSV record, MAL-2026-4750, described FastAPI’s fastapi0.136.3 as “Malicious code in fastapi (PyPI)” and attributed the report to Amazon Inspector. The record claimed the release added an undocumented dependency, fastar>=0.9.0, to FastAPI’s standard optional dependency group. It framed fastar as “typosquat-shaped” and described the dependency as a possible dependency-confusion or namespace-abuse vector.

The 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. Without verifying with maintainers of the popular project, the suspicious-looking dependency change was promoted into a malicious-code record.

Amazon Inspector Reports Drove the False Positives#

Many of the withdrawn JSON records point to Amazon Inspector, AWS’s automated vulnerability management service. OpenSSF added Amazon Inspector as an automated source for its malicious-packages repository in October 2025, setting up authentication to an OpenSSF-controlled AWS role that could ingest malicious-package reports from an Amazon Inspector bucket.

That path put automated Amazon Inspector reports into OSV-format malware records. In the PR for the rollbacks, Chi Tran wrote: “We have paused our automation and taking actions.”

This incident shows how that reporting path can push unvalidated detections into public package intelligence. FastAPI’s withdrawn record credits Amazon Inspector as the finder and lists amazon-inspector as the source for version 0.136.3, but the attribution is not uniform across all 157 reports. Some records appear cleanly Amazon Inspector-attributed. Others are mixed because they preserve older origins from prior confirmed compromises or other reporting sources alongside newer Amazon Inspector-origin entries. @tanstack/start-storage-context is one of the mixed cases: the package had earlier compromise context, while the disputed 1.167.4 version was part of the May 26 false-positive cleanup.

False Positives Hit Build Pipelines#

OSV has become a valuable data source because it is open, structured, and easy to consume. That is also what makes bad records propagate quickly through dependency scanners, CI checks, registry controls, SBOM tools, dashboards, and internal policy systems.

When those tools treat OSV as an enforcement source, a false malware report can block builds or deployments before maintainers have a chance to correct the record. Malware reports also carry a different operational weight than ordinary vulnerability advisories. A vulnerability alert can often be triaged by version range, severity, reachability, and deployment context. A malware alert is more likely to trigger emergency review, package removal, credential-rotation discussions, or incident-response workflows.

That made the May 26 rollback disruptive for maintainers and consumers. Packages were flagged as malicious, downstream tools surfaced the records, and maintainers had to manually verify releases that were later cleared.