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?
Emerging threats is rolling out progressively and is not yet enabled for every account. If you do not see it under Vulnerability Management, contact your JupiterOne account team.
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 ten CVEs currently trending, ranked. The card is headed Top 10 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 blends how recently a CVE crossed an escalation threshold with how dangerous it is, and lifts anything under confirmed active exploitation.
The escalation thresholds 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 |
Because the rank keys on transitions 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 week.
- An old, unremarkable CVE that picks up its first ransomware campaign today surfaces to the top.
Recency is one input to the rank, not the sort order. You cannot re-sort the list, and rows are always shown in the engine's ranked order.
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. 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.
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.