How we know what we say
Two kinds of evidence
Claimed coverage is a vendor's own public statement that a rule targets a CVE. We parse it from their changelog, quote the text and link it. Everything on the site today is claimed.
Measured coverage will come from a test lab: one identical origin behind each WAF on our own accounts, the same exploit request for each CVE sent daily, and the result recorded as block, challenge, log or pass. Measured results will be labelled separately and published with their configuration.
Statuses
- Blocks by default. The vendor says a rule for this CVE ships with a blocking or challenge action.
- Logs only by default. A rule exists but only logs by default. Someone has to switch it to block.
- Rule off by default. A rule exists but is disabled by default. Someone has to enable it.
- Rule published. The vendor says it published a rule. Its source does not state the default action.
- No public claim. We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it.
- Before feed history. The CVE predates the oldest entry in this vendor's public feed, so a rule may exist that we cannot see.
- No public source. This vendor publishes no machine-readable rule changelog we can check.
Time to rule
Days from the CVE's publication date in the CVE List to the vendor's own release date of the first new rule naming it. A negative number means the rule shipped before the CVE was published. When the first entry we can see updates an older rule, we don't count it.
The site check
"Is your site covered?" looks up the hostname's CNAME chain and the network of its addresses over public DNS (Cloudflare and Google resolvers, Team Cymru for networks). It never contacts the site. A WAF that only appears in HTTP responses, such as an appliance on your own network, is invisible to it.
What we read
- Cloudflare: Cloudflare WAF changelog (RSS). Each row gives the rule ID and its default action. The feed starts in January 2025, so older rules are missing.
- AWS: AWS Managed Rules changelog. AWS often describes a vulnerability without naming its CVE (for example "Log4j"). We count only entries that name the CVE, so AWS coverage is understated.
- Microsoft Azure: Microsoft Learn rule-group tables. The rule tables name CVEs but carry no dates, so Azure is left out of every time-to-rule figure.
- Google Cloud: Cloud Armor release notes (Atom) and WAF rules reference. Google names few CVEs: the release notes start in May 2024 and the rules reference lists CVEs without dates. Its cve-canary rules are opt-in.
- Fastly: Fastly changes feed. The feed holds only the latest 25 changes, so history builds up from the day we started reading it.
- F5: F5 Distributed Cloud attack signatures changelog. Each signature lists the CVEs it references, with its id and date. F5 does not state a default action; signatures enforce once staging ends in your policy.
- Akamai: None public. Akamai publishes rule release notes only behind a customer login. Its blog names some Rapid Rules, but not as a feed we can read reliably.
- OWASP CRS: Core Rule Set CHANGES.md. CRS rarely names CVEs: it relies on generic detections. Our own lab measures what it actually blocks.
- Vendor changelogs: polled every 5 minutes; a vendor's rule appears here within 5 minutes of the vendor publishing it. Vendors publish in batches (Cloudflare mostly weekly, plus emergency releases), so the site is only as fast as their changelogs.
- Exploitation: CISA Known Exploited Vulnerabilities catalog, hourly.
- Social: Hacker News, Mastodon (mastodon.social #cve), Bluesky and the official X API every 5 minutes, plus new GitHub repositories named after a CVE. Authors naming more than 12 CVEs a day are treated as feed bots and left out of trending.
- Our lab: public exploit templates replayed through WAFs on our own test server. See the lab.
- CVE details and CVSS: the CVE List (CVEProject/cvelistV5), CNA score first, then CISA's.
- Exploit likelihood: FIRST EPSS, daily.
Fairness
- Vigilbase is a Cloudflare partner. We publish Cloudflare's misses and slow rules the same way as anyone's.
- Vendors can report a wrong mapping to security@vigilbase.com.
- All data is downloadable from the API.