Live tracker of exploited and high-impact vulnerabilities
New vulnerabilities from CERTs, vendors, researchers and newsrooms in 180+ countries, checked automatically, with how widely each one is being exploited, warned about and covered.
Panic meter
Connecting- Researchers talking
- –
- News outlets covering
- –
- CERTs and agencies warning
- –
Distinct people and organisations discussing new vulnerabilities in the past 24 hours. Get alerts when it changes
Trending now
Outbreak map
- Countries in the news
- –
- Agencies warning
- –
- Countries warned
- –
- Services offline
- –
- Patient zero
- –
Daily panic
Vulnerabilities
Alerts
Get told when the Panic meter changes level or surges, and when new vulnerabilities are confirmed exploited or warned about by CERTs in several countries. Every alert says what’s driving it, who’s warning, how widely it’s covered and where the fix is.
Browser notifications
Notifications on this device, even when the site isn’t open. On iPhone and iPad, add Vulnocalypse to your Home Screen first.
Slack, Teams, Discord or webhook
Paste an incoming webhook URL. We send a test message first and only connect it if it arrives.
Where do I get a webhook URL?
Slack: create an app with Incoming Webhooks enabled, add it to a channel and copy the URL. Microsoft Teams: in the channel, use Workflows → “Post to a channel when a webhook request is received”. Discord: channel settings → Integrations → Webhooks → New webhook → Copy URL. Anything else: any HTTPS endpoint that accepts JSON; you’ll get a secret to verify our signature.
RSS
No sign-up and nothing stored: subscribe to /alerts.xml in any feed reader.
Your alerts on this browser
Recent alerts
Privacy
We store only what’s needed to deliver alerts: your browser’s push address and encryption keys (random values your browser creates, with no name or email) or the webhook URL you enter, plus your choices above. No accounts, no IP addresses and no tracking. Removing an alert here, or using the manage link in any message, deletes it immediately.
Client-Side Memory Leak in OCSP Response Checking
Assessment: Track
SSVC decision points: exploitation none, automatable yes, technical impact partial, deployment high.
What is it?
Issue summary: A malicious TLS server can cause a memory leak in a TLS client that has enabled OCSP response checking by sending an OCSP response that contains no single response entries. Impact summary: An attacker can leak an attacker-tunable amount of memory per TLS handshake in a victim client application. A long-running client that repeatedly connects to a malicious server can have its memory exhausted, resulting in a Denial of Service. CWE: CWE-401: Missing Release of Memory after Effective Lifetime Description: The affected function is called during X.509 certificate chain verification when OCSP response checking is enabled with the X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL verification flags, for example when a TLS client verifies an OCSP response stapled into the TLS handshake by the server. When the received BasicOCSPResponse contains an empty SEQUENCE OF SingleResponse, which is permitted on the wire and accepted by the OpenSSL decoder, the OCSP_BASICRESP structure allocated by OCSP_response_get1_basic() was not freed because an early return bypassed the cleanup code at the end of the function. The amount of memory leaked per handshake can be am
Evidence
No coverage recorded yet.
Exploitation
- Public proof of concept
- Exploited in the wild
- Listed as known exploited
- CVSS
- 7.5
- EPSS
- 0.5%
- First seen
- 11 h ago
- Status
- corroborated
Sources
CERTs and cyber security agencies, national news outlets in every country we could find, vendor advisories, research blogs and the security press. Every source is polled on its own schedule, by RSS where possible and by headless browser where not. Broken feeds are repaired automatically; anything still failing is listed here.
Sources admin
Enter the admin token from your server’s .env file (ADMIN_TOKEN). It’s sent once to start a session and isn’t stored in this browser.
Recent sign-in activity
Coverage and speed audit
Checked against ground truth: every recent CISA KEV listing must be tracked and marked exploited; exploitation levels must match their evidence; and how fast each kind of source reaches us after it publishes.
Pipeline, last 24 hours
How many articles each type of source produced, how many were read in full, and how many were linked to a vulnerability. “Unmatched” are articles that look like vulnerability news but couldn’t be linked; the reasons and examples show what to improve.
Add a source
Coverage
All sources
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 gets into the feed
A vulnerability is admitted when it is corroborated, either through a published CVE record or through at least two independent organisations, and its impact score reaches 60 out of 100. Anything listed in a known-exploited catalogue is admitted regardless of score. Once admitted, an entry stays, so the feed never flickers.
Impact score
Up to 30 points for severity (CVSS, or inferred from the description when no score exists), 25 for exploitation, 15 for blast radius by product category (edge devices and identity systems score highest), 15 for attention from news, CERTs and researchers, 10 for EPSS exploitation probability, and 5 for pre-authentication. Every entry shows its breakdown.
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. Titles, vendors, products and CVSS come from the official record rather than from headlines. 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
Three numbers over the past 24 hours, counting only vulnerabilities first seen in the last 14 days: distinct researchers posting 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 35% CERTs, 35% news and 30% researchers, and stretched so the top levels stay rare. 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: 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/mcpTools: 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.