Why does one CVE page have a full analysis and another only scores?

A scoring step decides. It sums nine components into a 0-100 score: exploitation status, exploit probability, public exploit code, product criticality, risk score, advisory activity, recency, severity, attention. Any of these produces a full analysis: a KEV listing, weaponized exploitation, a score of 70 or more, or a critical product with five or more public exploits. A score under 34 gets no page, and neither does a record with no exploitation signal and a fix already widely deployed. The identifier still resolves to its catalog record. Everything in between goes on the watchlist, and its page says that no analysis has been published.

KEV, EPSS, CVSS and SSVC all appear on the page. Which one should I act on?

Read them in order. KEV first, because it is an observation and it comes with a remediation deadline. Then EPSS, the probability that exploitation will be seen in the next 30 days, which is what tells you whether something CISA has not listed deserves attention this week. CVSS ranks consequence rather than likelihood: how bad it would be if exploited. SSVC is CISA's judgement on exploitation status, automatability and technical impact. When they disagree, the disagreement is the finding. A critical CVSS at 2% EPSS with no KEV listing is a different problem from a medium CVSS that CISA has listed.

How current is the data?

Each source moves on its own clock, so every page shows its dates instead of promising a refresh rate. CISA listings arrive as CISA publishes them. Exploit probability is rescored daily. Analyses are rebuilt as records change. Every CVE page carries the dates it knows: published, KEV added, due, last changed. The board's date columns are the same fields, so you read recency off the record rather than inferring it from a badge.

Can I look up a CVE nobody has analysed?

Yes. Every scored CVE in the published catalog has a page. Search or paste an identifier and it resolves to what is known: CVSS and severity, EPSS with its previous value, weakness class, affected vendors and products, exploitation flags, and any reporting that names it. A line at the top says no analysis has been published, so you know which kind of page you are on.

What is the difference between the Emerging threats and Waiting list tabs?

Both hold CVEs CISA has not listed, where exploitation is probable rather than confirmed. Emerging threats are the ones queued for analysis. Waiting list is the rest: watched daily, no analysis yet. Both render as catalog records, which is why neither is offered to a search engine.

How do I find exploited vulnerabilities that nothing detects yet?

Type has:exploit -has:rule in the search box. That is public exploit code with no published Sigma or YARA rule: the window where an attack works and leaves nothing recognisable in your logs. Trends ranks the same gap by vendor, so you can see whose products carry the most of it right now. Two more worth keeping: epss:>90 -has:kev for high-probability vulnerabilities CISA has not listed, and is:overdue has:ransomware for past-deadline entries with recorded ransomware use.

Where do the exploit counts, threat actors and detection rules come from?

From public sources, each named on the page. Exploit entries come from repositories, exploit databases and framework modules, with weaponized repositories counted apart from demonstrations. Detection rules are published Sigma and YARA content. Threat groups and malware families appear when a credible public source ties them to the CVE. The ransomware flag is CISA's field on the KEV entry. Indicators come from threat exchanges. Where a field is empty the page shows the absence rather than a placeholder, and nothing inferred is presented as fact.

Is CVE Radar free, and does it scan my systems?

Free, no signup, and it scans nothing. What you get is public knowledge about vulnerabilities, organised: the registry record, the exploitation evidence around it, and the aggregate view over both. If you want to know about your own estate, the search dorks and scanner templates on a CVE page are the material to run against it.

CVE Intelligence

How it works

From a public advisory to the page you are reading

What gets collected, what decides whether a CVE gets a full analysis, what each score means, and where the data stops.

Pipeline

Six stages, one dataset

One dataset, six stages. SOCRadar runs the pipeline in the card above: the data in the first two stages is public, its own collection joins at Assemble and its taxonomy at Classify. The gate is the only place a record's fate is decided, and every surface reads what comes out of it.

1 · Collect

Public registries and evidence feeds are pulled on their own schedules.

2 · Keep a row for every CVE

