14,090 Vulnerabilities in Two Months, and 99.4% of Them Have No CVE
Published on gastropod.io on 08-06-2026
14,090 Vulnerabilities in Two Months, and 99.4% of Them Have No CVE
Tags: vulnerability intelligence, software supply chain security, ai security, open source, dependency management, sbom
Palo Alto Networks Unit 42 published results on August 4 from an autonomous vulnerability research system it calls NOVA. In two months, NOVA analyzed 3,915 open source projects and confirmed 14,090 vulnerabilities. Of those, 99.4 percent had never been publicly reported. Under CVSS 4.0, 5,600 of them scored High or Critical. You can read the full writeup by following this link to the Unit 42 blog.
Just for a comparison, OSS-Fuzz launched in 2016 and took until August 2023 to help find more than 10,000 vulnerabilities across 1,000 projects. NOVA covered four times the projects and produced more findings in eight weeks.
Breaking the 14,090 down by type:
- Memory and calculation issues, the classic fuzzing territory: 557 findings, 4 percent
- Adding resource management and denial of service: 1,121 findings, 8 percent
- Everything else, 92 percent: semantic and logic flaws, specifically access control and authorization, path traversal, code injection, prototype pollution, and server-side request forgery
The 92 percent are the types that human reviewers then spend weeks triaging. To validate these NOVA built a working proof of concept for each candidate and replayed it in a clean environment before counting it.
By ecosystem, each language produced the flaws its style of code invites:
- C and C++: memory-safety and resource-management flaws
- JavaScript and TypeScript: code injection, prototype pollution, SSRF
- Go: path traversal and SSRF
- PHP, Java, and Python: access-control and authorization failures
How Unit 42 built it
NOVA runs multiple frontier models against the same codebase and keeps the union of what they find. In a controlled evaluation across 14 projects, the highest-volume model confirmed 235 vulnerabilities, 185 of which no other model found. The lowest-volume model confirmed 139, including 93 unique to it. Every model contributed findings the others missed, and the gap widened on larger codebases. Unit 42's design built an ensemble-of-models working together as their harness so rather than asking a model to find vulnerabilities, Unit 42 gave the agents a fixed procedure: map the architecture, find every point where outside input enters, locate the dangerous operations, then determine which paths connect the two. Separate agents scope the repository, generate ranked candidates, write proofs of concept, and replay them in a clean environment. A gatekeeper agent decides whether each finding gets published, archived, or sent back for another pass. No human reviews anything until the end.
The dependency math
Unit 42 separated out 5,421 findings with supply chain reach: 1,280 flaws in dependency packages, and 4,141 downstream exposures where an application's own code could reach a vulnerable dependency. For 2,776 of those downstream exposures, the pipeline proved exploitability from the consuming application with a working PoC rather than inferring it from an import graph.
Roughly 1,300 flaws in dependency packages generated more than 4,000 confirmed downstream exposures. That ratio is the entire argument for tracking where an artifact version is used rather than which projects you consider yours.
Check: Is anyone else is already using these?
Unit 42 checked all 14,090 findings against the public record. Only 85 matched something already published, and most of those public entries appeared two to eight weeks after NOVA had found the same flaw. Unit 42 reads that overlap as evidence that other organizations are running comparable scans independently. The same tooling is available to anyone willing to pay for inference. ($$$!)
And this type of threat is a bit asymmetric b/c attackers do not need expensive frontier models to benefit. The older models are great at reverse engineering a patch to build an exploit when you know what you are looking for. This is a well-automated task, and it gets easier as the patch volume grows.
The clock for time-to-patch is moving the wrong way
Dataminr's 2026 Mid-Year Cyber Threat Landscape Report, also released around Black Hat, puts median patching time at 43 days, up from 32. Attacker breakout time in the same period fell below 30 minutes. Palo Alto Networks cites an industry average of 55 days to deploy a traditional patch.
Consider these volumes against a discovery rate that has multiplied this year. Your remediation queue was designed around a CVE discovery and publishing rate from 2025 that no longer is grounded in reality and one of the largest constraints on fixing aa vulnerability is finding it in the first place. How long do you spend answering the question: Which builds, images, and services contain the affected version? For most companies that is a tough one to answer once in a while & now it is multiple times daily.
I wrote about this in another article "fastjson 1.x got CVE-2026-16723 with no patch available for the 1.x line", and again when "the OpenSSL HollowByte flaw shipped without a CVE at all" and most scanners missed it. Both were inventory problems dressed as vulnerability problems. The input volumes will only increase and the artifact inventory problem needs to be taken out of the equation.
Stop tuning your scanner cadence and start building the map. Before the next advisory arrives, you should be able to answer, in one query, which builds and services contain a given package version.
A scanner that reruns against every repository on every advisory does not scale to this.
The advisories from all sources need to be recorded once against the artifact and reused everywhere that artifact appears.
Shameless plug here but that is how Gastropod is built. Every artifact carries its exact PURL identity and a where-seen history, so a finding recorded once applies to every package, application, and dependency chain that pulled the same digest. OSV advisories correlate to each package version and carry their inherited reach across dependents. Direct and transitive dependents are flattened into queryable edges, which turns blast-radius scoping into a single query instead of a fleet-wide rescan. Every pull is attributed to a principal, with the time, the source, and the requester recorded, so an incident response team can produce the list of affected builds from the record rather than trying to reconstruct it from log activity or multiple-source queries. Bring your own scanner output from Trivy, Grype, Snyk, Anchore, or other (even your custom harness) and Gastropod attaches it back to the artifact record, where it stays useful for every current and future consumer of that version.
This does not patch the problem for you but it removes the days you currently spend deciding whether a given advisory applies to anything you run, which is the part of the process that 14,090 new findings in two months is about to overwhelm.
If your answer to "where does this package version live" is currently a person with a spreadsheet or a scramble to download and parse logfiles, take a look at what the gastropod.io does. I think you will like it.
For a free no-strings attached trial of gastropod.io just sign up. It is a one-click cancel if you decide it's not for you so nothing to lose! If you have questions or want to talk with one of us just ->contact us<-. We would love to talk!