How it works

Vulnocalypse reads vulnerability registries, government CERTs, vendor advisories, research blogs and newsrooms around the clock, links everything that refers to the same vulnerability, and only shows what passes automated validation.

What we only say when it’s verified

“Exploited in the wild” is shown only with a source we can cite: a known-exploited listing (CISA KEV, VulnCheck KEV or ENISA), CISA’s own SSVC assessment, or reports that state attackers are exploiting it, from the vendor or a government agency, or from at least two independent organisations. Each such report must name the vulnerability, and Claude reads it to confirm it says exactly that. “Could be exploited”, “exploitation is likely” and proof-of-concept code don’t count. “Services taken offline” is shown for a country only when a report says services were actually taken offline and the report itself shows it happened in that country, which Claude checks; the publisher’s country alone isn’t enough. Exploit code published means a public repository claims to contain exploit code; we don’t run or verify it, and such repositories are sometimes fake.

AI second reader

Vulnocalypse’s rules decide which articles belong to which vulnerability. Claude (Haiku, by Anthropic) then re-reads the uncertain cases (whether an article is really about the vulnerability), every claim that a vulnerability is being exploited, and every reported service shutdown (whether it really happened, and in that country). It can confirm, remove or downgrade, but never adds a link or a claim of its own. It also translates non-English headlines and writes the “In plain English” summaries, which are labelled as AI-written. Only public articles and public vulnerability data are sent to it.

Named events and technical briefings

When a vulnerability gets a nickname (like PHP2Shell, which covers two CVEs), Vulnocalypse groups its CVEs into one event, so it trends and counts once. Each CVE keeps its own page. Groupings are confirmed by Claude with quotes from our sources; until that has happened, CVEs are grouped only when most of each one’s coverage also covers the other.

For trending vulnerabilities, Claude (Sonnet, by Anthropic) compiles a technical briefing from the collected advisories, CERT bulletins and research: what’s affected, exploitation status, mitigations in order, detection, and guidance that was disputed or corrected. Every statement cites its sources, and specifics like versions and setting names are checked against them before publishing. Briefings contain defensive guidance only, never exploit details. They’re written for every vulnerability in the top 10 of Trending, the highest-ranked first, and kept up to date while they trend: new sources are checked every 30 minutes for the top 3 and every 2 hours for the rest, and the briefing is rewritten only when something material changes.

Indicators of compromise

For trending vulnerabilities, Vulnocalypse collects indicators of compromise (attacker IPs, domains, files, request paths, hashes) from the advisories, CERT bulletins and research it already reads, and from abuse.ch ThreatFox where available. Each indicator lists the sources that reported it. Values are shown defanged; request lines keep only the method and path, never exploit payloads. IP addresses can belong to compromised or shared machines, so they’re hidden after 30 days without new reports.

Social chatter

Vulnocalypse notes public Bluesky posts that mention a vulnerability’s identifier or name (through Bluesky’s public Jetstream), and public Fediverse and Bluesky sightings collected by CIRCL’s Vulnerability-Lookup. Only the account, a link to the post and its time are kept, for 90 days; post text is not stored. Deleted posts are removed, automated accounts that repost every new vulnerability are left out, and accounts that ask not to be shown to logged-out visitors are never shown. To have your account excluded, email contact@vulnocalypse.com. Social chatter shows attention, not risk, and isn’t part of the assessment.

Privacy

Vulnocalypse counts visits without cookies and without storing IP addresses or anything on your device. A visit is recognised only within the same day, so nobody can be followed over time. Browsers that send Global Privacy Control or Do Not Track aren’t counted at all.

What gets into the feed

A vulnerability enters the feed when it is corroborated (a published CVE record, or at least two independent organisations) and new (published in the last 60 days, newly listed as known exploited, or newly reported as exploited), and its assessment is Act, or Attend with a ranking score of 60 or more. Critical vulnerabilities that are major news before anyone exploits them (Track* with CERTs in three or more countries, or five or more outlets) are included too.

Exploitation status

We only mark something exploited when there is a citable source: a KEV listing (CISA, VulnCheck or ENISA), a statement from the vendor or a government agency, CISA’s SSVC assessment, or at least two independent organisations reporting attacks with no later denial from the vendor. Phrases like “no evidence of exploitation” are detected and count against a claim.

Validation, without humans

Identifiers are checked against the CVE List; rejected or non-existent CVEs are dropped. Vendors, products and CVSS come from the official record rather than from headlines. Titles come from the record too, or from the reporting when the record’s title doesn’t say what’s affected, and are never a bulletin or roundup headline. Wire stories syndicated across outlets are counted once. Roundups that list dozens of CVEs only count the ones they actually discuss. Reports without an identifier wait for corroboration and are merged into the right CVE once one is assigned. Every decision is logged and shown on each vulnerability’s page.

