Google's OSV Fix Just Added 500 New Advisories – All Thanks to One Small Policy

Google’s Open Source Vulnerabilities (OSV) database recently added 500–600 new advisories, not because of a sudden flood of new vulnerabilities, but because of a simple policy change. The fix came after I re-flagged a longstanding issue to the OSV maintainers during an OpenSSF Vulnerability Disclosures Working Group call on August 28th, 2025, and separately in a GitHub issue filed September 22nd, 2025.

Previously, any CVE marked as “disputed” in upstream data was being treated by OSV as “withdrawn.” “Disputed,” however, doesn’t mean “safe.” Rather, it means the vendor disagreed. By treating a disputed CVE as withdrawn, the policy effectively erased the vulnerability from anyone relying on OSV's data feed. Many of these vulnerabilities were, therefore, legitimate and potentially even exploited.

How the Problem Came to Light#

This issue became particularly visible during the fallout from CVE-2023-48022, a disputed but actively exploited vulnerability in Anyscale’s Ray, a distributed compute engine for AI workloads with nearly 39,000 GitHub stars.

Oligo Security reported that Ray’s lack of authentication on its job submission API could allow remote code execution. Anyscale disagreed, calling it a “design decision” and marking the CVE as disputed:

Attackers didn’t care about that nuance. They used the flaw to deploy cryptominers, steal credentials, and compromise cloud workloads, attacks Oligo detailed in their “ShadowRay” report.

Although the vulnerability was being actively exploited, OSV’s data feed marked it as withdrawn, effectively suppressing it. However, VulnCheck’s Known Exploited Vulnerabilities (KEV) list flagged this vulnerability on their KEV list on August 24th, 2024.

The US Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) list does not currently flag CVE-2023-48022. This is because CISA’s KEV only adds “known exploited vulnerabilities to the catalog when there is a clear action for the affected organization to take.” In this case, since the vendor, Anyscale, has not issued a patch, CISA’s KEV does not flag this vulnerability.

That discrepancy, invisible in two trusted databases but highlighted in another, is what prompted me to raise the issue directly with the OSV maintainers.

This case, already publicly documented through Oligo’s 'ShadowRay' report and Anyscale’s public response, illustrates how the “disputed” label can obscure real exploitation when data pipelines misinterpret it. It’s likely that many similar cases have gone unseen due to how disputed records were previously handled.

OSV Maintainers Agreed to Stop Treating Disputed CVEs as Withdrawn#

During the August 28th, 2025, discussion with the OSV team, including Andrew Pollock, formerly of Google's Open Source Security Team (GOSST) and the implementor of OSV's NVD CVE conversion, explained that the conversion process had historically treated disputed vulnerabilities as withdrawn when converting data from the NVD feed, for biasing against false positives.

I pushed back on that logic. Given how CVE-2023-48022 was actively exploited, classifying disputed vulnerabilities as withdrawn actively excluded valuable security information from the ecosystem. OSV’s mission isn’t limited to tracking vulnerabilities that can be fixed with a patch; it’s about providing an accurate record of risk across open source.

The OSV maintainers agreed. They recognized that passing through the disputed tag, rather than filtering it out, was the better approach. Removing disputed CVEs, as had been done in the past, risked alienating both security researchers and downstream users who rely on OSV's data for accurate visibility.

Andrew also acknowledged that the previous handling stemmed from a mix-up between disputed and rejected CVEs, which ultimately led to the bug in OSV’s conversion logic.

The Fix and Its Ripple Effect#

After that discussion, Google’s OSV team corrected the mapping logic. Disputed CVEs now appear as valid entries, no longer suppressed. The one line fix restored visibility to more than 500 vulnerabilities across the ecosystem.

But OSV wasn’t the only database affected. Socket consumes vulnerability data from GitHub’s advisory feed. Once I realized GitHub had the same issue, I submitted a pull request to fix the entry for CVE-2023-48022 (GHSA-6wgj-66m2-xxp2) as well. That update ensured Socket users would correctly see the critical Ray CVE flagged in our own dataset as well.

You can see it live on Socket’s Ray package page.

The Real-World Impact of a Simple Policy Mistake#

This policy change highlights how fragile our vulnerability intelligence pipelines can be. A single label misinterpretation, such as “disputed” → “withdrawn,” can cascade into widespread data suppression across multiple databases and ecosystems.

CVE-2023-48022 is the perfect example:

• The vendor disputed it.
• OSV (and GitHub’s feed) hid it.
• Attackers exploited it anyway.
• And downstream tools relying on those feeds never saw it coming.

“There are so many nuances related to CVE’s,” Patrick Garrity of VulnCheck commented on the discussion about OSV’s policy change. “The only criteria we have to add to VulnCheck KEV is that it has a CVE ID. It doesn't have to be published either which is one of the reasons we became a CNA.”

“Many vendors appear to respond in fear and attempt to sweep things under the rug when exploitation evidence surfaces, rather than disclose and inform their customers and the industry.”

As open source projects and registries increasingly depend on OSV, these subtle data-handling issues have real-world consequences. Maintainers, developers, and security teams might assume their dependency trees are clean when in fact, they’re just missing data.

Sources:

• OSV Issue #4007
• Anyscale: Update on Ray CVEs
• Oligo: ShadowRay Attack Campaign
• Oligo: 0.0.0.0 Day Exploit
• GitHub Advisory Database PR #6219
• Socket.dev Ray Package Page

Subscribe to our newsletter

Get notified when we publish new security blog posts!