What is NOVA and how does it find vulnerabilities?

NOVA (Network and Open-Source Vulnerability Analyzer) is an agentic vulnerability research system built by Unit 42. It uses a multi-agent architecture with specialized agents for code review, exploit development, adversarial triage, replay judging, and fix verification. Each finding is validated through the pipeline before being counted as confirmed, meaning NOVA's numbers represent real vulnerabilities, not raw scan output.

What kinds of vulnerabilities did NOVA find that traditional tools miss?

92% of NOVA's findings fall outside the vulnerability classes that fuzzers handle reliably. The bulk of discoveries are access control misconfigurations, path traversal flaws, code injection, prototype pollution, and SSRF — vulnerabilities that require reasoning about code intent and application logic, not just input boundary testing. These are the classes that manual code review has historically been the only reliable way to surface.

What does NOVA mean for defenders and open source maintainers?

The primary implication is that the traditional 55-day average patch window is no longer viable. Attackers with access to equivalent autonomous vulnerability discovery tooling will find and exploit these classes of bugs faster than maintainers can respond under the current disclosure-to-patch timeline. Unit 42 is working with clearinghouses including Lightwell and Akrites to coordinate responsible disclosure, but the structural mismatch between discovery speed and remediation speed requires policy changes alongside tooling improvements.

Unit 42 NOVA: Autonomous AI Found 14,090 OSS Bugs in 60 Days

Palo Alto Networks Unit 42 announced at Black Hat USA 2026 that its autonomous vulnerability research system, NOVA, analyzed 3,915 open source software projects over two months and confirmed 14,090 vulnerabilities. Of those, 99.4% had no prior public documentation. 39.7% scored high or critical under CVSS 4.0. A system that can surface previously unknown, high-severity bugs in nearly 4,000 codebases in 60 days represents a qualitative shift in how the vulnerability landscape will evolve from here.

The research, published as “The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software,” documents both the scale of what autonomous AI can find and what it implies for defenders, maintainers, and the industry’s patching cadence.

What NOVA Is

NOVA stands for Network and Open-Source Vulnerability Analyzer. Unit 42 built it as a multi-agent system, with each agent specializing in a different part of the research pipeline. Code reviewer agents analyze source files for vulnerability patterns. Exploit developer agents attempt to build working proof-of-concept exploits for candidate findings. Adversarial triager agents stress-test candidate findings to filter false positives. Replay judge agents re-run exploitation attempts under different conditions to confirm reproducibility. Fix-verification agents check whether proposed patches actually close the identified issue.

This pipeline design separates NOVA’s output from raw scan results. Everything counted in the 14,090 figure has passed through adversarial validation. The 85 findings that matched previously documented vulnerabilities were identified because NOVA found them independently, weeks to months before the public disclosures in question. That incidental result tells you something about the system’s thoroughness.

Unit 42 describes NOVA as leveraging “multiple leading frontier AI models.” The exact model composition is not disclosed in the public research, but the architecture is explicitly designed to use whatever models provide best-in-class performance for each agent’s specific function.

The Numbers in Detail

14,090 confirmed vulnerabilities from 3,915 projects over two months. Let’s break that down.

Under CVSS 3.1, 4,030 findings (28.6%) score high or critical. Under CVSS 4.0, that rises to 5,600 findings (39.7%). The divergence between 3.1 and 4.0 is meaningful: CVSS 4.0 incorporates environmental and threat context more granularly, and the class of vulnerabilities NOVA finds scores higher under it because they tend to involve chained exploitation paths and application-layer access failures that CVSS 4.0 accounts for more specifically.

Only 85 of the 14,090 matched existing documented vulnerabilities. That means 13,005 high-or-critical findings were genuinely new to the CVE record at time of discovery. For context, the entire NVD typically receives around 25,000-28,000 CVE entries per year across all software categories. NOVA surfaced roughly half a year’s worth of high-severity open source findings in two months.

Supply chain propagation amplifies the numbers further. Approximately 1,300 of NOVA’s findings are in dependency packages, and those 1,300 flaws propagate through more than 4,000 downstream projects. A single vulnerable library creates a long tail of exposure across everything that imports it.