Every scored CVE gets a row, so any identifier you paste resolves to something.

3 · Build the analysis

The records worth a full page are built into one enriched document each.

4 · Classify

Weakness class, exploit maturity and severity are resolved per record.

5 · Decide what gets analysed

A 0–100 score and two thresholds decide: full analysis, watch, or scores only.

6 · Serve

The same data feeds the board, the CVE pages, News, Trends and the dashboards.

What each stage does in full

1 · Collect Two halves. The registry half is the CVE record: identifier, description, weakness class, affected versions, references. The evidence half tells you whether it matters this week. Exploitation listings, exploit probability, published exploit code, detection rules, attributed groups, and the reporting that names the CVE.CISA Known Exploited Vulnerabilities catalog · NVD / MITRE CVE records and CNA advisories · FIRST EPSS full scoreset · CISA SSVC decision data · Public exploit repositories and scanner templates · Sigma / YARA rule publications · Threat exchanges (indicators), security press, public discussion

2 · Keep a row for every CVE Every published CVE gets a row — hundreds of thousands of them — with its scores, severity, weakness class, affected vendors and exploitation status. That is what makes any identifier answerable: paste a CVE nobody has analysed and the page still shows what is on record, and says that no analysis has been published.

3 · Build the analysis The set starts from the KEV catalog plus the CVEs queued for analysis. Building a page joins the registry facts to the evidence around them: exploit repositories and whether any are weaponized, detection rules, scanner templates, named threat groups, malware families, indicators, timeline entries, vendor remediation text, references.

4 · Classify Nineteen weakness classes, taken from the CWE data on the records themselves: memory corruption, remote code execution, authentication bypass, path traversal, and so on. Each record also carries an exploit-maturity lane (newly disclosed, proof-of-concept, active exploitation, resolved). If a record matches none of the nineteen it is labelled unclassified. Sweeping it into the biggest class would make that class useless.

5 · Decide what gets analysed Nine components are summed and clamped to 100. A record publishes on confirmed exploitation, on a strong score, or on a critical product with several public exploits behind it. It gets no page if the score is under 34, or if momentum is low: no KEV listing, a fix already widely deployed, low exploit probability, one exploit at most, little attention. Everything in between goes on the watchlist.

6 · Serve One dataset, five ways in. The board lists it. A CVE page shows one record of it. Hubs group it by vendor, product and topic. Trends aggregates the catalog behind it. The dashboards ask a role-shaped question of it.

What gets analysed

Why one CVE has a full analysis and another has only scores

Nine components are summed into a 0-100 score and checked against two thresholds. A KEV listing publishes on its own.

Each component's ceiling, laid end to end: 114 points of possible evidence, clamped to 100. Exploitation status alone carries a record most of the way to the publish threshold; attention cannot move it far.

Outcome	When	What the reader gets
Published	On the KEV catalog, or weaponized in the wild, or score ≥ 70, or score ≥ 62 with a strategic product and five or more public exploits.	Gets a full analysis: what it is, how it is being exploited, what to patch, and how to detect attempts.
Watchlist	Between the two thresholds. The signals justify watching it; the evidence does not yet justify a page of its own.	Shows up on the board's Emerging threats and Waiting list tabs. Its page shows the scores and scope on record, and says there is no analysis yet.
Not published	Score under 34, or low momentum: no KEV listing, fix widely deployed, exploit probability under 25%, at most one public exploit, little attention.	Keeps its row. The identifier still resolves to scores, scope and exploitation status, with no analysis on it.

Published

When On the KEV catalog, or weaponized in the wild, or score ≥ 70, or score ≥ 62 with a strategic product and five or more public exploits.

What the reader gets Gets a full analysis: what it is, how it is being exploited, what to patch, and how to detect attempts.

Watchlist

When Between the two thresholds. The signals justify watching it; the evidence does not yet justify a page of its own.

What the reader gets Shows up on the board's Emerging threats and Waiting list tabs. Its page shows the scores and scope on record, and says there is no analysis yet.

