Perseus Products
Subscription
Vulnerability Core Engine
Vulnerability and exposure intelligence for companies that build it into their own products: asset-management platforms, and monitoring-tool vendors who see availability and bandwidth but not vulnerability exposure. Delivered by subscription, with one canonical record per vulnerability and the evidence behind every derived field.
Intelligence your platform can act on
Overview
The engine ingests vulnerability intelligence from tiered sources, normalises it into one canonical record per vulnerability, and serves it over a versioned REST API. It answers the questions an asset-management or monitoring platform cannot answer on its own: which of these installed versions are affected, what the vendor says about it, what the fix is, and what changed since you last asked.
It is an intelligence engine, not a scanner. You send an inventory, a software bill of materials, a fleet of hosts or a set of industrial products; the engine returns matched findings with scores from every scoring party, exploit evidence where it exists, vendor statements, remediation paths and a change feed you can poll. Assessments are stateless: the engine does not keep your inventory.
Normalised intelligence
Every alias resolves to one record; vendor statements are collapsed to one row each; version ranges are canonical.
Assessment, not just lookup
Host, SBOM, fleet and OT posture assessments with patch-state-aware matching and upgrade paths.
A change feed you can trust
An immutable, cursor-paged event log, product-scoped feeds, and retractions carried as withdrawal facts.
VEX in and out
Upstream vendor statements on every finding, and OpenVEX or CycloneDX VEX exports of your assessments.
of vulnerabilities published since 15 April 2026 carry a CVSS score in the engine
of the same set carry the public national database's own analysis
of all scored vulnerabilities have no national-database analysis at all
vendor not-affected statements loaded and served on findings
The corpus today
What the engine holds
Lifetime totals across the whole corpus, from the engine's own counters. Every vulnerability is one canonical record, whether or not it has a CVE.
vulnerabilities in the corpus
713,289
with a CVE identifier
397,684
advisory-only, with no CVE
315,605
known exploited in the wild
1,721
exploit and proof-of-concept records
151,782
affected products
282,726
vendors
53,875
events in the immutable log
188,013,792
Vulnerabilities count CVEs plus advisory-only vulnerabilities from package-ecosystem, malicious-package, industrial and vendor advisories. Exploit and proof-of-concept records are catalogued as metadata. Events are the immutable log every other figure is rebuilt from.
Use cases
Nine ways platforms integrate
Each path has a written, tested integration recipe. We take each subscriber through the one that matches their platform during onboarding.
Asset-management platforms
Contextual findings for the inventory you already hold
Post host inventories, receive findings with vendor statements and remediation, and poll deltas instead of re-assessing everything.
Vulnerability and threat-intelligence platforms
Search, drill down, resolve in bulk
Look up by any identifier, read every enrichment with its lineage, browse the weakness and product catalogues, and watch a product inventory for change.
Monitoring and patch-planning tools
Fleet assessment with a fix-once plan
One call over many host cohorts, deduplicated server-side, returning the single actions that clear the most findings, re-run when the product-scoped feed moves.
OT monitoring and asset-inventory products
Posture per site, vendor and sector
Exposure rollups for an estate of industrial products by order number and family, the estate's change watch, and VEX filing per device.
Build-pipeline and application-security tools
SBOM in, findings and VEX out
Post a CycloneDX or SPDX bill of materials, get findings with exploited-in-the-wild flags, exploit probability and remediation, re-assess on the BOM's coordinates, file the result as CycloneDX VEX.
SIEM and SOAR platforms
Deltas by cursor, retractions included
Sync the immutable event log into your pipeline, subscribe to your own product coordinates, and receive withdrawal facts when a vendor retracts a statement. Push delivery is available by arrangement.
Offensive-security and risk-quantification platforms
Attack paths and staged chains
A per-vulnerability path with weakness class, adversary technique and exploit references, and chains across several vulnerabilities, computed deterministically.
Compliance and product-security platforms
VEX export and statement lookup
File an assessment as a schema-validated OpenVEX or CycloneDX VEX document, or page every vendor, distribution and coordinator statement the engine holds for one vulnerability.
Security testing tools
Exploit and proof-of-concept metadata
Discover and inspect known exploits and proofs of concept mapped to vulnerabilities, with quality labels and their lineage. Metadata only: content is not redistributed.
Capabilities
What the API gives you
Every capability below is live in production and available by subscription, with keys scoped to each integration.
Vulnerability intelligence
Search, detail and bulk enrichment. Look up by any identifier you hold; aliases from advisories, trackers and ecosystems resolve to the same canonical record.
Advisory-only vulnerabilities
Vulnerabilities published in security advisories without a CVE are first-class records, catalogued directly from the advisory, not dropped.
Asset assessment
Post a host inventory and get applicable findings, contextual exploitability, remediation actions and upgrade paths, with patch state taken into account.
SBOM ingestion
Post a CycloneDX or SPDX bill of materials and get findings matched natively on package coordinates, without a CPE.
Fleet assessment
Assess cohorts of hosts at once and receive a fix-once master plan: which single upgrade clears the most finding instances.
OT and ICS posture
Per-site exposure by product family, plus device matching by order number and firmware version for industrial products.
Attack chains
A per-vulnerability attack path with stations and exploit references, and staged chains across several vulnerabilities. Deterministic, with no model at request time.
Enrichments with lineage
Model-assisted enrichers adjudicate divergent scores, classify proof-of-concept quality, predict weakness classes and suggest remediation. Every derived field carries its model id, prompt version, fingerprint and input events.
The normaliser
One canonical identity per vulnerability, vendor statements materialised per source and collapsed to one row per statement, canonical package, CPE and version-range forms, and multi-source CVSS with the scoring party named.
Change feed and product-scoped feed
Poll an immutable event log with a cursor, or subscribe to changes for your own product coordinates. Delistings and vendor withdrawals arrive as explicit facts.
VEX statements and export
Opt in to vendor and distribution statements on every finding, page every statement for a vulnerability, and export assessments as schema-validated OpenVEX or CycloneDX VEX.
Exploit and proof-of-concept catalogue
Metadata for known exploits and proofs of concept, with quality labels. Metadata only: no exploit content is published or redistributed.
Secure-version lookup
Ask for the nearest clean version of a package and receive the target, the rungs between, and the residual count. Advisory-derived versions are flagged as leads.
Tamper-evident record
A hash-chained event log with a published chain head, and retrieval of the raw upstream record behind any fact.
What comes into the engine
Tiered intake, one immutable log
Connectors run on schedules and append facts to an immutable event log; projections are rebuilt from it and served read-only. Sources are grouped into tiers. The engine does not publish its source list.
Tier 1
Authoritative identifiers
The records that define vulnerability identity and baseline scores.
Tier 2
Exploitation and risk signals
Known-exploited listings and exploit-probability estimates.
Tier 3
Cross-ecosystem aggregators
Package-ecosystem advisories with native package coordinates.
Tier 4
Vendor CSAF and VEX feeds
Machine-readable vendor advisories and not-affected statements, including industrial vendors.
Tier 5
Distribution security trackers
Per-release package status from operating-system distributions.
Tier 6
Exploit and proof-of-concept sources
Public exploit repositories and proof-of-concept corpora, catalogued as metadata.
Tier 7
Weakness, attack pattern and adversary context
Weakness classes, attack patterns and adversary technique mappings.
Tier 8
Product identification
Product naming and coordinate schemes used to match inventories to advisories.
Connector counts per tier are published once the count is reconciled across the engine's documentation.
From advisory to answer
How it works
- 1
Ingest
Scheduled connectors fetch tiered sources and append immutable facts.
- 2
Normalise
Aliases resolve to one record; statements collapse; coordinates and ranges become canonical.
- 3
Enrich
Scores from every party, exploit evidence, weakness classes and attack chains, each with lineage.
- 4
Project
Rebuildable read models are served from an isolated tier so heavy reads never touch ingestion.
- 5
Assess
Your inventory, SBOM, fleet or product list is matched, scored and given remediation paths.
- 6
Notify
A cursor-paged change feed and product-scoped feeds tell you what changed, including withdrawals.
Showcase
Real output
Every item here is real engine output or a measured figure, on sample inputs. Nothing on this page takes input; API access is by subscription.
Coverage beyond the public national database
Share of vulnerabilities published since 15 April 2026 with a CVSS score: the national database's own analysis versus a score held in the engine from any scoring party.
Posted
One host, three package coordinates
A logging library, a utility library and an HTTP client, each with its installed version.
Returned
17 findings, nothing unmatched
The response says the result is complete, not truncated.
- Matched package
- org.apache.logging.log4j/log4j-core@2.14.1
- How it matched
- by package coordinate, confidence 0.95
- First fixed in
- 2.16.0
- Recommended target
- 2.25.4clean of every known issue
Upgrade ladder for log4j-core@2.14.1
findings remaining at each rung
- 2.14.17 open · 2 exploited
- 2.15.06 left · 1 exploited
- 2.16.05 left · 0 exploited
- 2.17.04 left · 0 exploited
- 2.17.13 left · 0 exploited
- 2.25.4 clean
Bars: critical, high, medium, low. Intermediate fixes leave the host exposed to later issues; the target is the nearest version with none.
An assessment: inventory in, findings and a fix path out
Three package coordinates posted as one host; 17 findings returned. One finding shown with its match, scores, exploited-in-the-wild flag and first fix, then the upgrade ladder: how many findings remain at each intermediate version and the nearest version clean of every known issue.
Network
no authentication
Improper Input Validation
CWE-20 · T1027 · low complexity — reliable
Code execution
foothold on the host · pivots beyond the component
- Weakness
- CWE-20 · Improper Input Validation
- Technique
- T1027 · Obfuscated Files or Information
- Proof-of-concept references
- 4 on file, metadata only
AV:N PR:N UI:N S:C C:H I:H A:H AC:L
A flaw was found in the Apache Log4j logging library in versions from 2.0.0 and before 2.15.0. A remote attacker who can control log messages or log message parameters, can execute arbitrary code on the server via JNDI LDAP endpoint.
Attack path for one vulnerability
The engine's attack-path resource for a widely exploited logging-library vulnerability: entry point, mechanism with weakness class and adversary technique, and outcome. Deterministic, computed without a model at request time. Proof-of-concept references are counted, not listed.
Target profile
Internet-facing on-premises mail server
Three vulnerabilities, in order. The engine frames them as stages and supplies each hop from its recorded links.
Objective reached
Unauthenticated remote code execution / SYSTEM-level compromise of Exchange Server (ProxyShell)
- 1Initial AccessCVE-2021-26855CVSS 9.8Exploited in the wildCWE-918
Network via server-side request forgery (ssrf) code execution
Needs
- · Network access to the Exchange front-end (typically internet-facing OWA/HTTPS)
- · Vulnerable on-prem Exchange Server version (2013/2016/2019)
Leaves the attacker with
Code execution foothold
Unauthenticated privileged access to Exchange backend (path toward full RCE/mailbox compromise)
Compromise after this stage30%Link to the next stage: confidence 0.8 · 4 proof-of-concept references
- 2ExecutionCVE-2021-34523CVSS 9.8Exploited in the wildCWE-287
Network via improper authentication code execution
Needs
- · Network access to the Exchange Client Access Service / Autodiscover frontend (typically internet-facing)
- · Vulnerable on-prem Exchange Server version (no ProxyShell patch)
- · Ability to reach the PowerShell backend through the proxied request
Leaves the attacker with
Code execution foothold
Unauthenticated remote code execution / SYSTEM-level compromise of Exchange Server (ProxyShell)
Compromise after this stage56%Link to the next stage: confidence 0.8 · 1 proof-of-concept references
- 3ImpactCVE-2021-27065CVSS 7.8Exploited in the wildCWE-39
Local via path traversal: 'c:dirname' code execution
Leaves the attacker with
Full code execution on the target
Code execution — foothold on the host
Compromise after this stage92%Final stage · 3 proof-of-concept references
An attack chain across three vulnerabilities
Three vulnerabilities in an internet-facing mail server, given in order. The engine frames them as initial access, execution and impact, with what each stage needs, what it leaves the attacker holding, the confidence of each link, a cumulative compromise meter and the tactics in play. The links and prerequisites come from the engine's recorded analysis of how these vulnerabilities combine.
Network code execution
Anchor · 71 exploit references
Network code execution
Pivot · 2 exploit references
Local code execution
End of a path · 20 exploit references
Local code execution
Pivot · 0 exploit references
Local code execution
Pivot · 0 exploit references
Network code execution
End of a path · 7 exploit references
From CVE-2021-26855
- → CVE-2021-34523Unauthenticated privileged access to Exchange backend (path toward full RCE/mailbox compromise)
- → CVE-2021-27065Unauthenticated remote code execution on Exchange (ProxyLogon)
- → CVE-2021-26857Unauthenticated remote code execution as SYSTEM on Exchange
- → CVE-2021-26858Unauthenticated remote code execution / webshell deployment on Exchange (ProxyLogon)
From CVE-2021-34523
- → CVE-2021-27065Unauthenticated remote code execution / SYSTEM-level compromise of Exchange Server (ProxyShell)
- → CVE-2021-42321Unauthenticated remote code execution on Exchange Server
- → CVE-2021-26858Unauthenticated remote code execution on Exchange (ProxyShell-style)
- → CVE-2021-26857Unauthenticated SYSTEM-level remote code execution on Exchange
From CVE-2021-26857
- → CVE-2021-27065Unauthenticated remote code execution / webshell deployment (ProxyLogon chain)
From CVE-2021-26858
- → CVE-2021-27065Authenticated arbitrary file write leading to webshell deployment / RCE (ProxyLogon chain component)
Every recorded onward hop from one vulnerability
Ask for the attack tree from one anchor and the engine merges every multi-step chain through it into one bounded graph: pivots, end points and the outcome of each hop. Bounds are explicit, and branches beyond them are counted as pruned rather than silently dropped.
Log4j 2.x deserializes and evaluates JNDI expressions in log messages, enabling remote code execution when an attacker controls log input.
- CWE-502confidence 0.95
Unsafe deserialization via JNDI LDAP endpoint allows remote code execution when attacker controls log messages or parameters.
- CWE-917confidence 0.85
Expression injection through JNDI lookup (${jndi:ldap://...}) in log message strings enables arbitrary expression evaluation and code execution.
- CWE-94confidence 0.7
Log message parameter interpolation allows evaluation of arbitrary code expressions through JNDI syntax in attacker-controlled strings.
Provenance, recorded with the result
- Produced by
- the enricher named above
- Model
- identifier recorded
- Prompt
- version 2.0.0, fingerprint b9eebe8eb24f
- Read
- 4 upstream events, by id
- Folded into
- the vulnerability's projection, in sync
Verdicts are displayed, never used to re-score a finding. Any derived field can be traced back to the upstream records it read and recomputed.
An enrichment, with the provenance that makes it auditable
One of 57 enrichments on the same vulnerability: the weakness-class predictor's output with per-prediction rationale, and the lineage recorded with it: which enricher and model produced it, the prompt version and fingerprint, the upstream events it read, and where it was folded into the projection.
One national advisory feed arrived as 3,869,945 raw affected-product statement rows. After materialising each vendor statement with a per-source identity and collapsing restatements, the same feed is 430,778 canonical rows. Within a single document, 31,419 rows collapsed to 4,999. Nothing was dropped: every row still points at its upstream event.
What the normaliser does to one feed
Recorded in the engine's architecture decision record for statement identity.
sharp: Vulnerabilities in libheif
- Identifier
- an advisory identifier, not shown here
- Published
- 8 Sept 2026
- Affected package
- sharpnpm ecosystem
- Matched
- like any other vulnerability, on the package coordinate
A vulnerability with no CVE
An advisory-only record from a package ecosystem: no CVE assigned, no score published, still a first-class vulnerability with its affected package, matched like any other. Advisory identifiers are not shown on this page.
| Status | As published | Published by | Supplier named | Match | Action |
|---|---|---|---|---|---|
| affected | known_affected | a coordinator | exacq technologies, johnson controls inc. | vendor-product, confidence 1 | Johnson Controls recommends upgrading exacq Enterprise Manager to Version 21.12.1 or apply manual mitigation steps (available upon request). |
| affected | known_affected | a coordinator | sensormatic electronics, llc, johnson controls inc. | vendor-product, confidence 1 | Upgrade PowerManage to Version 4.10 |
The document version changes whenever any consulted statement changes, including a withdrawal, so a consumer can detect movement without diffing the page.
Every statement the engine holds for one vulnerability
The per-vulnerability statement page: statements from vendors and coordinators with their status as published, the supplier they name, how the product was matched and at what confidence, and the recommended action. A document version changes whenever any consulted statement changes.
Order number as printed
6ES7518-4AX00-1AB0
Resolves to
simatic s7-1500 cpu 1518-4 pn/dp mfp
vendor: siemens
Vulnerabilities
1,126
Exploited in the wild
4
Exploit references
1,685
Highest score
10.0
By severity
112 critical · 542 high · 458 medium · 14 low
Seen in the corpus from 12 Sept 2023 to 8 Sept 2026. Product-family exposure, not the patch state of any one device.
A controller resolved from its order number
One industrial controller looked up by the order number printed on the device: the catalogue product it resolves to, its exposure counts by severity, exploited-in-the-wild count, exploit references on file and the dates the corpus first and last saw it.
Sites
4
Devices
24
Vulnerabilities
125
Exploited in the wild
1
Critical
28
| Site | Product family | Sector | Devices | Vulns | Exploited | Critical | Band |
|---|---|---|---|---|---|---|---|
| Northgate Transmission Substation | Siemens · SIMATIC WinCC | Transmission | 4 | 68 | 0 | 13 | critical |
| West Generation Plant Control | Schneider Electric · EcoStruxure Control Expert | Generation | 3 | 26 | 0 | 9 | critical |
| Southbank FactoryTalk HMI | Rockwell Automation · FactoryTalk View | Distribution | 5 | 18 | 0 | 6 | critical |
| Northgate S7 PLC Cell | Siemens · SIMATIC S7-1500 | Distribution | 12 | 13 | 1 | 0 | critical |
By vendor
- Siemens2 sites · 81 vulns · 1 exploited
- Schneider Electric1 sites · 26 vulns · 0 exploited
- Rockwell Automation1 sites · 18 vulns · 0 exploited
By sector
- Distribution2 sites · 1 exploited · 6 critical
- Transmission1 sites · 0 exploited · 13 critical
- Generation1 sites · 0 exploited · 9 critical
Exposure of the product family at each site, from the shared corpus; not the patch state of the devices. Unmatched products are reported as unmatched, never as clean. Sites are samples; the products and counts are as returned.
Posture across an estate of industrial sites
Four sample sites, each one product family at one location: exposure per site with a band, rolled up by vendor and by sector, with the estate's totals. From a recorded integration test; the product families and counts are as the engine returned them.
Sample data
- Concerns
- CVE-2000-1000
- Happened upstream
- 22 Jan 2001
- Recorded here
- 26 May 2026, 00:11 UTC
- Event id
- evt-01KSGSXWBS
- Checksum
- 6cc68460d300
- Concerns
- CVE-2000-1000
- Happened upstream
- 8 Aug 2024
- Recorded here
- 26 May 2026, 00:11 UTC
- Event id
- evt-01KSGSXWC8
- Checksum
- fd07b0c0e2ed
The change feed, event by event
Two events from the first page of the immutable log: what happened, which vulnerability it concerns, when it happened upstream and when it was recorded here, with an id and a checksum. Cursor paging and a published head let a subscriber replay from any point and detect gaps.
You send
pkg:maven/org.apache.logging.log4j/log4j-coreEngine resolves
pkg:maven/org.apache.logging.log4j/log4j-core
11 vulnerabilities on this coordinate
Package-coordinate arm
resolved55 rows scanned, 11 vulnerabilities
Ecosystem-and-name arm
too broadrefused rather than guessed: the name alone would match too broadly
A product-scoped feed, resolved before it is filtered
Ask for changes on your own coordinates and the engine first reports how it resolved them: which matching arm answered, how many rows it scanned, how many vulnerabilities the coordinate carries, and what it refused. Here the name-only arm was too broad and was declined rather than guessed.
Questions we are asked
FAQ
No. The engine does not probe systems. It takes the inventory you already have, from an asset-management platform, an agent, a build pipeline or a monitoring tool, and returns matched findings, scores, vendor statements, exploit evidence and remediation paths.
Put the intelligence behind your platform
Tell us about your platform, your customers and the data you hold. If the fit is right, we will take you through the integration path and the commercial terms.