A free security tracker for practitioners

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 theattributions 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

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

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. 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. 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.

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.

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.

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. 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.

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.

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.

How often each thing refreshes

Every command this tracker runs, with where it runs and how often. 46 run on a schedule and 42 are run by hand, so a number that has not moved is not necessarily a number that is stuck.

Generated from COMMAND_CADENCE in pipeline/src/cli.py and GUARDED_STEP_HOURS in pipeline/src/cadence.py, the same map the scheduled tasks are checked against, so this table cannot drift from what actually runs.