Not published

When Score under 34, or low momentum: no KEV listing, fix widely deployed, exploit probability under 25%, at most one public exploit, little attention.

What the reader gets Keeps its row. The identifier still resolves to scores, scope and exploitation status, with no analysis on it.

The nine components

Component	Max	What it measures
Exploitation status	26	Highest for a KEV listing, then weaponized in the wild, then public proof-of-concept, then newly disclosed.
Exploit probability	18	EPSS, applied proportionally. A 90% forecast contributes almost the whole ceiling.
Public exploit code	14	The number of exploit entries, with extra weight for repositories that are weaponized rather than illustrative.
Product criticality	14	Higher for edge and identity infrastructure than for a leaf application.
Risk score	12	SOCRadar's own score where it has one. Otherwise a score combined from CVSS, exploit probability, the KEV listing and public exploit evidence, labelled as such.
Advisory activity	10	Vendor, NVD and government advisories, plus whether the record has changed since disclosure.
Recency	8	Days since publication, in bands at three, ten and thirty days. An unknown date scores mid-band; an unknown age is neither fresh nor stale.
Severity	6	Critical or high CVSS severity. Small, because severity says what would happen, not whether it is happening.
Attention	6	Post volume and audience. Capped low, since chatter tracks awareness rather than risk.

Exploitation status

Max 26

What it measures Highest for a KEV listing, then weaponized in the wild, then public proof-of-concept, then newly disclosed.

Exploit probability

Max 18

What it measures EPSS, applied proportionally. A 90% forecast contributes almost the whole ceiling.

Public exploit code

Max 14

What it measures The number of exploit entries, with extra weight for repositories that are weaponized rather than illustrative.

Product criticality

Max 14

What it measures Higher for edge and identity infrastructure than for a leaf application.

Risk score

Max 12

What it measures SOCRadar's own score where it has one. Otherwise a score combined from CVSS, exploit probability, the KEV listing and public exploit evidence, labelled as such.

Advisory activity

Max 10

What it measures Vendor, NVD and government advisories, plus whether the record has changed since disclosure.

Recency

Max 8

What it measures Days since publication, in bands at three, ten and thirty days. An unknown date scores mid-band; an unknown age is neither fresh nor stale.

Severity

Max 6

What it measures Critical or high CVSS severity. Small, because severity says what would happen, not whether it is happening.

Attention

Max 6

What it measures Post volume and audience. Capped low, since chatter tracks awareness rather than risk.

The four signals

KEV, EPSS, CVSS and SSVC answer different questions

A CVE page shows all four together, so the cases where they disagree are the ones you notice.

Signal	Answers	Source	Changes when	Read it as
CISA KEV	Has this been exploited?	CISA, from incident reporting	When CISA adds an entry, or moves its due date	An observation. The strongest signal here.
EPSS	Will exploitation be observed in the next 30 days?	FIRST, model over the whole catalog	Daily rescoring — the page shows the previous value	A forecast. High and no KEV listing is the interesting case.
CVSS	How bad would it be if exploited?	The CNA or a scoring source, with its vector	Rarely, when a scoring source revises it	Consequence, not likelihood. Unscored means unscored.
SSVC	What should a defender do about it?	CISA, as a decision record	When CISA republishes its assessment	Exploitation status, automatability and technical impact — not a number.

CISA KEV

Answers Has this been exploited?

Source CISA, from incident reporting

Changes when When CISA adds an entry, or moves its due date

Read it as An observation. The strongest signal here.

EPSS

Answers Will exploitation be observed in the next 30 days?

Source FIRST, model over the whole catalog

Changes when Daily rescoring — the page shows the previous value

Read it as A forecast. High and no KEV listing is the interesting case.

CVSS

Answers How bad would it be if exploited?

Source The CNA or a scoring source, with its vector

Changes when Rarely, when a scoring source revises it

Read it as Consequence, not likelihood. Unscored means unscored.

SSVC

