# How the DefenceLevel Index is calculated

DefenceLevel Index · Methodology v1.30

This page describes in full, without simplification, the rule by which the DefenceLevel Index assigns each day a level from 5 to 1. The rule is deterministic: given the same data it always produces the same result, and every level comes with the reasons that determined it.

Methodology version: 1.30 · In force since 4 November 2026 · Page last updated: 4 November 2026

## 1. What it measures, what it does not

The DefenceLevel Index measures **the urgency of new cyber threats**: how likely it is that, on a given day, an organisation will need to act quickly on vulnerabilities in commonly used software and devices, because they are being exploited by real attackers or are about to be.

It does not measure:

- **the risk of an individual organisation**, which depends on the products it uses, how they are configured and how exposed it is on the internet;
- **the overall volume of published vulnerabilities**: thousands every month, most with no practical consequence;
- **attacks targeted at individual victims**, phishing campaigns, credential theft or incidents that do not involve a public software vulnerability.

A low level does not mean the world is safe: it means that nothing new emerged in those 24 hours that calls for action beyond normal maintenance.

## 2. The scale from 5 to 1

The scale follows the US military DEFCON scale: 5 is the ordinary condition, 1 the most severe. DefenceLevel is not affiliated with the United States Department of Defense or with the DEF CON® conference, a trademark of Def Con Communications, Inc.

| Level | Name | Operational meaning |
| --- | --- | --- |
| 5 | Low risk | No serious vulnerabilities in widely used products in the last 24 hours: ordinary maintenance. |
| 4 | Moderate risk | Serious vulnerabilities in widely used products, but no attacks under way and no mature exploits: patch in the normal cycle. |
| 3 | Substantial risk | Attacks under way or imminent on widely used products, including individual edge devices under attack: users of that product must patch now, everyone else within the week. |
| 2 | Severe risk | Broad-impact threat: active, recent exploitation of a serious internet-reachable vulnerability in near-universal components, or a documented campaign against edge devices. Patch today. |
| 1 | Critical risk | Mass exploitation of a critical vulnerability, without credentials, in near-universal components: immediate action. |

