Verified first, explained second

The record is assembled only from the public APIs and data exports these organisations publish. No data is scraped, bought, crowd-sourced or generated.

• NIST National Vulnerability DatabaseCVE API 2.0

  Published CVEs, descriptions, CVSS metrics from NVD and the reporting CNA, CWE weaknesses, affected products as CPE ranges and references.

• GitHub Advisory DatabaseREST global advisories, reviewed only

  GHSA advisories with their CVE aliases, summaries, CVSS, affected packages with vulnerable and first patched versions, and references.

• Google OSVPublic per-ecosystem data export

  Open-source package advisories in the OSV format: aliases, affected version ranges, fixed versions and CVSS vectors.

• CISA Known Exploited VulnerabilitiesCatalog JSON feed

  Confirmed exploitation in the wild: the date CISA added the CVE, its remediation due date, required action and known ransomware use.

• FIRST Exploit Prediction Scoring SystemEPSS API

  The daily probability that a CVE sees exploitation activity in the next 30 days, and its percentile among all scored CVEs.

OSV is read for these ecosystems: npm, PyPI, Go, Maven, crates.io, NuGet, RubyGems, Packagist, Pub, Hex, GitHub Actions, SwiftURL. Every vulnerability page lists the records it was built from, with links to each original.

A scheduled job starts the collection at 07:00 Europe/Stockholm, all year round. The scheduler runs in UTC, so it fires at 05:00, 06:00 and 07:00 UTC and the job itself checks the Stockholm clock: it collects once per day, on the first trigger at or after 07:00 local time, whether Sweden is on winter or summer time.

Window

Everything published or changed since the end of the previous run, with a two-hour overlap so late-indexed records are not missed.

Rate limits

Each API is called within its published limits, with retries and exponential back-off on errors.

Partial failures

If one source is down, the others still publish. The missing source is picked up again on the next run, and the status bar shows a partial update.

Explanations

Analyses are written after the data is published, most important first: confirmed exploitation, then severity and EPSS. A daily limit keeps the volume in check; records without an analysis still show all verified data.

Availability

Pages read from the database, never from the job. If a run fails, the site keeps serving the last good data.

The same flaw often appears in several sources under different names: a CVE ID at NVD, a GHSA ID at GitHub and an ecosystem-specific ID in OSV. Records are matched on their identifiers and aliases and merged into one entry, keyed by the CVE ID whenever one exists. A record without a CVE keeps its own ID, so nothing is dropped.

When sources disagree, a fixed order decides which value is shown:

Description

NVD, then GitHub, then OSV, then CISA KEV.

Title

GitHub summary, OSV summary, CISA vulnerability name, then a title derived from the weakness and product.

CVSS

NVD primary v3.x, the CNA's v3.x via NVD, GitHub v3, then v4.0 (NVD, then GitHub), then an OSV vector, then v2.

Affected software

The union of all sources, with version ranges and fixed versions as each source states them.

References

The union of all sources, de-duplicated by URL and grouped as advisories, patches, exploit and tracking links.

Records that a source withdraws or rejects are removed from the public record. The source of each displayed value is named next to it.

Severity is the qualitative band of the CVSS base score chosen above, using the bands defined by the CVSS specification. When no score exists, the source's own severity label is used. If there is neither, the vulnerability is shown as unrated; a score is never estimated.

• Critical9.0 – 10.0
• High7.0 – 8.9
• Medium4.0 – 6.9
• Low0.1 – 3.9
• UnratedNo score published yet

The four-light meter repeats the band in a form that does not depend on colour: four lights for critical, one for low, none when unrated. New CVEs are often published before NVD or the reporting organisation has scored them, so the unrated share is highest for the most recent days.

A vulnerability is marked exploited only when it is listed in the CISA Known Exploited Vulnerabilities catalog, which requires reliable evidence of active exploitation. Nothing else, including AI text, can set that flag.

CISA due date

The deadline US federal agencies have to remediate. It is shown as a signal of urgency, not as a deadline for anyone else.

Ransomware use

Whether CISA knows the vulnerability to be used in ransomware campaigns, exactly as the catalog states it.

EPSS

FIRST's estimate of the probability of exploitation activity in the next 30 days, from 0 to 100%, with its percentile among all scored CVEs. It is a prediction, not a confirmation.

Each published vulnerability gets an analysis written by Claude, Anthropic's AI model, through the Anthropic API. The call is made on the server; the key is never sent to the browser.

What it sees

Only the verified record shown on the page: identifiers, descriptions, scores, affected versions, exploitation status, weaknesses and references. It has no web access and is instructed to use nothing else.

What it writes

• A plain-language explanation and a technical analysis
• What an attacker could do, and the potential consequences
• Affected software and versions, as the sources state them
• Why the severity is what it is, and why the vulnerability matters
• Whether exploitation is confirmed, and defensive actions and patch information only where the sources support them

How it is checked

Before anything is published, the text is checked against the record. A draft is rejected if it mentions a CVE or GHSA ID that the sources do not name, quotes a CVSS score that differs from the published one, claims exploitation for a vulnerability CISA has not listed, or calls exploitation unconfirmed when CISA has listed it. A rejected draft is rewritten once with the reasons; if it fails again, no analysis is shown.

Labelling

AI text is always marked AI analysis and kept apart from verified data.

Record keeping

Each analysis is stored with the model that wrote it and the time it was written.

Updates

An analysis is rewritten when the facts behind it change, such as a new score, a fix or a KEV listing. Daily EPSS movements do not trigger a rewrite.

Briefings

Counts, rankings and lists are computed from the database. Only the headline, summary and short explanations are written by Claude, under the same rules.

• The record starts on the day collection began. Earlier dates include only vulnerabilities that CISA later listed as exploited.
• Sources publish at different speeds. A CVE can appear before it has a score, affected products or an EPSS value; those fields fill in on later runs.
• Affected products from NVD use CPE names, which can be terse. Package names come from OSV and GitHub as published.
• Only GitHub-reviewed advisories are collected, and OSV only for the ecosystems listed above.
• Patches and workarounds are reported as the sources describe them. They are not tested here.
• Times are stored in UTC and shown in Europe/Stockholm time (CET or CEST). Charts count Stockholm calendar days.

Baba Yaga Security is a read-only reference. There are no accounts, logins, comments, forums or user uploads, and nothing on the site scans, tests or attacks systems. It does not publish exploit code. It sets no tracking cookies and loads no third-party scripts.

Questions about a specific vulnerability are best taken to the vendor or the original advisory, linked on every vulnerability page. To browse the data, start with the explorer or the latest briefing. The sources themselves are at nvd.nist.gov, github.com/advisories, osv.dev, cisa.gov and first.org/epss.