Answers What should a defender do about it?

Source CISA, as a decision record

Changes when When CISA republishes its assessment

Read it as Exploitation status, automatability and technical impact — not a number.

A CVE page

What a CVE page puts where

A CVE page with an analysis, top to bottom. Where nobody has analysed the CVE, the same layout appears without the analysis blocks and says so at the top, rather than showing placeholders.

Terms

The vocabulary on a CVE page

Hover or tap a term for what it claims, what it does not, and where in the product you meet it.

CISA KEV

A statement of fact: this has been exploited against real targets.

The Known Exploited Vulnerabilities catalog records what has happened, not what might. A listing carries the date CISA added it, and for federal agencies a remediation deadline. It is the strongest single signal here, which is why the board opens on it.

Where KEV badge on a row and on the CVE page · has:kev · the KEV velocity chart in Trends

EPSS

A probability that exploitation will be observed in the next 30 days.

FIRST publishes it daily for the whole scored catalog. Read it as a forecast: 90% means the model expects exploitation, not that anyone has seen it. High EPSS with no KEV listing is a real and common pairing, and it is what the Emerging threats tab collects. The page shows the previous value next to the current one so you can see which way it moved.

Where EPSS column and its delta · epss:>90 · the exploit-probability bands in the dashboards

CVSS

How bad it would be if exploited — severity, not likelihood.

A 0–10 base score with the vector that produced it. It says nothing about whether anyone is exploiting the vulnerability, so a critical CVSS with no exploitation evidence will not get a page here on its own. Where no source has scored a CVE the page says unscored. An absent score is not a low one.

Where Severity chips and the score block on a CVE page · cvss:>=9 · severity:critical

SSVC

CISA's decision record: exploitation, automatability, technical impact.

Stakeholder-Specific Vulnerability Categorization. It is a set of judgements rather than a number: exploitation none, proof-of-concept or active; automatable or not; technical impact partial or total. It sits next to KEV and EPSS so you can see when the three of them disagree.

Where The SSVC block on a CVE page, when CISA has published one

Public exploit · weaponized

Exploit code exists somewhere; weaponized means it works out of the box.

An exploit entry is a published proof-of-concept: a repository, a database entry, a framework module. Weaponized is the stronger claim, that the code is packaged to run rather than to demonstrate. The score counts both and weights the second higher.

Where The exploit count and PoC sources on a CVE page · has:exploit · exploits:>5

Scanner template

Someone published a check that finds this vulnerability remotely.

A template means the vulnerability is findable at scale by anyone running the scanner, attackers included. It also means you can check your own exposure without waiting for a vendor tool.

Where Signals column · has:template

Detection rule

A published Sigma or YARA rule covers exploitation of this CVE.

Detection is the other half of remediation. A rule tells you whether the attempt would show up in your logs before the patch lands. The gap between available exploits and available rules is the most useful thing the query language can find: has:exploit -has:rule is that gap.

Where Signals column · has:rule · rules:>0 · the detection-gap ranking in Trends

Indicators and dorks

Hunting material: observed artefacts, and search strings that find exposed instances.

Indicators are the artefacts seen in exploitation attempts, sourced from threat exchanges. A dork is a search query that surfaces internet-facing instances of the affected product. Both sit next to the remediation text, because that is when you need them.

Where The detection and hunting block on a CVE page · has:ioc · has:dork

Threat actor · ransomware use

Who has been observed using it, and whether CISA records ransomware use.

Attribution here is reported, not inferred. A group appears when a credible public source has tied it to the CVE. The ransomware flag comes from CISA's own field on the KEV entry, which is why it is trusted enough to colour a row.

Where Actor chips on a CVE page · has:actor · actors:>=2 · has:ransomware

Exploit-maturity lane

Where a record sits on the disclosure-to-exploitation path.

Four buckets: newly disclosed (published, no public exploit), proof-of-concept (exploit code is public), active exploitation (weaponized in the wild), resolved (fix widely deployed). Since this set starts from the KEV catalog, nearly every record sits in active exploitation. That is why the board splits its columns by KEV recency, ransomware linkage and exploit probability instead of by lane.

