CVE (common vulnerabilities and exposures)

The public ID number for one specific known security hole, like CVE-2021-44228 (Log4Shell), so everyone can name the same bug.

the numbered bug everyone panics aboutthat famous security holeCVE numberknown vulnerability IDcommon vulnerabilities and exposuresthe log4j thing everyone was posting aboutsecurity advisory numberCVE-2021-44228

See it

Live demo coming soon

What it is

A CVE ID is a catalog number for one specific publicly known vulnerability, in the form CVE-year-number. It exists so that your scanner, the vendor's advisory, the patch notes, and the panicked Slack thread are all provably talking about the same bug. The program is run by MITRE with assigning authorities (CNAs) like GitHub, Google, and most large vendors; the NVD then enriches entries with affected version ranges and a CVSS severity score. Famous ones get nicknames: CVE-2021-44228 is Log4Shell, CVE-2014-0160 is Heartbleed.

For a builder the practical loop is: a scanner reports a CVE, you look up the affected package and version range, check whether your lockfile actually resolves into that range, upgrade to the fixed version or apply the documented mitigation, and note the decision if you choose to accept the risk.

Misconception: a CVE ID is an identifier, not a verdict. It carries no severity by itself, the attached CVSS score describes technical severity in the abstract rather than risk to you, and plenty of CVEs are disputed, duplicated, or filed against a code path your app never executes. The reverse trap is worse: not every real vulnerability gets a CVE, so an empty scan report is not a clean bill of health.

Ask AI for it

Analyze [CVE-ID] against this repository and tell me whether it actually affects us. Find the affected package and version range and the fixed version, check the lockfile for the version we really resolve to and whether it is a direct or transitive dependency, check whether our configuration enables the vulnerable feature, check whether the package is included in the shipped build at all, and trace whether any call path in our code reaches the vulnerable function. Then give me: a one-paragraph plain-language description of the bug and how it is exploited; a classification of exposed, not exposed, potentially exposed, or unknown, with the specific evidence behind that classification and an explicit note on anything you could not verify; the exact upgrade command or config mitigation; and the CVSS vector with a note on why our real risk is higher or lower than that score.

You might have meant

dependency vulnerability scanningcvssvulnerabilityexploitsupply chain attack

Go deeper