Emerging threats
Emerging threats answers a narrow question: of everything happening in the vulnerability landscape right now, what changed recently enough to deserve your attention today?
It is a threat intelligence view, not an inventory view. Nothing on it is scoped to your environment — it reports on the CVE itself, drawing on public and commercial threat intelligence sources. Use it to decide whether a CVE is worth reacting to, then use Unified Vulnerability Management to find out whether you are affected.
The view has two screens:
- The emerging threats list — up to 25 CVEs currently trending, ranked. The card is headed Top emerging threats.
- The threat brief — a full assessment of a single CVE. Open one from the list, or search for any CVE by identifier.
The emerging threats list
The list shows threats that recently got worse. It is not the most severe CVEs, and it is not the newest ones.
How trending is ranked
Ranking looks for evidence that a CVE's threat picture changed, and for how widely that change is being reported. A CVE earns credit for:
- A change in how it is being used: it was added to CISA KEV, a threat actor, ransomware group, or botnet was reported using it for the first time, or a weaponized exploit appeared.
- First confirmed exploitation.
- Independent reporting: how many separate organizations reported on it in the last 30 days. Several pages from one organization count once, and vulnerability catalogs do not count.
- New exploit code, weighted so that copies of one proof of concept do not inflate the rank.
- Recency of the latest evidence, as a small factor.
A CVE whose only recent activity is a catalog record update ranks lower.
Because the rank keys on changes rather than on state, the list behaves differently from a severity-sorted feed:
- A CVE that has been exploited steadily for years drops off — nothing about it changed this month.
- An old, unremarkable CVE that picks up its first ransomware campaign today surfaces near the top.
How long a CVE stays listed. A change earns full credit for 14 days, then fades out by day 30, so a major event slides down the list rather than dropping off overnight. If VulnCheck's canaries or honeypots observed exploitation attempts in the last 7 days, the fade runs to day 45 instead. Sensor activity alone never puts a CVE on the list.
New events are always listed. A CVE added to CISA KEV, weaponized, or first reported in use by a threat actor, ransomware group, or botnet within the last two days always appears, even when older events outrank it.
Campaigns share a row. When several CVEs in the same product are added to KEV within three days of each other, they appear as one row under the highest-ranked CVE.
You cannot re-sort the list, and rows are always shown in ranked order.
The escalation chips on each row are:
| Escalation | What it means |
|---|---|
| Public exploit | Working proof-of-concept exploit code became publicly available |
| Weaponized | A reliable, packaged exploit exists — no longer just a proof of concept |
| Exploited in the wild | Exploitation against real targets has been confirmed |
| Added to KEV | The CVE was added to CISA's or VulnCheck's Known Exploited Vulnerabilities catalog |
What each row tells you
Every row carries its own labels, so nothing on the list depends on a legend:
- The CVE identifier and, where a CPE record identifies one, the affected vendor and product.
- The escalations it has reached, as chips (see the table above). A chip you do not see means that escalation has not happened, or is not recorded.
- No scanner coverage, when no commercial scanner ships a check for the CVE. See Scanner coverage gaps.
- Why it ranked — the escalation that drove it onto the list, and how many days ago that happened. A CVE that ranked without a recent escalation says so.
- Its threat tier.
The Why it ranked line names the most recent change, which is more specific than the chips:
| Reason | What it means |
|---|---|
| Added to CISA KEV / Added to VulnCheck KEV | The CVE was added to that catalog. A CVE in both shows a line for each. |
| First threat actor report | A threat actor was reported exploiting the CVE for the first time |
| First ransomware report | A ransomware group was reported exploiting the CVE for the first time |
| First botnet report | A botnet was reported exploiting the CVE for the first time |
| First canary detection | VulnCheck's canary sensors saw exploitation attempts for the first time. This is shown for context; a sensor detection on its own does not rank a CVE. |
| First exploited in the wild | Exploitation was confirmed, with no single attacker class named |
| First weaponized | A reliable, packaged exploit appeared |
| Public exploit published | Proof-of-concept exploit code was published |
Threat tiers
Every ranked CVE and every brief carries one of four tiers. The tier is a stance on the whole CVE, and it is the same value in both places.
| Tier | Read it as |
|---|---|
| Act now | Confirmed, dangerous, and moving. Treat as time-sensitive. |
| Elevated | Escalating and worth planning around, but not an emergency today. |
| Monitor | Nothing yet demands action. Keep it in view. |
| Low | No meaningful exploitation signal. |
The threat brief
A brief opens with the verdict: the tier, a headline judgement, and a short narrative translating the intelligence into a decision. When automatable exploitation is a factor — meaning the exploit lends itself to mass, unattended use — the brief calls that out as a separate note, because it amplifies impact without changing the tier.
Below the verdict sit four reference metrics:
| Metric | What it reports |
|---|---|
| CVSS base score | The published severity score and rating |
| EPSS percentile | How this CVE's exploitation probability ranks against every other scored CVE. This is the percentile, not the probability itself. |
| Exploit maturity | None known, proof of concept, commercial, or weaponized |
| KEV | Whether the CVE appears in CISA KEV or VulnCheck KEV |
A metric with no published value reads Not scored. The brief never substitutes a guess for a missing number.
Brief sections
The rest of the brief is organized into eight sections.
Remediation guidance — how urgently to remediate, scored on CISA's four Stakeholder-Specific Vulnerability Categorization (SSVC) decision points. The resulting timeline is CISA's benchmark from Binding Operational Directive 26-04 (June 2026): binding for federal civilian agencies, and a useful yardstick for everyone else. Where the timeline depends on whether the affected asset is internet-facing, both branches are shown so you can pick the one that describes your deployment. When two intelligence sources disagree about a decision point, the disagreement is surfaced on the row it affects rather than resolved silently.
Exploitation timeline — how the threat matured, and how quickly defenders responded. The stages are disclosure, scanner checks shipping, public proof of concept, weaponized exploit, in-the-wild exploitation, and KEV listing. A filled dot happened; an outlined one has not. The stages are in a fixed order, so dates can legitimately read out of order — a CVE exploited in the wild before any scanner check shipped is common, not an error. A stage can also be marked as happened with an unknown date.
What it is — the published description, its CWE weakness classification, and a summary of the affected product and version footprint.
Who is using it — exploitation activity broken out by actor class: threat actors, ransomware, botnets, and public exploit repositories. Each class reports how much activity was observed, and — for threat actors, ransomware, and botnets — when it was first and most recently seen. Where named detail exists, you can open it in a side panel: specific actors with attribution country, ransomware families, botnets, and the exploit repositories themselves.
Can the ecosystem see it — per-scanner coverage: whether a check exists for this CVE and when it shipped. A patch and an EPSS score are useless if your scanner has no check.
Fix and mitigation — published patch and mitigation references.
Detection and investigation — whether detection tooling covers the CVE, and how it maps to detection frameworks and controls. If a public exploit needs no credentials and no user interaction, this section says so prominently.
Sources and provenance — when the brief was assessed, which sources were consulted, the underlying references, and source attribution.
Sections with no data available say so explicitly. An absent section is an absence of published intelligence, not an absence of risk.
Scanner coverage gaps
A no scanner coverage flag means no commercial scanner ships a check for that CVE. This matters more than it first appears: if no check exists, the CVE will not appear in your scan results whether or not you are affected. A clean scan is not evidence of absence.
Two things to know about how the flag is derived:
- It is computed from commercial scanners only. An open-source tool may well have a check for a CVE that is flagged as uncovered.
- The absence of the flag is not a promise of coverage — it only means there is no known commercial blind spot.
Data freshness
The two screens are refreshed differently, on purpose:
- The list is a snapshot, refreshed periodically rather than live. The header carries an "as of" timestamp so you always know how current the ranking is.
- A brief is assessed when you open it, because freshness is the whole point of an emerging threat. The assessment time appears in the brief's Sources and provenance section.