Where Status facet in search · the exploitation-stage chart in the dashboards

Weakness class

Which kind of bug it is, in nineteen classes rather than a catch-all.

Derived from the record's CWE data. The classes follow what the records actually contain, so memory corruption gets its own class instead of being folded into remote code execution: in a list of exploited-in-the-wild vulnerabilities it is the largest group there is. A record matching none of them is labelled unclassified.

Where Category filter on the board · cwe:CWE-79 · the weakness leaderboards in Trends

Analysis page vs reference entry

One has an analysis behind it; the other shows the facts on record and says so.

An analysis page tells you what the vulnerability is, which versions are affected, what to patch and how to detect attempts. A reference entry shows what is on record — scores, scope, exploitation status — and says at the top that no analysis has been published. The watchlist tabs are reference entries, and so is any CVE nobody has analysed.

Where Every CVE URL. The page tells you which one you are reading.

KEV due date · overdue

CISA's remediation deadline for federal agencies, and whether it has passed.

It binds federal agencies, not private organisations, but it is a useful public clock. An overdue entry has been exploited and has stayed unpatched in scope long enough for the deadline to pass.

Where Due and overdue chips · is:overdue · due:<2026-09-01 · the overdue profile in the dashboards

Listing lag

Days between a CVE being published and CISA listing it as exploited.

Measured across the KEV catalog, it is the window a defender actually had. Short lags cluster where exploitation began at or before disclosure. Long lags are usually older CVEs that came back into use.

Where The listing-lag distribution in Trends and the dashboards

Search syntax

The search box takes a query language

Hover a filter for what it does. The list is generated from the vocabulary the box parses, so it cannot document a filter that no longer exists.

Start with one of these

has:exploit -has:ruleepss:>90 -has:kevvendor:cisco,citrix,fortinet-has:titleage:<30 has:actorseverity:critical actors:>=2is:overdue has:ransomware

Filters

vendor:cisco

Affected vendor. Comma-separate for any of: vendor:cisco,citrix

product:exchange

Affected product name.

title:bypass

Search the title only, rather than every field.

cwe:CWE-79

Weakness class, as CWE files it.

year:2026

The year in the CVE id — when the id was assigned, not when CISA listed it.

severity:critical

critical · high · medium · low · unscored. Unscored is the absence of a score, not a low one.

epss:>90

EPSS as a percentage. Accepts > >= < <= or a bare number for at-least.

cvss:>=9

CVSS base score, from the scored records only.

exploits:>5

How many public exploit entries exist.

actors:>=2

How many named threat groups are tied to it.

rules:>0

How many published Sigma/YARA rules cover it.

malware:>0

How many malware families are observed using it.

tweets:>50

How many X posts name it.

github:>10

How many public GitHub repositories are filed against it.

news:>3

How many stories the security press ran.

iocs:>0

How many indicators a threat exchange ties to it.

after:2026-06-01

Listed on or after this day. A bare year or year-month works too.

before:2026-06-01

Listed on or before this day.

published:>2026-01

When the CVE record was published, as opposed to when CISA listed it.

due:<2026-09-01

CISA's remediation deadline.

age:<30

Days since CISA listed it. age:<7 is this week's additions.

Flags

has:kev

On the CISA Known Exploited Vulnerabilities catalog

has:ransomware

CISA records known ransomware use

has:actor

A named threat group is tied to it

has:malware

A malware family is observed using it

has:rule

A published Sigma/YARA detection rule covers it

has:exploit

Public exploit code exists somewhere

has:template

A scanner template checks for it

has:overdue

Past CISA's remediation deadline

has:due

Carries a CISA remediation deadline at all

has:title

The CNA filed a title — `-has:title` finds the ones that did not

has:epss

FIRST has scored it

has:cvss

Some source has scored it

has:twitter

