How ZeroThreat Detects New CVEs Within Hours of Disclosure

Quick Overview: New CVEs are being exploited faster than ever, making detection speed a critical part of application security. This blog explains how ZeroThreat detects newly disclosed CVEs within hours, why traditional CVE coverage often lags behind, how interpreter-driven vulnerability intelligence works, the role of tech stack-based testing and AI validation, and the difference between rapid CVE coverage and zero-day vulnerability detection.

The time from CVE disclosure to first observed exploitation has collapsed from 771 days in 2018 to hours in 2024. In the first half of 2025, 32.1% of known exploited vulnerabilities showed exploitation evidence on or before the day the CVE was published, meaning attacks started before most security teams even received the disclosure. A scanner that updates its CVE signatures weekly or monthly isn't late to the response. It's not in the response at all.

ZeroThreat’s zero-day detection closes this window through interpreter-driven vulnerability intelligence: a continuous ingestion layer that maps newly disclosed CVEs to active detection logic within hours of publication, without waiting for the NVD enrichment cycle that the rest of the industry depends on. This post explains exactly how that works, why traditional pentesting or DAST tools can't match it, and what the difference means for your application's exposure window during an active threat cycle.

Your stack has CVE exposure right now. Find it before attackers do. Start For FREE

What "Real-Time CVE Detection" Actually Means

Real-time CVE detection is the capability to activate scanner test cases for a newly disclosed CVE within hours of its public publication, without requiring manual signature creation or waiting for a downstream vulnerability database to enrich the CVE with CVSS scores, CPE identifiers, and CWE categorization.

It's distinct from real-time scanning (scanning continuously) and from zero-day detection (finding vulnerabilities without any CVE yet assigned). Real-time CVE detection sits in the gap between disclosure and traditional scanner coverage, which for most tools is measured in weeks.

The Numbers Behind the Problem

Before getting into architecture, the threat landscape data establishes why this matters at all.

In 2025, 48,185 new CVEs were published, a 20.6% increase over 2024 and a 520% increase since 2016. That's 133 new vulnerabilities catalogued every single day. CVE submissions to CNAs (CVE Numbering Authorities) have grown 263% between 2020 and 2025, driven in significant part by AI-assisted vulnerability discovery tools accelerating researcher output.

The exploitation side has kept pace. According to Mandiant's analysis, the average time to exploit has collapsed to five days as of 2023. Fortinet's analysis of 97 billion exploitation attempts in 2024 confirmed this trajectory, with 28% of vulnerabilities exploited within 24 hours of disclosure. VulnCheck's 2025 data shows 32.1% of known exploited vulnerabilities had exploitation evidence on or before the day the CVE was publicly issued, up from 23.6% in 2024.

The organizational response time, however, hasn't changed. Companies take an average of 74 days to patch critical application vulnerabilities, according to CyberMindr's 2025 analysis. That creates a systematic 6-to-20x exposure window between when attackers have working exploits and when defenders have applied fixes. A scanner that doesn't know about a CVE for 30 days makes that window materially worse.

Why NVD Enrichment is Too Slow for Real-time CVE Coverage

The NVD has served as the industry's primary source for enriched CVE data for over 20 years. Enrichment means adding CVSS scores, CWE categorization, and CPE product identifiers to raw CVE records, the metadata that security teams and scanner vendors use to build detection logic and prioritize remediation.

In February 2024, NIST began slowing CVE enrichment. By May 2024, 93.4% of new vulnerabilities and 50.8% of known exploited vulnerabilities were waiting on analysis. In April 2026, NIST officially changed its policy: it now enriches only CVEs that meet specific risk-based criteria, and will not routinely enrich all published CVEs going forward. CVE submissions increased 263% between 2020 and 2025. The enrichment infrastructure wasn't designed for that volume and cannot scale to meet it.

For scanner vendors that depend on NVD enrichment as their primary trigger for building new CVE test cases, this creates a structural lag that grows longer with each passing month. A CVE published today might sit in "Awaiting Analysis" status for weeks before the metadata required to build a detection signature arrives. Defenders relying on the NVD as their signal are already behind the threat curve before they start.

Expose vulnerabilities within hours of CVE disclosure with active real-time threat intelligence. Run Zero-Day Detection

How Do Scanners Detect New CVEs After Disclosure?

Understanding the traditional pipeline clarifies exactly where ZeroThreat's architecture diverges. Most DAST tools follow a five-step process for turning a new CVE into an active detection check.

Step 1: CVE is published by a CNA. The record goes live in the CVE database. NVD marks it "Awaiting Analysis." At this point, the raw record may contain only a description, no CVSS score, no affected versions list, no CWE.

