Most vulnerability programs start from the same place: a CVE appears in the NVD, it gets a CVSS score, maybe a KEV entry, and the scanner lights up. Attackers start somewhere else. They map which servers run which product, and sometimes they exploit a flaw weeks before anyone has written a line about it.
Pre-NVD detection means spotting that activity before the vulnerability is published in the NVD, the US National Vulnerability Database where CVEs are listed and scored. It’s the part of the timeline your scanner can’t see, because there is nothing to scan for yet.
The NVD documents at its own pace
I like the NVD. It’s the backbone of how our industry talks about vulnerabilities. But it was built to document, and it can’t keep up with the volume:
- This year, the NVD has received 84,597 new CVEs and analyzed 40,770 of them.
- In September, it received 15,069 and analyzed 5,047: one in three.
- 57,115 CVEs sit in “deferred” status.
(Source: NVD dashboard, nvd.nist.gov, as of 19 October 2026.)
Meanwhile, attackers don’t wait for the analysis. Across the exploited CVEs we tracked, 36% were attacked within a day of publication. CISA’s Binding Operational Directive 26-04 now gives US federal agencies 72 hours to fix publicly exposed, highest-risk exploited vulnerabilities. For a third of exploited CVEs, the attack starts before that clock has meaningfully run. If your defense starts at the NVD entry, you start late.
What happens before the CVE
Exploitation rarely comes out of nowhere. Two things show up first in our data.
Reconnaissance. Before attackers exploit a product, they look for it: which servers run Microsoft Exchange, which expose an F5 BIG-IP management interface, which WordPress sites run a given plugin. That probing targets a product family instead of one CVE. It’s the attacker building a target list for whatever comes next.
Exploitation before disclosure. Sometimes the flaw is already in use. Our network first saw CVE-2025-2748, a file-upload flaw in Kentico Xperience, being exploited on 28 February 2025, by five AWS IPs. The CVE was published in the NVD on 24 March: 24 days later. The research describing it came out 42 days after our first sighting, and our virtual patch shipped on 1 April, 8 days after the CVE.
Probing months before the CVE. Our reconnaissance rule for SAP NetWeaver went live on 28 July 2024, tracking attackers mapping NetWeaver servers. CVE-2025-31324, an unauthenticated upload flaw in NetWeaver Visual Composer, was published on 24 April 2025, about nine months later, and CISA added it to its catalog of exploited vulnerabilities five days after that. Anyone whose firewall followed that rule’s list had been blocking the IPs scouting NetWeaver long before the CVE had a name.
Those are two cases we found by digging. To check whether the pattern holds beyond them, our data science team studied 460 spikes in reconnaissance against the products of 14 vendors (Cisco, Fortinet, Ivanti, Citrix, Microsoft and others). After a spike, a new CVE for that vendor followed within six weeks 28.7% of the time, against 20.6% after an ordinary day: 1.39 times more often. When a CVE did follow, it came a median of 20 days after the spike, and the effect held in every way they cut the data. A spike is a reason to check your exposure on that product before any CVE exists. The Live Exploit Tracker runs more than 300 reconnaissance rules next to 949 CVE-specific rules (virtual patches).
How we detect it: reconnaissance rules
The Live Exploit Tracker watches two levels. CVE rules detect the exploit technique of one specific vulnerability. Reconnaissance rules (called “fingerprints” in our API) detect probing of a whole product: endpoint enumeration on Exchange, OWA and EWS, scanning of F5 BIG-IP and TMUI interfaces, WordPress discovery.
A reconnaissance rule is a broader expression than a CVE rule. It catches traffic that behaves like an exploit attempt against a product, and that often ends in an HTTP error on the target: attackers checking whether a vulnerability-to-be is usable against you, before anyone has published it.
Both run on signals from more than 300,000 active CrowdSec Security Engines on production servers. Both get the same scores: how targeted the activity is, whether it’s growing or fading, and an overall CrowdSec Score. And both can feed your firewall.
That last part is what turns a pre-NVD signal into prevention. Subscribe your firewall to a vendor, and the list covers the IPs probing that vendor’s products today and exploiting its CVEs tomorrow, including the ones that don’t exist yet. When the CVE finally lands in the NVD, the scanners that mapped your Exchange server last month are already blocked.
What to do with pre-NVD signals
- List the internet-facing products you can’t patch in hours. VPN gateways, mail servers, load balancers, CMSs: the things that make headlines.
- Watch the reconnaissance rules for those products. A growing, targeted probing campaign against something you run is your early warning.
- Subscribe your firewall to those vendors. It works with Palo Alto, FortiGate, Check Point, Cisco, Juniper, Sophos, F5, pfSense, OPNsense, MikroTik or any device that reads a plain IP list.
- When the CVE lands, start from what you already know. Who probed you, since when, how targeted. Then patch in the order the exploitation data gives you (we explain the method in How to prioritise CVEs by real exploitation).
Why the window keeps shrinking
AI makes reconnaissance and exploitation cheaper every month. Local models and better tooling turn what used to be a targeted effort into something attackers can industrialize, against everyone at once. The time between “a product is interesting” and “a product is exploited” will keep collapsing. Defenders who wait for a published, scored CVE will keep losing that race.
What it can’t do
Pre-NVD detection is an early warning, and it has limits. Probing a product doesn’t prove a new vulnerability is coming, and we only see what hits internet-exposed systems: nothing about phishing, insider threats or what happens inside your network. Reconnaissance rules cover the product families attackers probe at scale; a niche product may have none. Keep your scanner and your patch process. Pre-NVD tells you where to look first, and blocks the people already looking at you.
FAQ
What is pre-NVD detection? Spotting attack activity against a technology, such as reconnaissance or exploitation, before the vulnerability behind it is published in the NVD. It gives you warning before your scanner, CVSS or the KEV list can know about it.
Is pre-NVD the same as zero-day? No. A zero-day is a flaw exploited before a fix exists. Pre-NVD is about timing of knowledge: activity seen before the vulnerability is public in the NVD, whether or not the vendor already knows about it.
How does CrowdSec detect pre-NVD activity? With reconnaissance rules in the Live Exploit Tracker, which detect attackers probing a product family (Exchange, F5, WordPress…) across signals from more than 300,000 active Security Engines. The same rules can feed your firewall so the probing IPs are blocked.
Does it replace my vulnerability scanner? No. Your scanner shows where you’re exposed; the Live Exploit Tracker shows what attackers are doing, including before a CVE exists. You need both.
See it on your stack
Book a Live Exploit Tracker demo: we’ll show you which of the products you run are being probed right now.
Philippe Humeau, CEO, CrowdSec