X posts naming it — chatter, not evidence

has:github

A public GitHub repository is filed against it

has:news

The security press has written about it

has:discussion

A forum thread is running about it

has:ioc

Indicators are tied to it in a threat exchange

has:dork

A search dork exists for finding exposed instances

has:advisory

CISA published an advisory naming it

A leading minus negates a term. Terms combine with AND; comma-separate a field's value for OR.

Where to go

Five surfaces over one dataset

CVE Database

What is being exploited right now, and what is about to be?

A CVE page

Everything known about this identifier, and where each part came from.

News

What is being written about, and which vulnerability record it is about.

Trends

Is this getting worse, for whom, and in which weakness class?

Dashboards

The same data, arranged around the decision in front of you.

What each surface holds

CVE Database The board. Three tabs: Known exploited (on the CISA KEV list, with an analysis), Emerging threats (probable exploitation, queued for analysis), Waiting list (watched, no analysis yet). Columns carry severity, EPSS, exploitation signals and CISA dates. Four grouped views split the KEV set by recency, ransomware linkage and exploit probability.

A CVE page One record in full: identity and scores, exploitation verdict, affected scope, timeline, detection and hunting material, references, and the reporting that names it. If the record is catalog-only, the page says so at the top.

News Security reporting linked to the CVE identifiers each story names, alongside proof-of-concept repositories filed against a CVE and the discussion running about it.

Trends Aggregates over the whole published CVE catalog, not only the CVEs analysed here: monthly publication volume, KEV velocity, vendor and weakness leaderboards, movers, and the detection-gap ranking. Month reports and vendor pages drill into a single cell.

Dashboards Three views over the same records: SOC, vulnerability management, CISO. The difference is the first question each one asks. What needs watching this shift, what needs patching this sprint, what needs reporting this quarter.

Where SOCRadar fits

Mostly public data, and the part that is ours

Public data, organised

Most of what a CVE page shows is public: the CVE record, the KEV catalog, EPSS, SSVC, vendor advisories, published exploits and rules. The work is in the joining. One identifier, the evidence around it, and a named source on every field.

Where SOCRadar's own data appears

Four streams come from SOCRadar's own collection rather than a public index: indicators tied to a CVE, named threat groups and the malware they run, the discussion and social volume around it, and the reporting it aggregates. Rows and items carrying that material wear the SOCRadar mark, and each stream shows a capped slice of what exists.

The risk score, and where it comes from

Where SOCRadar has scored the CVE, the 0-100 figure is its own risk score and the page names it. Where it has not, the page combines CVSS, exploit probability, CISA's exploited list and public exploit evidence into a score of its own, and labels it that way. You can always tell which one you are reading.

What this tool does not do

It never looks at your estate. No asset inventory, no monitoring of your domains, no alerting, no ticket. The dorks and scanner templates on a CVE page are how you check exposure by hand. Continuous monitoring of your own attack surface, and the streams without a cap, are what the platform is for.

See what the platform adds, or keep using this one. Nothing here asks for a signup.

What this cannot tell you

Where the data stops

Six limits worth knowing before you act on any of it.

01

EPSS is a forecast.

A high value is what a model expects; the KEV listing is what someone observed.

02

Attribution and ransomware linkage come from public reporting.

No named group means nobody credible has published one, not that there is none.

03

Catalog-record pages carry no original analysis and say so.

They exist so an identifier always resolves. They are not research.

04

Affected-version data is only as good as the CNA advisory behind it.

Where a record carries CPE match data alone, the page shows flat vendor and product lists rather than inventing version ranges.

05

The endpoint behind the watchlist tabs returns at most 200 rows per request, so those two tabs are a top slice of that population, not all of it.

06

Nothing here scans your environment.

This is what is publicly known about a vulnerability. The dorks and templates are how you check your own exposure.

Something still unclear? Open the CVE database and search the identifier. The page tells you which kind of record you are looking at.

F.A.Q.

What people ask about CVE Radar