Step 2: NVD enrichment. NIST analysts add CVSS scoring, CWE categorization, and CPE product identifiers. Under current NVD policy, this happens for high-priority CVEs within days; for lower-priority CVEs, it may not happen at all, or it may take weeks.

Step 3: Scanner vendor database ingestion. The vendor's vulnerability database polls the NVD or a downstream aggregator, picks up the enriched CVE, and flags it for internal triage.

Step 4: Internal research team creates a test case. A security researcher converts the CVE into a scanner check: an HTTP payload, a version detection heuristic, a behavioral probe. This requires understanding the affected component and how to test for the specific vulnerability class.

Step 5: Test case QA and release. The check is tested for accuracy and pushed to the production scanner.

Each step adds latency. Steps 1 through 3 alone can take days to weeks under current NVD conditions. Steps 4 and 5 add more. For non-critical CVEs, the total pipeline can extend to 30 days or longer. This is documented reality, not speculation. The ability to rapidly transform newly disclosed vulnerabilities into executable, validated attack coverage is therefore a significant advantage in modern application security programs.

How ZeroThreat Closes the Gap

ZeroThreat's approach to CVE speed rests on three distinct architectural components. They're not interchangeable; each solves a different slice of the problem.

What Is Interpreter-Driven Vulnerability Intelligence in ZeroThreat?

ZeroThreat’s interpreter-driven vulnerability intelligence is a live analysis layer that continuously ingests CVE disclosures from primary sources (CNAs, vendor security advisories, researcher publications, and proof-of-concept repositories) and maps them to active detection logic without waiting for NVD enrichment to complete.

Where traditional DAST tools treat NVD enrichment as a prerequisite for building a CVE test case, ZeroThreat's interpreter layer bypasses NVD entirely for CVE coverage timing. It reads the raw disclosure, correlates it with the target's known technology stack, and generates or updates detection logic where sufficient technical detail exists in the disclosure itself.

The practical result: when a CNA publishes a critical CVE affecting a widely-deployed web framework on a Tuesday morning, ZeroThreat Enterprise users can trigger a scan with that CVE's detection the same day. The NVD hasn't finished analyzing the record. The CVE is still marked "Awaiting Analysis." The interpreter layer didn't wait.

This is the mechanism behind ZeroThreat's documented 0-day CVE delay: detection is available as soon as the interpreter maps the disclosure to an actionable test case, not when the enrichment pipeline completes.

Tech stack-based vulnerability testing in DAST

The second component addresses relevance, not just speed. A CVE for a WordPress plugin produces no exposure for a Node.js API. A critical-severity CVE in a PHP deserialization library has zero relevance to an ASP.NET application. Firing every CVE against every target is noise, not coverage.

When you configure a target in ZeroThreat, you define the technology stack: frontend framework (React, Angular, Vue), backend (Node.js, PHP, Java, ASP.NET), database, authentication mechanisms. This definition governs which CVE-based test cases activate for that target. Under the Tech Stack Based Vulnerability feature (available on Professional and Enterprise plans), the scan profile filters active CVE checks by:

• Technology stack: only CVEs mapped to the configured components
• CVE timeline: filter to recent disclosures to focus effort on newly published CVEs without re-running the entire historical set
• Severity: filter by Critical, High, Medium, or Low to match risk tolerance and scan time budget

When you enable Tech Stack Based Vulnerability in a scan profile, ZeroThreat shows the count of matching CVE test cases selected by your filters. You confirm, and those checks execute alongside the standard scan.

Each CVE finding in the report includes CVSS v3.0 base score, CWE and OWASP mapping, NIST reference, affected URIs, the exact HTTP request and response captured during the scan, and technology stack-specific remediation guidance. A PHP application flagged for an injection-class CVE gets remediation that includes PHP-specific prepared statement patterns using PDO, not generic advice.

Zero-day signal detection: coverage before CVEs exist

The third component addresses the gap no CVE database can fill. In 2025, according to Cloud Security Alliance research citing VulnCheck and Mandiant data, the average time from exploit publication to formal CVE assignment was approximately 23 days, and roughly 80% of exploits were published before their corresponding CVEs received official designation. Defenders relying on CVE publication as their signal for action are already behind.

ZeroThreat's zero-day signal detection uses behavioral pattern analysis rather than signature matching. Instead of looking for a known CVE identifier, it recognizes patterns characteristic of known exploit categories: authorization bypass signals, state desynchronization, multi-step logic abuse, unexpected object traversal, and other exploit primitives that new vulnerability classes share with established ones.

The brand deck is specific about how this is accurately described: ZeroThreat "detects signals, not always the zero-day itself." The capability surfaces indicators that a new vulnerability class is active in the target application. The Platform AI validation layer then confirms whether the signal represents an exploitable finding before anything reaches the report. This is not noise-based anomaly detection. It's pattern recognition grounded in known exploit behavior, applied to novel contexts.