The exact conditions for each level are in [section 8](https://defencelevel.com/index/methodology#event-level).

## 3. Sources

The system reads public sources, grouped by role. The role determines two things: **how much** the source weighs in the attention signal and **whether it can confirm** a vulnerability or its exploitation. Only official bodies, CERTs and vendors can confirm that a vulnerability exists; research labs can also confirm active exploitation; press and social media contribute to attention but cannot confirm anything on their own.

| Role | Sources | Weight | Confirms |
| --- | --- | --- | --- |
| Official | NVD (NIST), CISA KEV catalogue, CISA advisories, CERT-EU, CERT.at, Zero Day Initiative, GitHub Security Advisories (reviewed), Wordfence Intelligence, CERT-FR, NCSC-NL, INCIBE-CERT, CERT Polska, Canadian Centre for Cyber Security, VulnCheck KEV and ENISA EUVD (only vulnerabilities missing from the CISA catalogue or reported earlier) | — | Yes |
| Vendors | Microsoft (MSRC), Google Chrome, GitLab, Siemens, Mozilla, Atlassian, Google Cloud, Node.js | — | Yes |
| Research | watchTowr, Cisco Talos, Google Project Zero, GreyNoise, Kaspersky (Securelist), Volexity, SANS Internet Storm Center, Unit 42 by Palo Alto Networks | 2.5 | Active exploitation yes, existence no |
| Public exploits | Exploit-DB, Nuclei templates, Metasploit modules | — | No |
| Code | GitHub repositories with proof-of-concept code (PoC) | 1.2 | No |
| Trade press | The Hacker News, Help Net Security, SecurityWeek, The Record, Dark Reading | 1.2 | No |
| Social | Mastodon (#cve, #vulnerability, #zeroday, #infosec, #cybersecurity), Bluesky; authoritative accounts: Shadowserver, GreyNoise, watchTowr, Will Dormann, Kevin Beaumont | 1 (authoritative accounts 2.5) | No |

VulnCheck KEV data are used under VulnCheck's terms, which require attribution: **VulnCheck KEV** (vulncheck.com). Data from the European catalogue of exploited vulnerabilities are reused under ENISA's legal notice, with attribution: **ENISA EUVD** (euvd.enisa.europa.eu).

Enrichment: for each vulnerability the system also reads the **EPSS** exploitation probability published by FIRST and the official record on cve.org.

The live console on the home page shows how many sources responded in the last 24 hours. The list grows over time: every addition is recorded in [section 14](https://defencelevel.com/index/methodology#versions).

## 4. The collection cycle

- **Every 30 minutes**: fast sources (research, press, public exploits, code, social).
- **Every hour**: official and vendor sources (NVD, CISA KEV, Microsoft, GitHub Advisories, CERTs, vendor advisories).
- **Every 12 hours**: Wordfence Intelligence, the vulnerability database for WordPress plugins and themes.
- **At every collection** each affected vulnerability is re-assessed and the current level is recalculated over the last 24 hours.
- **At 04:00 UTC**, every day of the year, the level of the day and the content of the briefing are set, with the data collected up to that moment; **at 05:00 UTC**, after the check, the briefing is sent to subscribers.

Each report collected records a source, a point in time, one or more vulnerabilities mentioned (identified by their CVE code), and some indicators taken from the text, such as an explicit mention of active exploitation. Reports are never deleted: the calculation always uses the full history. A report attributed to a vulnerability by mistake, for example a notice about other vulnerabilities that mentions it only as context, is excluded from the calculation for that vulnerability after verification: the correction is recorded and the level is recalculated with the same rules. In a bulletin covering several vulnerabilities, one that has been exploited for at least 7 days (KEV catalogue or first confirmation), mentioned alongside new ones (published less than 14 days earlier or not yet published) and not named in the title of the notice, is a reference and not a signal: that report does not count for it. An official or vendor notice published within 48 hours after the publication of the vulnerability is the notice about it: it is excluded only if it wrongly attributes exploitation to it. The CISA announcement of additions to the KEV catalogue counts only for the vulnerabilities that the catalogue lists with its date (or with the day before, because of time zones): for the others it mentions, it does not count.

## 5. Analysis of each vulnerability

Each vulnerability is assessed on four axes, each from 0 to 10.

### 5.1 Technical severity (S)

This is the official CVSS score. If the CVE record has not been published yet but an official advisory, from a national CERT or the vendor, confirms the vulnerability, the severity stated in the advisory applies: its CVSS score, or else the minimum of the stated class (critical 9, high 7, medium 4, low 0.1); the affected product and whether the attack needs no credentials are taken from the same advisory. Otherwise it is estimated from the category of the vulnerability (for example: remote code execution 9; authentication bypass 8.5; arbitrary file write 8.5; privilege escalation 7.5; information disclosure 5.5; cross-site scripting 4.5), with −1 if difficult prerequisites are needed (administrative credentials, local or physical access) and +0.5 if it can be attacked over the network without credentials. “Attackable over the network without credentials” comes from the CVSS vector, but does not apply if the vendor writes that local access, privileges or an account already obtained, or an authenticated client, are needed: then the difficult prerequisites count. If the CVE record has neither vendor nor product, those written in structured form by the exploited-vulnerability catalogues and ENISA EUVD apply; next, the affected products written in the record itself or by NVD, if they name a single vendor (with only the products of a Linux distribution, which includes the component, the more severe assessment applies); without them, the product named in the titles of the advisories and catalogues, with its vendor when it is a known product. If it has no description, the category is taken from the titles of the advisories.

### 5.2 Real-world exploitation (E)

Depends on the most advanced documented status:

| Status | When | Value |
| --- | --- | --- |
| Actively exploited | Listed in the CISA KEV, VulnCheck KEV or ENISA EUVD catalogue, or active exploitation reported by an official, vendor or research source | 10 |
| Weaponised | Exploit in Exploit-DB, Metasploit module or Nuclei template. A detection-only Nuclei template ("passive": it recognises the installed version, it does not attack) does not count. An Exploit-DB exploit without a CVE code is linked to the CVE for the same product and the same type of flaw only if there is just one in the last 120 days | 8 |
| Credible proof of concept | Proof-of-concept code from reliable authors or with a real following (at least 10 GitHub stars, or 3 after two days), or an "Exploit" reference in the NVD record. Never credible: decoys (password-protected archives, executables to download, sales), serial authors (5 or more repositories within hours), accounts less than 30 days old | 6.5 |
| Unverified exploit | Code repositories from unknown authors | 4.5 |
| No exploit | — | 3.5 if attackable over the network without credentials, otherwise 2 |

The value rises to 10 × EPSS if the EPSS probability is higher, and to at least 6 if the vulnerability is in the top 5% by EPSS. It drops by 1.5 if difficult prerequisites are needed (unless actively exploited) and by 1 if the CVSS attack complexity is high.

"Active exploitation" in a text is recognised from explicit expressions ("exploited in the wild", "actively exploited", "under active exploitation" and similar). It counts only if the source is official, a vendor or research; if only the press, or at least two different social media accounts, say so, the vulnerability stays under observation marked "exploitation reported, not confirmed", and never goes into the noise. It is also recognised in Italian, French, Spanish, German and Dutch, the languages of the CERTs we read, and does not count when negated ("not aware of active exploitation", "n'a pas connaissance d'exploitation"). In bulletins covering several vulnerabilities it counts only for those named in the sentence about exploitation; if that sentence names none, it counts for all of them if there are no more than three and, if there are more, only for the one whose paragraph contains the sentence, when the bulletin describes them one by one. A press article or social media post that names only other CVEs in its title or first lines does not count as a report of attacks on the vulnerabilities it mentions further on, unless the sentence about exploitation names them. In list-style summaries it counts only for the vulnerability on the line that contains it, and it does not count when it only describes what the flaw would allow ("lets attackers…"). A research article whose title names other CVEs and not this one mentions it as context: it is not a signal for it. A research or press article about a vulnerability in the CISA KEV catalogue for more than 30 days mentions it as context and does not count for it, unless the title or the address names the vulnerability, its product or its vendor, or speaks of attacks, or, in a text about several vulnerabilities, the sentence about exploitation names it. The same holds for any vulnerability when a research article mentions only that one, without naming it, its product or its vendor in the title or the address and without reporting attacks: it cites it as context and, like a reference, does not count for it.

### 5.3 Impact (I)

Starts from the category (code execution 9.5; authentication bypass 9; supply-chain compromise 9; arbitrary file write 8.5; privilege escalation, memory corruption, SQL injection 7; …) and is adjusted by the reach of the product (see [section 6](https://defencelevel.com/index/methodology#reach)): +1.5 near-universal components, +1 edge devices, 0 common products, −1.5 niche products, −4 low-impact vulnerability generators. +1 if used by ransomware groups according to CISA, +0.5 if attackable over the network without credentials. Execution of arbitrary commands counts as code execution, including when it results from an SQL injection.

### 5.4 Attention (Z)

Measures how much professionals have discussed it in the last 24 hours. Research, code, press and social mentions count, each weighted by the role of its source (table in section 3), and each account, outlet or author counts only once, with the highest weight among its mentions, even when it posts on several social networks under the same username; official, vendor and exploit-archive notices already feed severity and exploitation, and do not count here:

```
Z = 3 × log₂(1 + sum of mention weights in the last 24 hours)
    + 1   if that sum is at least 4 and at least 60% of the 7-day sum (sudden spike)
    + 0.5 if at least 4 independent sources (section 8) of any role reported it in the last 30 days
(maximum 10)
```

The logarithm prevents a thousand repeated posts from counting a thousand times more than one.

Accounts that republish vulnerability records instead of discussing them do not count: those that wrote about at least 20 different vulnerabilities in the previous 7 days, except the authoritative accounts in section 3. The same text posted by different accounts a few minutes apart, as an outlet does with several profiles, counts as one account.

### 5.5 Combined score

```
score = 0.35 × S + 0.30 × E + 0.25 × I + 0.10 × Z
```

The weights favour severity and real-world exploitation; attention counts for only 10%, so as not to reward noise. These are methodological choices, declared here and validated after the fact ([section 12](https://defencelevel.com/index/methodology#validation)). The score is used to choose which vulnerabilities enter the briefing (7.0 for the main ones, 5.8 for "worth watching"); the **level**, on the other hand, follows the explicit rules of section 8.

## 6. Widely used and targeted products

A vulnerability matters more if it affects a product used by many organisations and historically targeted by attackers. The classification combines a public list by product **type** with an objective **attack history**:

| Class | What it includes | Condition |
| --- | --- | --- |
| Near-universal | Operating systems, browsers, base components (OpenSSL, glibc, OpenSSH…), WordPress | From the list |
| Edge devices | Firewalls, VPNs, gateways, mail and collaboration, remote access, file transfer, virtualisation | From the list, with at least 2 exploited vulnerabilities in 5 years in the CISA KEV catalogue |
| Common | Widely used business software (CMS, databases, containers, web applications) | From the list, with at least 2 exploited vulnerabilities in 5 years; or any product with at least 3 exploited vulnerabilities in 5 years |
| Niche | Everything else | — |
| Noise | Projects that generate vulnerabilities at industrial volume with minimal real impact | From the list, unless at least 3 exploited vulnerabilities in 5 years |

The attack history is taken from the CISA Known Exploited Vulnerabilities catalogue: it counts the vulnerabilities with confirmed exploitation added in the last 5 years. The count is redone automatically on the first day of each month (UTC) and stays fixed for the whole month; each month's snapshot is kept. A product that attackers target therefore enters the classification even if it was not on the list, and a listed product with no attack history is not overrated. The vendor is recognised without its company form, however the source writes it: “PHP Group” is PHP, “SAP SE” is SAP, “IBM Corporation” is IBM.

The class from the list applies to the products of whoever makes the platform: Windows from Microsoft, Android from Google or from the manufacturers that install it on their phones, system components (OpenSSL, glibc, sudo…) also from the Linux distributions that include them. A third-party product that mentions its name does not inherit it: a Python library is not Python, an Android app is not Android. Nor is a project whose name joins the platform's name to another word with a hyphen (node-openssl is not OpenSSL), which does not take on its vendor's attack history either, unless the product carries the platform's name on its own. The same applies to add-on components (plugins, extensions, themes, add-ons): a WordPress plugin is not WordPress. These products are classified in their own right, with their own attack history. Vendor and product are those of the CVE record, except in two cases where those of the CISA KEV catalogue apply: the record lists more than three products (Microsoft lists every version of Windows), or it names a vendor unrelated to the catalogue's, usually a product that embeds the affected component (Apache Struts, not the Huawei device that contains it). The catalogue's generic names ("Multiple Products") never apply.

A vulnerability that affects several products from the same vendor is assessed with the class of each, and the most severe result applies: a Bamboo flaw that also affects Confluence and Jira counts as a flaw in an edge device. The affected products are those named by official sources (CVE record, NVD, CISA KEV catalogue, vendor advisories), excluding those the record declares not affected; products from other vendors, such as systems that bundle an affected library, and the catalogue's generic names do not count.

For vendors with a broad catalogue (Cisco, Fortinet, Ivanti, Citrix, Palo Alto Networks, F5, Juniper, VMware, ConnectWise) the vendor's name in the list of edge devices applies only to its products with their own attack history, at least 2 exploited vulnerabilities in 5 years: a Cisco firewall yes, a data-centre switch or a licence server no. Its other products count as common products.

Switches and access points of the internal network are not edge devices, even from vendors whose products otherwise count as such: they are common products. They are recognised by the product name or, for Zyxel, by the model code.

A vendor that is the brand of a known product (for example NetScaler, from Citrix) counts as that product of its owner, with its history. The Linux kernel counts as such even when the CVE record calls it just "Linux".

## 7. Keeping alarmism in check

A vulnerability cannot raise the level if it falls into one of these cases:

- **Unconfirmed**: widely discussed, but no official source or vendor has confirmed it. If the press reports a vendor security update, however, it goes among those worth watching.
- **Rejected or disputed** in the CVE registry, unless it is in the CISA KEV catalogue or has a vendor advisory: then it is assessed like any other.
- **Sensationalist**: headline language ("catastrophic", "billions of devices at risk"…), no exploitation or credible exploit, severity below 7 or niche product, when the attention is not explained by an official or vendor advisory from the last 3 days.
- **Fake or unverified exploit** widely shared, with severity below 9, when the attention is not explained by an official or vendor advisory from the last 3 days.

These cases go into the "Much discussed, but no cause for alarm today" section of the briefing, with an explanation of why they are not an emergency. The exception is a vulnerability for which the press, or at least two different social media accounts, report attacks: even if they are not confirmed, it goes among the vulnerabilities worth watching, never into this section. The editors can move an entry from this section to the vulnerabilities worth watching, never the other way round; no level changes.

In addition, an **old** vulnerability (published more than a year ago, or with a CVE code from two years earlier) is not news, unless CISA has just confirmed its exploitation: in that case it can reach level 3 at most.

## 8. The level of each vulnerability

Conditions are evaluated from top to bottom; the first one met applies. Only confirmed vulnerabilities not classified as noise can rise above level 5.

| Level | Conditions (all required) |
| --- | --- |
| 1 | Actively and recently exploited · not old · severity ≥ 9 · attackable over the network without credentials · near-universal component · very high attention (Z ≥ 7) or confirmation from at least 3 official sources |
| 2 | Actively and recently exploited · not old · serious (CVSS ≥ 8, or code execution, authentication bypass or memory corruption if CVSS is missing) · reachable from the internet (network without credentials, or edge device) · and also one of: **near-universal component** with broad attention (Z ≥ 4.5 or at least 3 independent sources); **edge device in a documented campaign**, i.e. exploitation reported by at least 2 independent sources besides the CISA KEV, VulnCheck KEV and ENISA EUVD catalogues, or very high attention (Z ≥ 7); **edge device used by ransomware groups** according to CISA |
| 3 | Widely used product (near-universal, edge or common) · not old · actively and recently exploited, **or** critical severity (CVSS ≥ 9) with a public or weaponised exploit. Also: an old vulnerability just added by CISA to the KEV catalogue, on a widely used product |
| 4 | One of: actively exploited on a niche product · serious (CVSS ≥ 7) on a widely used product · serious and widely discussed (Z ≥ 6) · combined score ≥ 5.8 with severity ≥ 4 |
| 5 | None of the above |

**"Recent"** means: added to the KEV catalogue no more than 14 days ago, or published no more than 30 days ago, or with a new exploitation report from an official, vendor or research source in the last 72 hours. Long-known exploitation is a known problem, not news.

**Independent sources** (broad attention for level 2 and the half point of attention): each source counts once; social networks together count as a single source, because attention already measures how much it is discussed; the CISA announcement of an addition to the KEV catalogue is the KEV catalogue; the VulnCheck KEV catalogue does not count if the evidence it cites comes from a source already present. The same username on several social networks is a single author.

Level 2 distinguishes an attack on _one product_ from a _broad-impact_ threat. An edge device under attack (a firewall, a VPN, a gateway from a given vendor) is an emergency for those who use it: those who list it among their products in My Defence, with “Only my products”, get the alert at once, and everyone finds it in the day's briefing; but on its own it does not take the global index to severe risk, which is reserved for near-universal components and campaigns documented by several sources.

It follows that a serious vulnerability in a widely used product never drops to level 5, and that a critical vulnerability with a public exploit in a widely used product is at least level 3 even before attacks are observed.

## 9. The level of the day

### 9.1 The level at a given moment

At any moment the level is the most severe among those of the vulnerabilities in the briefing: the **new** ones and those **still ongoing**, the latter one step lower:

```
level = minimum( levels of the new vulnerabilities,
                 level + 1 of the vulnerabilities still ongoing,
                 5 )
```

**Main vulnerabilities** are confirmed vulnerabilities with a combined score of at least 7.0 or with level 3 or more severe. Critical vulnerabilities (severity ≥ 9) on an edge device, attackable over the network without credentials and published no more than 30 days ago, are main too, even without known attacks: they keep their level and carry the advice to update within the week. Those "worth watching" appear in the briefing but do not determine the level. A report without a CVE code on a product that already has a vulnerability with a CVE code in the briefing is the same news: it appears neither as an item of its own nor among those worth watching. Vulnerabilities in products classified as noise are never main, unless they are in the CISA KEV catalogue. Vulnerabilities of the same product mentioned together with a main vulnerability in the same official, vendor or research notice of the last 7 days, with at most 5 vulnerabilities, join its item even if they would not be selected on their own: they are the same attack chain. The level of the day does not change.

The time of the news is the latest of: publication of the vulnerability, addition to the KEV catalogue (+12 hours), the last official, vendor, research or exploit signal, and "now" if there are at least 3 mentions in the last 24 hours. A vulnerability that is still being discussed therefore stays in the news; one that is no longer discussed drops out of the calculation. A notice republished by the same source with the same title within 30 days is not a new signal; an update with a different title is. The date of each signal is the one on which the source published it; an item without a readable date counts as new only the first time it appears. A signal without a reliable date (unreadable, before 1999, more than one day in the future, or identical to the millisecond on at least three different advisories of the same source about different vulnerabilities: that is the time the source updated its feed) counts for what it says, not for when: it does not make a vulnerability topical and does not confirm its exploitation, which stays reported and unconfirmed until a dated source confirms it.

To stay at level 1 or 2, and at level 3 because of active exploitation, however, a vulnerability needs a strong signal in the last 24 hours: publication, addition to the KEV catalogue (+12 hours), or an official, vendor, research or exploit signal. If it is in the news only because it is being discussed, it counts one step lower, in the level of the day and in the briefing.

At level 4 or 5, a vulnerability that is current only because it is being discussed, with no strong signal for more than 7 days, is not a main one: it appears among those worth watching and does not set the level.

**New in the last 24 hours.** Among the main vulnerabilities in the news in the last 24 hours, the new ones are those never among the items of the briefings of the previous 30 days, those with a strong signal in the last 24 hours and those with a more severe level than the last time, unless only discussion has raised it. A vulnerability already reported that is back in the news only because it is being discussed, on social media or in the press, is not new and does not come back in the briefing; if the discussion has raised its level, it appears in one line, like those still ongoing, which says so. The same rule applies to the vulnerabilities worth watching: one already in the briefings of the previous 30 days comes back only with a strong signal in the last 24 hours. A vulnerability never reported that in the last 24 hours has only been discussed goes among those worth watching, unless it is at level 1–3 (exploited, or critical with a public exploit): then it is new, even if it was already among those worth watching. A vulnerability more than a year old, in the CISA KEV catalogue for more than 30 days, comes back among those worth watching only with a strong signal in the last 7 days or if at least two accounts have written about it in the last 24 hours.

**Still ongoing.** An actively exploited vulnerability at level 1–3, already reported and with no strong signal in the last 24 hours, stays in the briefing for 72 hours after its last strong signal, in one line, even if nobody discusses it; on the last day the line says so. In the level it counts one step lower: anyone who has not yet patched is still exposed. A new strong signal brings it back among the new ones. If its product has a new vulnerability, it appears in the same item. The other vulnerabilities already reported, with nothing new, leave the briefing.

**Other exploited vulnerabilities.** The briefing has at most 8 new items, the most severe, and at most 8 “still ongoing” lines. The actively exploited vulnerabilities (confirmed exploitation or KEV catalogue) left out appear in a separate section, one line per vulnerability, the most severe first, at most 60; the others stay out. The level of the day already includes them. They count as reported: like the others, they return among the new items only with a strong signal in the last 24 hours or a more severe level.

Under the level, the briefing says what it was in the previous briefing and which vulnerabilities set it.

When the briefing reports a product, it also recalls the other vulnerabilities of the same product exploited in the last 60 days (KEV catalogue or first exploitation) that are not in today's briefing: at most 6, the most recent, with the date since which they have been exploited. It is only a reminder: it changes neither the product's level in the briefing nor the level of the day.

### 9.2 The level of the day in the index

The level of a day (calendar day in UTC) is the one **set at 04:00 UTC** and communicated to subscribers in that day's 05:00 briefing. It never changes afterwards. If the collections during the day detect a more severe level, the Index shows it as the peak of the day, with the time in UTC, without changing the day's level.

The current level shown live is instead recalculated at every collection: an emergency that emerges after the briefing appears immediately in the current level, is sent to subscribers as an immediate alert, and shows in the index on the following day.

Alerts are sent at DEFCON 1, 2 and 3: DEFCON 1 to every subscriber; DEFCON 2 to those who receive every alert and, for those who chose “Only my products” in My Defence, only when it concerns their products; DEFCON 3 only to those who chose “Only my products”, and only when it concerns their products. At DEFCON 4 and 5 no alert is sent: the vulnerabilities are in the day's briefing. Alerts are sent only on a strong signal from the last 24 hours. If the vulnerability was already among the briefing's items and no new strong signal has arrived since, a more severe level reached afterwards (for example because it is discussed more) does not trigger a DEFCON 2 or 3 alert: the next briefing reports it. DEFCON 1 is always sent. If exploitation is confirmed only by the VulnCheck KEV catalogue and the evidence it cites is only social media posts, aggregator pages or vulnerability databases (such as the CVE record), which describe the flaw but do not prove an attack, the vulnerability stays in the briefing at its level, but the alert waits for a second source: the CISA KEV catalogue, a CERT, the vendor or a research report.

In the 24 hours after a DEFCON 1 or 2 alert has been sent, the vulnerability does not fall below the level it had at the time of the alert merely because time passes, for example because mentions drop out of the 24 hours: that level is recalculated with today's data, and it falls only if a fact has changed, such as a source item excluded after verification, a rejected CVE or a lower official CVSS. In the briefing of those 24 hours the alert counts as a strong signal: the vulnerability stays among the new items, at the level of the alert.

## 10. The role of artificial intelligence

The level, the selection and the order of vulnerabilities are calculated **only** by the deterministic rule described on this page: given the same data, the result is always the same, and artificial intelligence never decides them. We use it for editing: before sending, an artificial intelligence system checks every briefing and every alert against our data (products, evidence of exploitation, dates, prerequisites) and writes their texts. If it finds a report attributed to the wrong vulnerability, it excludes it, and the level is recalculated by the rule. If the data do not confirm an alert, the alert is not sent. Briefings and alerts are sent only once the check is complete: if it is not ready, sending waits.

## 11. History of the Index

Each day's level is calculated with the rules described on this page, using only the data the sources had published up to that day: no later information enters the level of a past day.

## 12. Validation of results

We validate the method by comparing its levels with the CISA KEV catalogue, the list of vulnerabilities whose real-world exploitation is confirmed. We measure how many exploited vulnerabilities the method brings to level 3 or higher, how early or late compared with official confirmation, and how many of those brought to level 2 or 1 turn out to be exploited.

The validation is done in two ways, with the catalogue among the sources, as the service works, and without it, as an independent check, and it is repeated with every version of the method.

## 13. Stated limitations

- **Source coverage.** The system sees only what is public and written in the sources it reads. Attacks not yet disclosed, or disclosed only in closed channels, are not visible.
- **Dependence on CVE codes.** Vulnerabilities without a CVE code are recognised only if they mention a known product; they may be underestimated. Product names that are also common words (Teams, Outlook, Zoom, Entra) count only with the vendor or a qualifying word, as in “Microsoft Teams”. An exploit without a CVE does not raise the level on its own: it counts only together with other signals on the same product.
- **Language recognition.** Active exploitation in texts is recognised from explicit expressions in six languages (English, Italian, French, Spanish, German, Dutch); unusual wording or other languages may be missed.
- **Weights and thresholds.** They are methodological choices, not physical quantities: they are declared, stable over time and validated after the fact, but a different method would give different levels.
- **Attack history.** The CISA KEV catalogue reflects the priorities of the US government and its ability to confirm; products widely used outside the United States may be under-represented.
- **Products with different names.** Matching vendor and product names across sources is automatic and can be wrong in ambiguous cases.
- **Levels before 1 October 2026.** They depend on how much the sources retain of past days: some sources have no searchable history and, for a fair comparison over time, social media count only for hashtags with a complete history (#vulnerability, #zeroday), with at most 30 mentions per day. Levels in that period may therefore underestimate the risk.

## 14. Versions and changes

The methodology has a version number. Every change that can alter a level is recorded here with its date; levels already published are not silently rewritten: if a new version changes past levels, it says so.

| Version | In force since | Changes |
| --- | --- | --- |
| 1.30 | 2026-11-04 | Accounts that republish vulnerability records (at least 20 different vulnerabilities in 7 days) no longer count towards attention, except the authoritative accounts, and the same text posted by different accounts a few minutes apart counts only once. Switches and access points of the internal network are common products, not edge devices. A vulnerability more than a year old, in the CISA KEV catalogue for more than 30 days, comes back among those worth watching only with a strong signal in the last 7 days or with at least two accounts. In the 24 hours after a DEFCON 1 or 2 alert the level does not fall merely because time passes, and in the briefing the alert counts as a strong signal. The CISA announcement about the KEV catalogue is recognised even when it announces a single vulnerability. On the briefings from 22 October to 4 November the level of the day stays that of the previous version, except on 1 November: 3 instead of 2, as in the briefing sent that day. No published level is rewritten. |
| 1.29 | 2026-11-03 | A vulnerability already reported whose level rises only because it is discussed more is no longer among the new items: it appears in one line, like those still ongoing, which says so. A research article that mentions only one vulnerability, without naming it, its product, its vendor or an attack in the title or the address, cites it as context and, like a reference, does not count for it. No level changes, not even on past days: the line counts in the level as the item did, and the second rule applies to reports collected from 3 November. |
| 1.28 | 2026-11-02 | The CISA announcement of additions to the KEV catalogue counts only for the vulnerabilities that the catalogue lists with its date: on 29 October it had also been linked to a vulnerability added to the catalogue the following day. Across the whole history (31 announcements since 25 September) this is the only case, already excluded after verification: no published level changes. |

**Earlier versions (28)**

| Version | In force since | Changes |
| --- | --- | --- |
| 1.27 | 2026-11-01 | The same username on several social networks counts as a single author in attention, and the sources for broad attention (level 2) and for the half point of attention are independent: social networks together count as one source, the CISA announcement about the KEV catalogue is the KEV catalogue, and the VulnCheck KEV catalogue does not count if the evidence it cites comes from a source already present. Applied to the 401 briefings in the history, the new rule changes no published daily level. |
| 1.26 | 2026-10-31 | A DEFCON 2 or 3 alert for a vulnerability already among the briefing's items is sent only if a new strong signal (KEV catalogue, official or vendor source, research, exploit) has arrived since the briefing: a level raised only because the vulnerability is discussed more is reported in the next briefing. DEFCON 1 is always sent. No level changes, not even on past days. |
| 1.25 | 2026-10-29 | In a bulletin that describes more than three vulnerabilities one by one, an exploitation sentence that names none of them counts for the one whose paragraph contains it, as preconditions already do: before, it counted for none. No level changes, not even on past days. |
| 1.24 | 2026-10-27 | A vulnerability discussed in sensationalist terms no longer goes into the "Much discussed, but no cause for alarm today" section when the attention is explained by an official or vendor advisory from the last 3 days, as already for unverified exploits since version 1.9: it is assessed like the others. No level changes, not even on past days. |
| 1.23 | 2026-10-25 | Each signal counts from the date on which the source published it, including when the feed writes the time zone in letters (CEST, CET): before, without a readable date, it took the time of collection. An item without a readable date counts as new only the first time it appears, and on a source's first run its already published past does not enter as news; an advisory page that must be read in full and cannot be read waits for the next run, instead of becoming a signal without a CVE identifier. A signal without a reliable date (unreadable, before 1999, more than one day in the future, or identical to the millisecond on at least three different advisories of the same source about different vulnerabilities) counts for what it says, not for when: it does not make a vulnerability topical and does not confirm its exploitation. The weak evidence cited by the VulnCheck KEV catalogue now includes vulnerability databases, such as the CVE record: the level stays, the alert waits for a second source. Declared correction: on 24 October at 10:07 UTC, CERT-EU advisories published between April and October had entered as signals of the last 24 hours. The level of 25 October changes from DEFCON 2 to DEFCON 3, and the current level shown since 10:07 UTC on 24 October returns to DEFCON 3; the briefings of 11 and 20 October lose a DEFCON 4 item that came from the same advisories, without changing the level of those days. No other level changes, not even on past days. |
| 1.22 | 2026-10-25 | New vendor source: the Node.js security releases; CERT-EU advisories are read in full, so that they are linked to their CVE codes, and a report without a CVE code on a product that already has an item in the briefing no longer appears among the vulnerabilities worth watching. No level changes, not even on past days. |
| 1.21 | 2026-10-24 | In texts without a CVE code (reports, news, advisory titles), product names that are also common words, such as Teams, Outlook, Zoom, Entra, React, Rails, Vault, Slack and PuTTY, count only in the form that really names the product, with the vendor or a qualifying word (“Microsoft Teams”, “Outlook.com”, “Microsoft Entra ID”, “HashiCorp Vault”): “security teams” or “2026 Data Breach Outlook” are no longer reports about a product. No level changes, not even on past days. |
| 1.20 | 2026-10-23 | The vendor name is compared without its company form (“PHP Group” is PHP, “SAP SE” is SAP, “IBM Corporation” is IBM), also with the names in the CISA KEV catalogue: the attack history and the reach of a product no longer depend on how the CVE record writes the company name. From the same version, the quick notice at DEFCON 3 for everyone is no longer sent: at DEFCON 3 an alert goes only to those who chose “Only my products” in My Defence, and only on their products; the other vulnerabilities are in the day's briefing. |
| 1.19 | 2026-10-22 | Actively exploited vulnerabilities left out of the 8 new items or the 8 “still ongoing” lines appear in a separate section, “Other exploited vulnerabilities”, one line each, and count as reported; a research or press article that mentions in passing a vulnerability in the CISA KEV catalogue for more than 30 days does not count for it; the reminder of the other exploited vulnerabilities of the same product includes all those of the last 60 days that are not in the briefing, reported before or not, up to 6. |
| 1.18 | 2026-10-20 | The briefing reports what is new: a vulnerability already reported in the previous 30 days comes back among the items only with a strong signal in the last 24 hours or a more severe level, never only because it is being discussed, and the same applies to those worth watching, where a vulnerability never reported that has only been discussed also goes; exploited vulnerabilities at level 1–3 with nothing new stay "still ongoing", in one line, for 72 hours after their last strong signal, and count one step lower in the level, replacing the carry-over rule, which kept the level one step lower for two days after the last news; under the level, a line says what it was in the previous briefing and what sets it. |
| 1.17 | 2026-10-20 | A CVE record with neither vendor nor product is also assessed with the affected products written in the record itself or by NVD, when they name a single vendor, before the product taken from advisory titles; the Linux kernel counts as such even when the record calls it just "Linux"; a project whose name joins a platform's name to another word with a hyphen takes on neither its prevalence class nor its attack history; util-linux and Linux-PAM are among the near-universal components. |
| 1.16 | 2026-10-19 | A press article or social media post that names only other CVEs in its first lines, or a list-style summary that states exploitation on another line, no longer counts as a report of attacks on the vulnerabilities it mentions, nor does a research article titled after other CVEs; a CVE record with neither vendor nor product is assessed with those written in structured form by the exploited-vulnerability catalogues or ENISA EUVD, or with the product named in the advisories together with its vendor; the recall of the product's other exploited vulnerabilities looks back 60 days instead of 30. |
| 1.15 | 2026-10-18 | A vulnerability rejected or disputed in the CVE registry, but in the CISA KEV catalogue or with a vendor advisory, is assessed like any other instead of being listed among the widely discussed ones with no reason for alarm, and so is a not yet confirmed one for which the press reports a vendor security update, which goes among those worth watching. |
| 1.14 | 2026-10-17 | A vulnerability that affects several products from the same vendor is assessed with the prevalence class of each, and the most severe result applies, instead of only the class of the product listed first in the CVE record. |
| 1.13 | 2026-10-15 | A vulnerability with attacks reported by the press or by two different accounts goes among those worth watching, never into the noise; passive Nuclei templates, references to already exploited flaws in bulletins covering several vulnerabilities and repeated posts from the same account no longer count; an SQL injection that leads to command execution counts as code execution; vendor and product come from the CISA KEV catalogue when the CVE record says otherwise; vulnerabilities of the same attack chain join the same item; new research source: Unit 42 by Palo Alto Networks. |
| 1.12 | 2026-10-13 | When the briefing reports a product, it also recalls the product's other vulnerabilities exploited in the last 30 days and already reported, without changing any level. An alert based only on VulnCheck KEV with weak evidence waits for a second source. |
| 1.11 | 2026-10-11 | The level of the day and the content of the briefing are set at 04:00 UTC, an hour before the 05:00 sending, so that they can be checked before they are sent. |
| 1.10 | 2026-10-10 | Prerequisites written by the vendor prevail over the CVSS vector, arbitrary file write is a category of its own, product and category are also taken from the titles of catalogues and advisories, exploitation reported in a bulletin covering several vulnerabilities counts only for those named in the sentence about it, execution of arbitrary commands is code execution, a report attributed by mistake to a vulnerability that a notice mentions only as context is excluded after verification, and at level 4 or 5 a vulnerability back on the list only because it is being discussed, with no strong signal for 7 days, is among those worth watching. |
| 1.9 | 2026-10-09 | Level 3 due to active exploitation, like levels 1 and 2, needs a strong signal in the last 24 hours, and an identical republished notice does not count as a new signal; the name of a vendor with a broad catalogue counts as an edge device only for its products with their own attack history; an unverified exploit no longer turns a vulnerability just reported in an official advisory into noise. |
| 1.8 | 2026-10-08 | For a vulnerability confirmed by an official advisory before its CVE record is published, severity, product and attack without credentials are taken from the advisory instead of being estimated; critical vulnerabilities on an edge device that can be attacked without credentials are always main, to be updated within the week. |
| 1.7 | 2026-10-07 | New sources: Wordfence Intelligence, the vulnerability database for WordPress plugins and themes, which often publishes them before NVD, and the SANS Internet Storm Center. |
| 1.6 | 2026-10-06 | To stay at level 1 or 2 a vulnerability needs a strong signal in the last 24 hours; one that is only being discussed counts one step lower. |
| 1.5 | 2026-10-05 | Updated source list, including the ENISA EUVD catalogue; posts from authoritative accounts weigh more in the attention signal; the name of a widely used platform counts only for its maker's products, while plugins and extensions are assessed on their own. |
| 1.4 | 2026-10-04 | New source: VulnCheck KEV, for exploited vulnerabilities not yet in the CISA catalogue; stricter rules for proof-of-concept exploits on GitHub. |
| 1.3 | 2026-10-03 | More sources (national CERTs, vendors, research labs, news outlets); active exploitation also recognised in Italian, French, Spanish, German and Dutch. |
| 1.2 | 2026-10-02 | The level of the day is set at 05:00 UTC all year round; Index days are calendar days in UTC. |
| 1.1 | 2026-10-01 | Level 2 reserved for broad-impact threats: near-universal components, or edge devices in a documented campaign. A single edge device under attack is level 3. |
| 1.0 | 2026-09-30 | First public version. |

## 15. Using and citing the data

Daily levels are public and reusable under the **Creative Commons Attribution 4.0 (CC BY 4.0)** licence, with attribution. The CSV file for the last 12 months can be downloaded from the DefenceLevel Index page and contains date, level, level name and number of vulnerabilities included in the briefing.

Suggested citation: `DefenceLevel Index (defencelevel.com), methodology v1.30`, with the date of the figure.

Details of individual vulnerabilities (names, products, recommended actions) are reserved for briefing subscribers.

---

Web page: https://defencelevel.com/index/methodology