6,754 sites run a known critical CVE. How sure are we?

6,754 sites in our database run a version of some software that has a known critical vulnerability. That is about 1 in 54 of the 364,604 domains we had crawled when we took the snapshot on 22 September 2026. We are fairly sure about the matches we call "exact", less sure about the rest, and this post explains both.

We are building DataCrawly in public, so here is how the number is made, where it breaks, and what we do not know yet.

What does "a known critical CVE" mean here?

A CVE is a public ID for a known security flaw in a specific product and range of versions. An advisory is the published note that says which versions are affected.

"Known critical CVE" in this post means: the site shows a version of a technology, and that version sits inside the affected range of an advisory rated critical. It does not mean the site was hacked. It does not mean the flaw can be exploited on that server. It means the public version number points at a known problem.

Where does the number come from?

These are the figures from the snapshot of 22 September 2026:

The 478 is the size of the detector catalogue: technologies we know how to recognise from a page, not the number we found on these sites. The CVE list is short on purpose. We track 97 CVEs, not every advisory ever published. Each one had to be mapped to a technology we can detect and a version range we can read. A long list of CVEs we cannot match from the outside would only add noise.

The same counters live on the security page and move with every crawl.

How does a domain become a "critical CVE" record?

Step by step:

• Crawl. The crawler loads the public page as any visitor would. No login, no probing, no script execution, no extra asset requests.
• Version. It reads versions from what the page already exposes: a generator meta tag, versioned file URLs (for example on jsDelivr, unpkg or cdnjs), response headers.
• Match. The matcher pairs that version with an advisory whose affected range contains it. The result is a candidate, a signal to verify, not a confirmed exposure.
• Label. Every candidate gets a confidence label: exact, likely or weak.

Why is the version everything?

"This site runs WordPress" tells you nothing about risk. A product can be safe in one release and critical in the next one down. What matters is which release is live.

This is what a lookup on the home page returns. The security verdict at the bottom is only as wide as the versions above it: 23 of 29 components could be checked, the other 6 could not.

A specific version can be checked against an advisory. No version, no check. That is why a site that hides its versions looks "clean" to us. It is not clean. It is silent.

It also works the other way. A visible version is not always the real one. Some servers patch a flaw without changing the version string. We cannot see that from outside, and it is one of the ways a match can be wrong.

What do exact, likely and weak mean?

• Exact. The version is stated directly: a generator meta tag, a pinned package CDN URL, a versioned X-Powered-By header.
• Likely. The version is read from a file name or folder in an asset path, or from the version parameter WordPress adds to its own and plugin files.
• Weak. The version comes from a hint that often lies: the Server header, where Linux distributions ship patched builds under old version numbers, or a theme's cache-busting parameter.

Weak matches do not count toward 6,754. We keep them in the database, but we never put them in front of a site owner and never include them in public numbers. Build IDs and chunk hashes are never treated as versions at all.

How good is it?

We took 50 exact matches and checked each one by hand: open the site, find the version evidence, read the advisory, decide true or false. By 24 September 2026, 94% of those 50 were right.

That is a good sign for the exact bucket. It is not a proof for the whole number.

Why is 94% on 50 not 94% on 6,754?

Three reasons.

• Small sample. 50 checks give a rough estimate with a wide margin. We need more reviews before we quote a precision for the whole set.
• Only exact. The review covered exact matches. The 6,754 also includes likely matches, and we have not published a separate precision for them.
• Known failure modes. We have already caught false matches. One pattern: CVEs that only apply on Windows were matched on sites where nothing suggested Windows. The version was in range, but the platform was not.

What does not count as proof?

We do not scan ports, send payloads or try to confirm that a flaw is exploitable. That is on purpose. Everything we know comes from the public page.

So a record is a strong hint, not a verdict. The honest sentence for any single site is: "You show version X, and version X is listed in advisory Y." What the owner does with that is up to them.

What is next?

We are turning this into a report: State of website security 2026. Aggregates only, no site names. You can see how the checks work on the security page, and the Technology Inspector extension shows the same kind of version evidence for any page you open. The home page has the live counts.

The conclusion so far: a public version number is enough to find a known critical CVE on about 1 in 54 sites, but the number is only as good as its error rate, and we have measured that for exact matches alone.

What question should the report answer? Reply on X or write to us. If a question comes up more than once, it goes into the report.