Close your CVE exposure window without overspending on your security budget. View Pricing

The Detection Flow for a Newly Disclosed CVE

To make the architecture concrete, here is how detection for a new CVE moves through ZeroThreat in sequence.

Disclosure: A CNA publishes the CVE record. NVD marks it "Awaiting Analysis." Vendor advisories may already be out. The interpreter layer starts ingesting.

Interpreter mapping: Where the disclosure contains sufficient technical detail (affected component, version range, attack vector, PoC references), the interpreter generates or updates a CVE test case. For Enterprise users, this detection is available immediately.

Scan execution: The next scan run against a target whose configured technology stack includes the affected component activates the CVE test case. ZeroThreat runs the test against the live application, focusing on behavioral validation, and sometimes it relies on version number lookups. It confirms whether the running application actually exhibits the vulnerable behavior, ensuring accuracy even in cases where a traditional version check is used.

Platform AI validation: The validation layer re-tests every candidate CVE finding before it reaches the report. A finding labeled as a specific CVE includes the HTTP request, the response, and evidence of exploitability. While some findings may rely on version matching when behavioral testing isn't possible, the platform prioritizes capturing demonstrated impact whenever the exploit path can be verified.

Report output: The finding maps to CVE identifier, CVSS v3.0 score, CWE, OWASP Top 10 category, and NIST reference. Remediation guidance is specific to the application's configured technology stack.

0-Day CVE Delay vs Zero-Day Vulnerability Detection: The Difference

These two capabilities are regularly confused, and the confusion produces misleading scanner evaluations. They solve different problems.

The distinction matters because they are purchased differently, serve different threat models, and have different architectural bases. 0-day CVE delay is a speed optimization on the known-CVE pipeline. Zero-day signal detection is coverage where no CVE exists yet. Both are part of ZeroThreat's architecture; neither substitutes for the other.

Scheduling Scans to Match CVE Disclosure Cadence

The fastest CVE intelligence is only useful when scans run frequently enough to use it. ZeroThreat's scheduled scan capability lets you align scan frequency with deployment and disclosure cycles.

A recommended configuration for teams prioritizing CVE coverage: align the scan schedule with deployment cycles. If your team deploys every Sunday night, a scheduled Monday scan at 2:00 AM tests both the deployment's changes and any new CVE coverage that became available since the previous scan. The schedule supports Daily, Weekly, or Monthly repeat cycles with 30-minute start-time precision.

For Enterprise teams with high deployment frequency, CI/CD integration (GitHub Actions, Azure Pipelines, CircleCI, GitLab CI/CD, AWS CodePipeline) triggers a scan automatically on each pipeline run via the ZT_TOKEN mechanism. The scan profile used in CI/CD includes the Tech Stack Based Vulnerability configuration, meaning new CVE test cases available since the last profile save fire automatically in the next pipeline run. There's no manual update step between "CVE disclosed" and "scan includes that CVE's detection."

What ZeroThreat Does Not Claim

Claim integrity is part of how ZeroThreat communicates, especially on a topic where vendor overclaims are common.

"Real-time CVE coverage within hours of disclosure" means the interpreter layer processes new disclosures quickly when sufficient technical detail is available to build a test case. For CVEs where the CNA disclosure is thin, where PoC details aren't yet public, or where the affected component requires deeper behavioral analysis to test, coverage arrives when the technical basis for a test case is established, not at the moment a CVE ID is published.

ZeroThreat is an automated pentesting platform. CVE detection is dynamic: it tests the running application's behavior. It doesn't analyze source code dependency trees for vulnerable library versions before the application is built. Dependency-level CVE detection at the code layer is an SCA (Software Composition Analysis) function. ZeroThreat's CVE coverage is at the runtime behavior level.

ZeroThreat also doesn't claim to detect every CVE the moment it's published, and the technology stack filter exists precisely to prevent indiscriminate coverage: only CVEs relevant to the configured stack activate for a given target.

Every application has a unique stack. Get CVE testing advice that matches yours. Contact Us

The Exposure Window Is the Product You're Actually Buying

The time between a CVE going public and your scanner knowing about it is a window your organization is undefended during an active threat cycle. For the average scanner on a 30-day update cycle, that window spans a period when, statistically, 28% of weaponized CVEs have already been exploited in production environments belonging to organizations like yours.

ZeroThreat's interpreter-driven intelligence, 0-day CVE delay on Enterprise plans, Tech Stack Based Vulnerability filtering, and zero-day signal detection across all plans together close that window to the point where it doesn't create a meaningful exposure gap during active threat cycles.

Run a scan with current CVE coverage on your stack, or book a session with a security engineer to walk through Tech Stack Based Vulnerability testing for your specific application and framework.