The Panic meter

Four numbers over the past 24 hours, counting only vulnerabilities first seen in the last 14 days: distinct people talking about them on Bluesky and the Fediverse (automated accounts left out), distinct research labs publishing about them, distinct news organisations covering them, and distinct CERTs and agencies warning about them. Each is ranked against its own 90-day history, weighted 20% people, 20% research labs, 30% CERTs and 30% news, and stretched so the top levels stay rare. Until there are 14 days of history, each is compared with a “busy day” that grows with the number of sources monitored and is never below the busiest day so far. The meter itself is a rolling 24 hours; the daily chart shows calendar days. Each day’s score is split across the vulnerabilities that caused it.

The outbreak map

The map shows three things for every country: how many national news outlets are covering new vulnerabilities, whether the national CERT or cyber security agency has issued a warning, and whether services were taken offline because of a vulnerability (the unplug icon: shown only when a report says services there were taken offline and Claude has confirmed it happened in that country; marked confirmed when the country’s own CERT or national press reports it, or two independent outlets do). National outlets are read directly, through local-language Google News editions, and through GDELT, which attributes coverage in over 100 languages to its source country. International security press is left off the map so it shows national attention, not trade coverage. Replay the spread to watch a vulnerability travel from patient zero across the world.

Subscribe

• Everything (RSS), also as Atom and JSON Feed
• Exploited only and KEV-listed only
• Updates: new KEV listings, exploitation changes and public exploits for tracked vulnerabilities
• Per vendor: /feed.xml?vendor=Fortinet, or by score: /feed.xml?min_score=80

Use it from an AI agent

Vulnocalypse runs a read-only MCP server. Add it to any MCP client as a remote server:

https://vulnocalypse.com/mcp

Tools: get_feed, search_vulnerabilities, get_vulnerability, check_exposure (send the products you run and get back anything that affects them), get_panic and explain_panic_day. The JSON API is documented at /api/docs.

How a vulnerability is assessed

Each vulnerability gets a decision from SSVC, CISA’s Stakeholder-Specific Vulnerability Categorization: Act, Attend, Track* or Track. It rests on four decision points, each shown with where its value came from:

• Exploitation (none, proof of concept, active): from the evidence on the page: listings in known-exploited catalogues (CISA KEV, VulnCheck KEV, ENISA), statements by the vendor or a government agency, independent reports from at least two organisations, and public exploit code. When CISA’s own SSVC assessment in the CVE record says more, that is used and named.
• Automatable (yes, no): CISA’s SSVC value when it exists; otherwise from the CVSS vector (network attack, low complexity, no privileges, no user interaction).
• Technical impact (partial, total): CISA’s SSVC value when it exists; otherwise from the CVSS vector (full loss of confidentiality and integrity) or a confirmed remote code execution.
• Deployment: SSVC’s mission and well-being point depends on the organisation. As a public baseline we assume a typical organisation running the product, and use how widely the product is deployed (internet-facing devices, identity systems, hypervisors, operating systems, browsers and common libraries count as high). Your own decision can differ: a product you don’t run is always Track for you.

Next to the decision, every page shows the evidence it rests on: exploitation evidence with sources and dates; CVSS from the CNA, CISA and NVD, with disagreements between them flagged; affected and fixed versions; the EPSS probability of exploitation in the next 30 days (the probability itself, not its percentile); and public attention, which is shown but is never part of the decision. Missing data is listed rather than guessed: for example “NVD has not assessed it yet” or “internet exposure not measured”.

The number on each entry is a ranking score for sorting. It never contradicts the decision: every Act ranks above every Attend. Within a decision it orders entries by EPSS probability, CVSS, deployment and whether the exploit is weaponised (a Metasploit module, an exploit proven by Ethiack Zero, or use in ransomware).

Checking ourselves. The assessment made when a vulnerability is first seen is stored, and 30 days later it is compared with what happened: did it get exploited or listed as known exploited? We measure how often each decision was followed by exploitation, and whether the ranking predicts exploitation better than CVSS or EPSS alone. We’ll publish the results here once there are enough assessments to be meaningful.

Limits. Internet exposure (how many vulnerable systems are reachable) is not measured yet. EPSS is unavailable for the first days after a CVE is published. Decision points derived from CVSS inherit the CVSS author’s judgement, which is why the source of each value is shown.