Why These Bugs Weren’t Found Before

This is the technically important question. If 14,090 vulnerabilities existed in well-used open source projects, why were they unreported?

The answer is in the vulnerability classes. Unit 42’s analysis shows only 8% of NOVA’s findings fall into categories where traditional fuzzing and dynamic analysis tools are effective: buffer overflows, format string errors, simple memory corruption. These categories are well-covered by existing automated tooling and decades of fuzzer development.

The remaining 92% require reasoning about code intent, data flow, and application-layer semantics. Access control misconfigurations require understanding what a function is supposed to permit versus what it actually permits under different input conditions. Path traversal requires tracking untrusted input through a chain of string operations and filesystem calls. Prototype pollution requires understanding how JavaScript’s inheritance model interacts with recursive object merge patterns. SSRF requires mapping which endpoints accept user-controlled URLs and whether outbound validation is applied correctly.

Fuzzers generate random or mutated inputs and look for crashes. They don’t understand what code is trying to do. Code review, human or AI, reasons about intent. NOVA’s finding is essentially a demonstration that frontier AI has crossed the threshold where it can perform intent-based code review at scale, across vulnerability classes that have historically required senior security engineers to find.

The Structural Problem: Patch Speed Cannot Match Discovery Speed

Unit 42’s own framing is direct: “The patch window has collapsed.”

The industry average for deploying a traditional patch, from vulnerability disclosure to applied fix across a typical enterprise environment, is 55 days. NOVA can find, confirm, and report a vulnerability in hours. The math is unfavorable.

The immediate response might be to accelerate patching. But open source patching is upstream-dependent. A security team cannot patch a library they don’t maintain. They can update their dependency to a patched version, but only after the upstream maintainer has received the report, understood it, developed a fix, cut a release, and published it. For volunteer-maintained projects, that timeline is highly variable.

Unit 42 is working with clearinghouses including Lightwell and Akrites on coordinated responsible disclosure at scale. The challenge is operationally significant: responsible disclosure of 14,090 findings requires a different process than the standard bilateral researcher-maintainer workflow. How you contact thousands of maintainers, track patch status, decide when to publish unpatched findings, and manage embargoes at this volume hasn’t been fully solved yet.

The research explicitly notes that coordinated vulnerability disclosure infrastructure was not designed for output at this rate. That infrastructure is now the binding constraint.

What This Means for Defenders Now

NOVA is a defensive research system, and its findings are being disclosed responsibly. But the capability NOVA demonstrates is not exclusive to Unit 42. Equivalent autonomous vulnerability research systems are within reach of any well-resourced threat actor. The adversarial question is not whether this capability exists, but whether attackers are running similar systems against targets right now.

For security teams, several immediate priorities follow from the research.

Dependency visibility is table stakes. You cannot respond to a disclosure about a package you don’t know you’re using. Software bill of materials (SBOM) coverage for production systems, especially for open source dependencies, is the foundation of any response capability at the pace this research implies.

Prioritization under CVSS 4.0 will become necessary. The CVSS 3.1 to CVSS 4.0 gap in NOVA’s results (28.6% vs 39.7% high/critical) suggests that teams using CVSS 3.1 for triage are underweighting a class of findings that 4.0 scores higher. Tooling and policy updates to adopt CVSS 4.0 for vulnerability prioritization are worth accelerating.

The vulnerability classes NOVA finds well (access control, path traversal, code injection, prototype pollution, SSRF) are the same classes that should anchor threat modeling for applications that accept untrusted input. These aren’t exotic attacks. They’re the classes that appear repeatedly in production breach investigations because they’re present in widely used libraries, hard to find manually at scale, and frequently low-friction to exploit once found.

Finally, the transition in Unit 42’s own workflow, from 2024’s “carefully designed workflow for a narrow vulnerability class with significant human researcher involvement” to 2026’s “agentic AI operating across many vulnerability classes without that overhead,” has taken roughly two years. Security organizations should expect adversarial capability to follow a similar trajectory.