What this is
Learn how this free security tracker gathers, ranks, and presents news and vulnerability intelligence.
Cybersecurity Tracker aggregates security news and vulnerability intelligence into one ranked, filterable feed. It runs autonomously, costs nothing, and asks for no account.
Built and operated by Gary Bowen
I am a cybersecurity leader, and I built Cybersecurity Tracker to solve a problem I have on my own team: too many sources, too little time, and no free tool that ranks what actually matters. It runs autonomously and stays free because the security community it serves should not have to pay to keep up.
Feedback makes it better. You can connect with me on LinkedIn or send feedback directly.
How it works
Reporting is aggregated from multiple sources. Anything Cybersecurity Tracker computes or infers is labelled as its own judgment, never as a claim made by a source. The pipeline combines security reporting, vulnerability intelligence, public records, and other structured data. Stories are de-duplicated and clustered across outlets, classified by category, and summarized in our own words; vulnerabilities are enriched and ranked into priority tiers. Leak-site claims are always labeled unverified. Licence-required credits remain on the attributions page.
Editorial policy
- Summaries are two to three sentences in our own words. We never reproduce article text beyond a short phrase.
- Every item links to and names its sources.
- Leak-site entries are always labeled "Unverified claim. Claimed by [group]." We do not present a claim as a confirmed breach.
- We respect robots.txt on any page fetch and use the syndicated feed when full text is disallowed.
How priority works
| Tier | What it means | What to do this week |
|---|---|---|
| Track | No signal currently raises the record above the baseline tier. | Review during routine vulnerability management. |
| Track* | A public exploit, elevated exploitation probability, or Stakeholder-Specific Vulnerability Categorization (SSVC) verdict raises this record for closer watching. | Watch for exploitation and prepare the likely fix. |
| Attend | The SSVC-style verdict calls for attention, but no confirmed exploitation signal sets an Act floor. | Plan remediation this week and confirm ownership. |
| Act | Confirmed active exploitation or an SSVC-style Act verdict requires prompt action. | Prioritize remediation now and verify compensating controls. |
| Act now | Ransomware association sets the top tier; active exploitation can also rise one tier through the end-of-life or open-exposure modifier. | Respond now and verify containment, remediation, and exposure. |
Known Exploited Vulnerabilities (KEV) catalogs provide confirmed-exploitation evidence.
A KEV-listed or confirmed-exploited item is never below Act.
What each input can change
| Input | Source | Can do | Cannot do | When absent |
|---|---|---|---|---|
| Confirmed exploitation | Cybersecurity and Infrastructure Security Agency (CISA), VulnCheck, or European Union Agency for Cybersecurity (ENISA) catalog membership, or a CISA Vulnrichment active-exploitation judgment | Set an Act floor. | Cannot lower a stronger result. | No confirmed-exploitation floor is applied. |
| Ransomware association | Tracked exploitation catalog evidence | Set Act now. | Cannot be inferred from news volume or product exposure. | No ransomware floor is applied. |
| Stakeholder-Specific Vulnerability Categorization (SSVC) verdict | CISA Vulnrichment judgments, with CVSS-derived fallbacks where a judgment is absent | Set Track, Track*, Attend, or Act. | Cannot lower an exploitation floor or set Act now by itself. | An indeterminate input remains indeterminate, never zero. |
| Public exploit | Exploit references and maturity recorded by the tracker | Set a Track* floor. | Cannot reach Attend or Act by itself. | No public-exploit floor is applied. |
| Exploit Prediction Scoring System (EPSS) | Exploit Prediction Scoring System score and percentile | Set a Track* floor at the configured threshold and affect order within a tier. | Cannot reach Attend, Act, or Act now by itself. | No EPSS tier or rank term is applied. |
| End of life | The tracker product lifecycle crosswalk | Lift an actively exploited item by at most one tier. | Cannot move a tier without active exploitation or ransomware association. | No lifecycle escalation is applied. |
| Product exposure | Common Vulnerability Scoring System (CVSS) vector and the tracker product-class crosswalk | Lift an actively exploited or ransomware-associated item by at most one tier when exposure is open. | Cannot move a tier when exposure is controlled, small, or not paired with exploitation. | Exposure is shown as unknown and no exposure escalation is applied. |
| Within-tier signals | Common Vulnerability Scoring System (CVSS), Common Weakness Enumeration (CWE), technical impact, privileges, due proximity, news, exploit maturity, threat Internet Protocol (IP) addresses, and observed instances | Order records within the tier. | Cannot move a record to another tier. | Each absent signal contributes nothing and is never rendered as zero. |
A vulnerability's priority is a tier, not a raw sum. Confirmed exploitation sets an Act floor, ransomware association sets Act now, and an actively exploited item can rise one step when the affected product has an end-of-life version. A Stakeholder-Specific Vulnerability Categorization (SSVC) style decision can set Track through Act; a public exploit or elevated Exploit Prediction Scoring System (EPSS) result can set Track*. Product exposure raises a tier only when an internet-facing product is already under active exploitation or ransomware use, and then by one step at most. The rank within a tier draws on the listed within-tier signals. It is a triage signal, not a substitute for your own risk assessment.
Five further measures separate items that sit in the same tier.
Reach beyond the component
The first is how far the flaw reaches: whether exploiting the affected component lets an attacker reach resources beyond that component's own security authority.
Privileges required
The second is Privileges Required, which records whether an attacker needs no account, an ordinary account, or an administrative one.
Both only ever add to an item's score, never subtract, so they can change the order of items inside a tier. Neither can move an item into a different tier, and neither is treated as evidence of exploitation.
Details for analysts
We read reach beyond the affected component from whichever measure the record's version of the standard provides. Version 3 states it as Scope, a single changed or unchanged value. Version 4 removed Scope and replaced it with three measures of the impact on a system beyond the vulnerable one, so we read those instead. We do not read version 4's Scope letter, because that version reuses it for an unrelated safety measure describing physical harm to a person, and reading it as Scope would state something the record does not say.
The two versions earn the same amount. Version 4 grades how large the further impact is, where version 3 records only whether it happened, and scoring the grade would rank two items differently for the same real-world property purely because of which version of the standard their record happens to use. Privileges Required means the same thing in versions 3 and 4, so we read it from both.
The priority number you see is rounded for reading, to one decimal place. Two items can show the same rounded number and still sit in a fixed order, because we rank them on the unrounded value. That ordering is stable and repeatable, not arbitrary. The decimal preserves more of the underlying score for reading, but it does not guarantee a unique displayed value. It is not a claim of precision about risk, and a difference of a few tenths of a point is not a meaningful difference in urgency. The breakdown under each item always adds up to the sub-score printed beneath it, and the rounded figure we show alongside can differ from the unrounded one we rank by, by less than one tenth of a point.
We list an entry for reach and Privileges Required only when the measure raises the score. A record whose flaw stays inside the affected component, or where an attacker needs administrative privileges, shows no entry, and neither does a record where we cannot read the measure at all. An absent entry never means we assumed a zero, and it is not a claim that anything was measured. The same rule governs the two measures described next.
Weakness class
A third measure is the weakness class: what an attacker actually gets. The Common Weakness Enumeration (CWE) identifier on a record tells us whether the flaw lets an attacker run code of their choosing, defeat an access control, or read information they should not see. The severity score already says how bad the outcome is, and this says what kind of outcome it is, which severity alone does not carry. We weigh only the classes listed in an operator reviewed table we maintain, and a class that is not on that table earns nothing. That is a refusal to make a claim, not a finding that the weakness is harmless. Where an item does earn one, the breakdown under it names the class in plain words, so what we counted is visible on the item itself.
Exploit maturity
A fourth is how mature the public exploit is. Where a catalogue records a working exploit for an item, it also records a grade: the Metasploit project rates how reliably its module works, and the VulnCheck exploit database records what the exploit gives an attacker. We use that grade, so among items that are otherwise equal, the one with a more reliable or more powerful public exploit ranks higher.
Details for analysts
It is a small amount, and a difference in exploitation likelihood or severity between two items will usually outweigh it. This is not a second opinion about whether an item is exploited. It reads the same two sources we use to decide how exploited an item is, it is capped far below the distance between any two steps of that judgment, and it cannot move an item into a different tier. It applies only where a catalogue provides a grade. Where a catalogue lists many exploits for one item we store the first several rather than all of them, so we grade the best of the ones we hold, which is not always the best that exists.
Direction of travel
A fifth is direction of travel. Every other measure describes where an item stands today, and this one describes where it is heading. We keep a daily archive of Exploit Prediction Scoring System readings, and we compare an item's most recent reading against its oldest reading in the last thirty days. An item whose predicted likelihood climbed from almost nothing to near certain in a month is a different situation from one that has sat at the same high number all along, even though the current number alone cannot tell them apart. Only a rise counts. A fall earns no penalty, because the likelihood measure itself has already fallen with it, and subtracting again would count one decline twice. It is capped well below the likelihood measure itself, so where an item stands always outweighs how fast it moved, and it cannot move an item into a different tier. It applies to a small minority of items on any given day, and which items those are changes as the readings do.
Details for analysts
We make no claim about direction of travel unless we can measure it. An item we have not tracked long enough, or whose rise is too small to print, shows no entry at all, which is not a reading of no change. If the archive stops updating we withhold the measure from every item rather than describe a month old move as current, and if an unusually large share of the whole archive moves on a single day, we withhold the measure until that day has passed out of the window: a shift on that scale is not about any one item, and a rise measured across it would not mean what a rise normally means. We do not say what caused it. The published readings could have been rebuilt, or a day's snapshot could have been written only in part, and the measurement cannot tell those apart. One limit worth stating: the comparison spans the readings we hold inside those thirty days, so a recently published item can rest on considerably fewer.
Threat intelligence tags contributed by the abuse.ch ThreatFox community are shown on an item with the date each indicator was first seen, and they do not change its priority. The tags are community submissions, and we hold a number a defender acts on to the same evidence standard as our other sources.
What it costs
Nothing, to you. No account, no paywall, no ad tracking. Anonymous, cookie-free Cloudflare Web Analytics measures aggregate site use. See the attributions and licences page for how every source is credited, and the API if you want the raw data.
Send feedback
A bug, a source we should add, or anything else. No account needed. Leave contact details only if you want a reply.