VULNpocalypse

VEDAS and Exploit Observer: how this site works, and its limits

Vulnpocalypse is generated and updated automatically by VEDAS, A.R.P. Syndicate’s Vulnerability and Exploit Data Aggregation System. This page explains what that means, where every number comes from, and what can go wrong.

What VEDAS is

VEDAS (Vulnerability and Exploit Data Aggregation System) is A.R.P. Syndicate’s vulnerability and exploit intelligence system. It:

  1. Collects vulnerability and exploit records from public sources, including global identifiers (CVE, GHSA, OSV, EUVD) and national databases (such as China’s CNVD and CNNVD, Russia’s BDU and Japan’s JVNDB), plus exploit sources such as Exploit-DB, Metasploit, public code repositories and vendor advisories.
  2. Clusters records that describe the same weakness under different identifiers, so one vulnerability with a CVE, a GHSA and several national IDs becomes one cluster.
  3. Scores each cluster with the VEDAS score, from 0 to 1, for how much evidence of a working exploit exists and how widely the bug shows up.
  4. Writes detection signatures: for exploitable CVEs, VEDAS uses AI to write a Nuclei template (an active check) and a Suricata rule (network detection). They are published openly in vedas-signatures under the MIT licence.

More detail is on the VEDAS page.

What Exploit Observer is

Exploit Observer is the public search over VEDAS: look up a CVE or another identifier and see its cluster, the exploit and analysis references VEDAS has found, and its scores. This site reads Exploit Observer through its authenticated API, using A.R.P. Syndicate’s puncia client.

How this site is generated

Every few hours, a build runs without human involvement. It downloads:

  • VEDAS and EPSS scores for every CVE from the public cve-scores feed,
  • CISA’s Known Exploited Vulnerabilities catalogue,
  • CVE records from CVE.org (descriptions, affected versions, weakness types, CVSS, CISA’s SSVC assessment, references),
  • Exploit Observer intelligence for each CVE page,
  • vedas-signatures, the detection rules,
  • NVD monthly publication counts and CVE.org publication dates,
  • confirmed malicious-package records from the OpenSSF malicious-packages database (via OSV), for the supply-chain tracker,
  • headlines from established security newsrooms, used only to flag developing breach stories for review.

It then regenerates every page.

CVE advisory pages are assembled, not written. Every sentence is either quoted verbatim from a named source or a fixed template filled with a field from one. No language model writes or rewords the CVE advisories.

Supply-chain alerts are assembled the same way. Package names, versions, times and indicators come from the malware records and the package registry; the advice is identical for every confirmed malicious release and is not written per alert.

Developing stories are headlines, not claims. A breach story reported by two or more newsrooms that we have not reviewed yet is listed with links to those outlets, labelled as unreviewed. Nothing is rewritten.

Long-form advisories, briefs, the timeline and the explainers are drafted with AI assistance from the cited sources and checked against them. Every factual claim links to its source.

How Exploit Observer results are filtered

Exploit Observer can return material that is not about the CVE you asked for. This is a known property of the data, not a fault in a single record:

  • Cluster neighbours. A VEDAS cluster can contain several related identifiers, and its links are pooled.
  • “Related” is not “the same”. Exploit Observer’s related list includes advisories that its upstream sources say are different vulnerabilities, such as the same bug class in another ecosystem.
  • Mentions are not exploits. Code repositories that merely mention a CVE, collections and mirrors can appear alongside real proofs of concept.
  • Clustering can be wrong. Automatic clustering occasionally joins records that do not belong together.

So before anything from Exploit Observer appears on a CVE page, this site applies strict rules:

  1. Identity uses aliases only. A record counts as the same vulnerability only through Exploit Observer’s aliases field, which lists ids the source says are the same vulnerability. The broader related list is never shown as the same bug.
  2. An exploit link is shown only if it names the CVE, or one of its true aliases (for example its GHSA or Exploit-DB id). Everything else is left out, and the page says how many references were left out.
  3. Products are shown only if they match the vendor or product in the official CVE record.
  4. Descriptions, affected versions and fixes always come from the CVE record, never from Exploit Observer.

Every dropped item is kept in an internal audit file so the rules can be reviewed and improved.

What the scores mean, and do not mean

  • VEDAS score (0 to 1) measures how much exploit evidence exists. It is not a probability of attack. It combines many corroborating signals, so well-documented bugs saturate near 1. Its formula has been improved over time, so scores from different dates are not strictly comparable.
  • EPSS (0 to 1) is FIRST.org’s estimate of the chance of exploitation attempts in the next 30 days. In the cve-scores feed, an EPSS of exactly 0 means FIRST had no score that day, not zero risk.
  • CISA KEV lists bugs with reliable evidence of exploitation. It is US-focused and incomplete: absence from KEV does not mean a bug is safe.
  • How VEDAS and EPSS compare is measured, with the method, on the VEDAS vs EPSS page. In short: EPSS is sharper among the very riskiest few percent of CVEs, and VEDAS covers far more of the bugs that were later exploited once you look beyond that.

Known limits of the data

  • Publishing gaps. cve-scores was published almost daily from April 2025 to 22 February 2026, paused until 8 August 2026, and has been irregular since. History charts show the pause as “no data”, and comparisons only use bugs with a score snapshot taken within seven days before CISA listed them.
  • Detection scope. vedas-signatures currently covers remotely exploitable CVEs only. Bugs that need local access are marked “out of scope” rather than “missing”.
  • Attack vector. Remote or local is taken from the CVSS attack vector in the CVE record. When a record has none, CISA’s description is used, and when that says nothing, the bug is treated as remote.
  • AI-written signatures. Detection rules are generated with AI, syntax-checked in CI and open to community review. They are not tested against every affected version. Expect false positives and false negatives, and read a rule before running it.
  • Record changes. CVE records, CVSS scores and KEV entries are revised by their owners. A page reflects the data at its last build, shown as “Scores as of” at the top.
  • Technology groups on the technologies page are assigned by vendor and product name with keyword rules, so a few products may be grouped imperfectly.

Responsible use

  • Only run Nuclei templates or any active check against systems you own or have written permission to test. Unauthorised scanning may be illegal where you are.
  • Detection rules and advisories are provided as is, without warranty of any kind. A.R.P. Syndicate is not liable for decisions made, or damage caused, using this site or its rules.
  • Always confirm affected versions and fixes with the vendor before changing production systems.

Independence and trademarks

Vulnpocalypse and VEDAS are not affiliated with or endorsed by CISA, FIRST, MITRE, NIST or any vendor named on this site. Product and company names are trademarks of their owners and are used only to identify the software affected. Data from CVE.org, CISA KEV and NVD is used under their public terms; EPSS is provided by FIRST.org.

Corrections

If anything here is wrong, email sales@arpsyndicate.io with “Correction” in the subject and a link to the page. Corrections to detection rules are welcome as pull requests on vedas-signatures.