Version 1.7.5 (January 21, 2026)

Original authors:

• Oliver Chang (ochang@google.com)
• Russ Cox (rsc@google.com)

Purpose

This document defines a standard interchange format for describingvulnerabilities in open source packages.

We hope to define a simple format that all vulnerability databases can export,to make it easier for users, security researchers, and any other efforts toconsume all available databases. Use of this format would also make it easierfor the databases themselves to share or cross-check information. Ultimately,this format aims to enable automated, accurate, and distributed managementof vulnerabilities in open source dependencies.

This format is stable, but further backwards compatible changes may still be made.Feedback from maintainers of other vulnerability databases and security response teamsis most welcome. Please feel free to create anissue in this repo.

The current list of databases exporting this format can be foundhere.

Format Overview

The format is a JSON-based encoding format, using the following informal schema.The exact details of each field are elaborated in the next section. All stringscontain UTF-8 text.

A JSON Schema for validation is also availablehere.

{"schema_version":string,"id":string,"modified":string,"published":string,"withdrawn":string,"aliases":[string],"upstream":[string],"related":[string],"summary":string,"details":string,"severity":[{"type":string,"score":string}],"affected":[{"package":{"ecosystem":string,"name":string,"purl":string},"severity":[{"type":string,"score":string}],"ranges":[{"type":string,"repo":string,"events":[{"introduced":string,"fixed":string,"last_affected":string,"limit":string}],"database_specific":{seedescription}}],"versions":[string],"ecosystem_specific":{seedescription},"database_specific":{seedescription}}],"references":[{"type":string,"url":string}],"credits":[{"name":string,"contact":[string],"type":string}],"database_specific":{seedescription}}

Again, this document is only about the JSON encoding the database serves toconsumers, which could be applications or other databases. A database mightstore its entries in an entirely different format, or it might store them usingthis schema but in a more human-editable encoding, such as TOML or YAML. Forserving, only the JSON encoding format is allowed,not a transliteration into any other encoding.

Overall, the approach of this schema is to define only the fields thatabsolutely must be shared between databases, leaving customizations to the“ecosystem_specific” and “database_specific” blocks (see below)

Field Details

schema_version field

{"schema_version":string}

Theschema_version field is used to indicate which version of the OSV schemaa particular vulnerability was exported with. This can help consumer applicationsdecide how to import the data for their own systems and offer some protectionagainst future breaking changes. The value should be a string matching the OSVSchema version, which follows theSemVer 2.0.0 format, withno leading “v” prefix. If no value is specified, it should be assumed to be1.0.0,matching version 1.0 of the OSV Schema. Clients can assume that new minor and patchversions of the schema only add new fields, without changing the meaning of oldfields, so that a client that knows how to read version 1.2.0 can process dataidentifying as schema version 1.3.0 by ignoring any unexpected fields.

id, modified fields

{"id":string,"modified":string}

Theid field is a unique identifier for the vulnerability entry. It is astring of the format<DB>-<ENTRYID>, whereDB names the database andENTRYID is in the format used by the database. For example: “OSV-2020-111”,“CVE-2021-3114”, or “GHSA-vp9c-fpxx-744v”.

The defined database prefixes and their “home” databases are:

In addition to those prefixes, other databases may serve information aboutnon-database-specific prefixes. For example a language ecosystem might decide touse CVE identifiers to index its database rather than a custom prefix. The knowndatabases operating without custom identifier prefixes are:

• Alpine Security Advisory. Serving<ID> in the shared format athttps://storage.googleapis.com/cve-osv-conversion/osv-output/<ID>.json.
• Your database here.Send us a PR.

Themodified field gives the time the entry was last modified, as anRFC3339-formatted timestamp in UTC (ending in “Z”). Given twodifferent entries claiming to describe the sameid field, the one with thelater modification time is considered authoritative.

Theid andmodified fields are required. For schema versions above 1.0.0,theschema_version field is also required. All other fields are optional,although of course an entry with no other metadata is not particularly useful.(It could potentially stand for a reserved ID with no other public information.)

published field

{"published":string}

Thepublished field gives the time the entry should be considered to have beenpublished, as an RFC3339-formatted time stamp in UTC (ending in “Z”).

withdrawn field

{"withdrawn":string}

Thewithdrawn field gives the time the entry should be considered to have beenwithdrawn, as an RFC3339-formatted timestamp in UTC (ending in “Z”). If thefield is missing, then the entry has not been withdrawn. Any rationale for whythe vulnerability has been withdrawn should go into the summary text.

aliases field

{"aliases":[string]}

Thealiases field gives a list of IDs of the same vulnerability in otherdatabases, in the form of theid field. This allows one database to claim thatits own entry describes the same vulnerability as one or more entries in otherdatabases.

Two vulnerabilities can be described as aliases if they affect any givensoftware component the same way: either both vulnerabilities affect the softwarecomponent or neither do. A subsequent patch addresses both of thevulnerabilities (and no others), and vice versa.

Aliases should be considered symmetric (if A is an alias of B, then B is analias of A) and transitive (If A aliases B and B aliases C, then A aliases C).

Aliases shouldnot be used to refer to vulnerabilities in packages upstreamor downstream in a software supply chain from the given OSV record’s affectedpackage(s). For example, if a CVE describes a vulnerability in a languagelibrary, and a Linux distribution package contains that library and thereforepublishes an advisory, the distribution’s OSV record must not list the CVE ID asan alias. Similarly, distributions often bundle multiple upstreamvulnerabilities into a single record. To refer to these upstreamvulnerabilities,upstream should be used.

upstream field

{  "upstream": [ string ]}

Theupstream field gives a list of IDs of upstream vulnerabilities that arereferred to by the vulnerability entry.

For example, a downstream package ecosystem (such as a Linux distribution) mayissue its own advisories that include (possibly multiple) upstreamvulnerabilities.

upstream should be considered transitive but not symmetric. For example, if B isan upstream vulnerability for A, and C is an upstream vulnerability for B, thenC is also an upstream vulnerability for A. At the same time, if B is an upstream vulnerability for A, then A cannot be an upstream vulnerability for B.

related field

{"related":[string]}

Therelated field gives a list of IDs of closely related vulnerabilities, suchas:

• A similar but completely different vulnerability.
• Cases that do not satisfy the strict definition ofaliases orupstream.

Related vulnerabilities are symmetric but not transitive.

summary, details fields

{"summary":string,"details":string}

Thesummary field gives a one-line, English textual summary of thevulnerability. It is recommended that this field be kept short, on the order ofno more than 120 characters.

Thedetails field gives additional English textual details about thevulnerability.

Thesummary field is plain text.

Thedetails field is CommonMark markdown (a subset of GitHub-FlavoredMarkdown). Display code may at its discretion sanitize the input further, suchas stripping raw HTML and links that do not start with http:// or https://.Databases are encouraged not to include those in the first place. (The goal isto balance flexibility of presentation with not exposing vulnerability databasedisplay sites to unnecessary vulnerabilities.)

severity field

{"severity":[{"type":string,"score":string}]}

Theseverity field is a JSON array that allows generating systems to describethe severity of a vulnerability using one or more quantitative scoring methods.Eachseverity item is a JSON object specifying atype andscore property,described below.

severity[].type field

Theseverity[].type property must be one of the types defined below, whichdescribes the quantitative method used to calculate the associatedscore.

severity[].score field

Theseverity[].score property is a string representing the severity score basedon the selectedseverity[].type, as described above.

affected fields

{"affected":[{"package":{"ecosystem":string,"name":string,"purl":string},"severity":[{"type":string,"score":string}],"ranges":[{"type":string,"repo":string,"events":[{"introduced":string,"fixed":string,"last_affected":string,"limit":string}]}],"versions":[string],"ecosystem_specific":{seedescription},"database_specific":{seedescription}}]}

Theaffected field is a JSON array containing objects that describes theaffected package versions, meaning those that contain the vulnerability.

Within each object in theaffected array, thepackage field identifies thepackage containing the vulnerability. In most cases, there should be exactly oneentry in theaffected array per affectedpackage to describe all affectedversions. In rare cases, for example if theecosystem_specific encodesplatform information that doesn’t apply equally to all listed versions andranges, a separate entry with the samepackage in theaffected array may beneeded.

Theversions field can enumerate a specific set of affected versions, and theranges field can list ranges of affected versions, under a given definedordering.A version is considered affected if it lies within any one of theranges or is listed in the versions list. Pseudocode for evaluating if agiven version is affected is availablehere.

Theversions list is generally recommended to always be present, to allowsoftware to easily answer the question “is this specific version affected?”without having to contain code specific to every different ecosystem. If theaffected versions can be accurately summarized by one or more non-overlappingranges, they may be encoded using theranges field with an appropriate type(see below). In this case, the ranges act as a kind of compact form of a largerversions list. Tooling and infrastructure such as https://osv.dev are able toexpand these ranges for supported ecosystems into theversions list for easierconsumption. Products or ecosystems that do not use version identifiers that canbe represented as ranges must include the enumeratedversions list instead.

affected[].package field

Theaffected object’spackage field is a JSON object identifying theaffected code library or command provided by the package. The object itself hastwo required fields,ecosystem andname, and an optionalpurl field.

Theecosystem identifies the overall library ecosystem. It must be one of thestrings in the table below. Thename field is a string identifying the librarywithin its ecosystem. The two fields must both be present, because theecosystem serves to define the interpretation of thename.

Thepurl field is a string following thePackage URL specification thatidentifies the package, without the@version component.This field is optional but recommended.

Different ecosystems can define the same names; they identify differentpackages. For example, these denote different libraries with different sets ofversions and different potential vulnerabilities:

{"ecosystem":"npm","name":"zlib"}

{"ecosystem":"PyPI","name":"zlib"}

Defined ecosystems

The defined ecosystems are:

It is permitted for a database name (the DB prefix in theid field) and anecosystem name to be the same, provided they have the same owner who can makedecisions about the meaning of theecosystem_specific field (see below).

affected[].severity field

Theseverity field is an optional elementdefined here.Thisseverity field applies to a specific package, in cases where affectedpackages have differing severities for the same vulnerability. If any packagelevelseverity fields are set, the top levelseveritymust not be set.

affected[].versions field

Theaffected object’sversions field is a JSON array of strings. Each stringis a single affected version in whatever version syntax is used by the givenpackage ecosystem.

When there is no well-defined packaging ecosystem specified (forexample, general C/C++ libraries), GIT commit ranges are typically the best wayto define vulnerable version ranges. In this case, versions specified in thisarray cannot be relied upon to conform to any particular syntax (e.g. theycould be the upstream Git version tags derived from these GIT commit ranges,which is whatOSV.dev populates this field with). In thissituation, the GIT commit ranges inaffected[].rangesshould be used to match vulnerabilities by Git commit hashes.

affected[].ranges[] field

Theaffected object’sranges field is a JSON array of objects describing theaffected ranges of versions.

affected[].ranges[].type field

In theranges field, thetype field is required. It specifies the type ofversion range being recorded and defines the interpretation of theeventsobject’sintroduced,fixed, and any type-specific fields.

The defined types and their additional fields are:

• SEMVER: The versionsintroduced andfixed are semantic versions as definedbySemVer 2.0.0, with no leading “v” prefix. The relationu < v denotes the precedence order defined insection 11 of SemVer 2.0.Ranges listed with typeSEMVER should not overlap: since SEMVER is a strictlinear ordering, it is always possible to simplify to non-overlapping ranges.

  Specifying one or moreSEMVER ranges removes the requirement to specify anexplicit enumeratedversions list (see the discussion above).

  Some ecosystems may recommend using SemVer 2.0 for versioning without explicitlyenforcing it. In those cases you should use theECOSYSTEM type instead.

• ECOSYSTEM: The versionsintroduced andfixed are arbitrary, uninterpretedstrings specific to the package ecosystem, which does not conform to SemVer2.0’s version ordering.

  It is recommended that you provide an explicitly enumeratedversions list whenspecifying one or moreECOSYSTEM ranges, becauseECOSYSTEM range inclusionqueries may not be able to be answered without reference to the package ecosystem’sown logic and therefore may not be able to be used by ecosystem-independentprocessors. The infrastructure and tooling provided by https://osv.dev alsoprovides automation for auto-populating theversions list based on supportedECOSYSTEM ranges as part of the ingestion process.

• GIT: The versionsintroduced andfixed are full-length Git commithashes. The repository’s commit graph is needed to evaluate whether a givenversion is in the range. The relationu < v is true when commitu is a(perhaps distant) parent of commitv.

  Specifying one or moreGIT ranges does NOT remove the requirement to specifyan explicitly enumeratedversions list, becauseGIT range inclusion queriescannot be answered without access to a copy of the underlying Git repository.

affected[].ranges[].events fields

Theranges object’sevents field is a JSON array of objects. Each objectdescribes a single version that either:

1. Introduces a vulnerability:{"introduced": string}
2. Fixes a vulnerability:{"fixed": string}
3. Describes the last known affected version:{"last_affected": string}
4. Sets an upper limit on the range being described:{"limit": string}

Theseevents objects represent a “timeline” of status changes for the affectedpackage.

The values ofintroduced,fixed,last_affected andlimit are version stringsas defined by theaffected[].ranges[].type field. Note that these versionstrings are not guaranteed to exactly match versions of the package found in theupstream package repository. For example, they may be normalized, or have buildmetadata stripped.

Special values

• introduced allows a version of the value"0" to represent a version thatsorts before any other version.
• limit allows versions containing the string"*" to represent “infinity”.If no limit events are provided, an implicit{ "limit": "*" } is assumed toexist. Multiplelimit events are allowed in the same range.

Requirements

Onlya single type (eitherintroduced,fixed,last_affected,limit) is allowed in each event object. For instance,{"introduced": "1.0.0", "fixed": "1.0.2"} isinvalid.

Entries in theevents array can contain eitherlast_affected orfixedevents, but not both. It’sstrongly recommended to usefixed instead oflast_affected where possible, as it precisely identifies the version whichcontains the fix.last_affected should be thought of as the hard ceilingof the vulnerabilityat the time of publication in the absence of a fixed version.Versions abovelast_affected should be considered unaffected. Unfortunatelythis opens up the possibility for false negatives, which is whyfixed isoverwhelmingly preferred. Anexample is available toillustrate the difference.

Thefixed andlimit events are closely related and involve a similartrade-off forGIT ranges. (See thelimit example for detailsabout how they differ.)events arrays withfixed events must include allother cherrypicked fix commits in all branches as separatefixed events toavoidfalse positive matches in other branches. Conversely,limit eventsrestrict the set of vulnerable commits to those reachable from thelimit,which may result infalse negatives. Where possible, it’s stronglyrecommended to usefixed overlimit.

There must be at least oneintroduced object in theevents array. Whilenot required, it’s also recommended to keep theevents array sorted accordingto theaffected[].ranges[].type of the range.

Seeexamples for examples of how to describe affected ranges.

affected[].ranges[].repo field

Theranges object’srepo field is the URL of the package’s coderepository. The value should be in a format that’s directly usable as anargument for the version control system’s clone command (e.g.git clone).

Theaffected object’sranges field is a JSON array of objects, eachdescribing a single range. The range object defines the fieldstype,events,repo.introduced,fixed, and additional type-specific fields as needed.

This field is required ifaffected[].ranges[].type isGIT.

affected[].ranges[].database_specific field

Theranges object’sdatabase_specific field is a JSON object holdingadditional information about the range as defined by the database from which the record was obtained. Themeaning of the values within the object is entirely defined by the database andbeyond the scope of this document.

Databases should only use this field to store additional context that may be useful in converting from the OSVformat back into the original database representation. Values in this fieldhave no effect on theevaluation algorithm.

affected[].ecosystem_specific field

Theaffected object’secosystem_specific field is a JSON object holdingadditional information about the vulnerability as defined by the ecosystem forwhich the record applies. The meaning of the values within the object isentirely defined by the ecosystem and beyond the scope of this document.

For example, the Go ecosystem includes here information about the affectedfunctions and which modules the packages were found in, along with severity inthe Go project-specific severity scale.

Note that this is a single field with key “ecosystem_specific”, which itselfcontains a JSON object with unspecified fields.

affected[].database_specific field

Theaffected object’sdatabase_specific field is a JSON object holdingadditional information about the vulnerability as defined by the database fromwhich the record was obtained. The meaning of the values within the object isentirely defined by the database and beyond the scope of this document.

In general, the canonical database for a particular ecosystem should record itsinformation inecosystem_specific, allowing other aggregator databases to puttheir own summaries indatabase_specific.

For example, databases that add additional information such as computed CVSSscores for ecosystems that do not provide them could add that information here.

Note that this is a single field with key “database_specific”, which itselfcontains a JSON object with unspecified fields.

Evaluation

The algorithm to evaluate if a packagepkg at versionv is vulnerable isgiven by theIsVulnerable function in the pseudocode below:

funcIsVulnerable(pkg,v,osv)foraffectedinosv.affectedifaffected.package==pkgifIncludedInVersions(v,affected.versions)||IncludedInRanges(v,affected.ranges)returntruereturnfalsefuncIncludedInVersions(v,versions)forversioninversionsifv==versionreturntruereturnfalsefuncIncludedInRanges(v,ranges)forrangeinrangesifBeforeLimits(v,range)vulnerable=falseforevtinsorted(range.events)ifevt.introducedispresent&&v>=evt.introducedvulnerable=trueelseifevt.fixedispresent&&v>=evt.fixedvulnerable=falseelseifevt.last_affectedispresent&&v>evt.last_affectedvulnerable=falseifvulnerablereturntruereturnfalsefuncBeforeLimits(v,range)ifnolimiteventsinrange.events# implicit "*" entry is assumedreturntrueforevtinrange.eventsifevt.limitispresentandv<evt.limitreturntruereturnfalse

Examples

Unfixed vulnerability example

The following expresses that “every possible version is affected”.

"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},]}]

Fixed vulnerability example

The following expresses that “everything before1.0.2” is affected.

"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.0.2"},]}]

Multiple range example

The following expresses that versions in the SemVer ranges[1.0.0,1.0.2) or[3.0.0, 3.2.5) are affected. Everything else is unaffected.

"ranges":[{"type":"SEMVER","events":[{"introduced":"1.0.0"},{"fixed":"1.0.2"},{"introduced":"3.0.0"},{"fixed":"3.2.5"}]}]

Limit events

limit events are typically not necessary for describing numbered (linear)version ranges and should not be used. They are more useful for git ranges,where it has more implications for the evaluation algorithm. Take the followinggit commit graph and git range:

"ranges":[{"type":"GIT","repo":"https://github.com/owner/repo","events":[{"introduced":"X"},{"fixed":"Y"},]}]

Without an explicitlimit, the list of computed affected commits will beX,A, B, C, D, E, F. This is the desired behaviour in most cases.

"ranges":[{"type":"GIT","repo":"https://github.com/owner/repo","events":[{"introduced":"X"},{"limit":"Y"},]}]

Iflimit is set toY, the list of affected commits will beX, A, B, C. Thisis equivalent togit rev-list X..Y (but includingX and excludingY).This may be useful if the scope of a vulnerability entry is limited to a smallset of linear branches. Multiplelimit events may be specified for eachbranch – each expands the scope of the git commit graph to cover.

Note that we did not specify afixed event here aslimit makes it redundant.

last_affected vsfixed example

Understanding the difference betweenlast_affected andfixed is essential toidentifying where false negatives may occur.

The following example expresses that the vulnerability is present in all versionsof the package, up to and including version2.1.214. Versions above2.1.214 areassumed to be free from the vulnerability, but there is a potential for a falsenegative. Thelast_affected field is typically assigned at the time of discovery andassumes the vulnerability will be addressed in the following version.

"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.1.214"},]}]

The following example looks similar, but there are differences in how it is interpreted.The vulnerability is present in all versions of the package up to version2.1.214. Inthis case2.1.214 is not vulnerable. Versions2.1.214 and above do not include thevulnerability and there isn’t the possibility for false negatives that we see in thelast_affected case.

"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.1.214"},]}]

Usingfixed is preferable tolast_affected whenever possible. The use offixedrequires fewer assumptions and eliminates the possibilities for false negatives.

references field

{"references":[{"type":string,"url":string}]}

Thereferences field contains a list of JSON objects describing references.Each object has a string fieldtype specifying the type of reference, and astring fieldurl. Theurl is the fully-qualified URL (including the scheme,typically “https://”) linking to additional information, advisories, issuetracker entries, and so on about the vulnerability itself. Thetype specifieswhat kind of reference the URL is.

The known referencetype values are:

• ADVISORY: A published security advisory for the vulnerability.
• ARTICLE: An article or blog post describing the vulnerability.
• DETECTION: A tool, script, scanner, or other mechanism that allows fordetection of the vulnerability in production environments. e.g. YARA rules,hashes, virus signature, or other scanners.
• DISCUSSION: A social media discussion regarding the vulnerability, e.g.a Twitter, Mastodon, Hacker News, or Reddit thread.
• REPORT: A report, typically on a bug or issue tracker, of the vulnerability.
• FIX: A source code browser link to the fix (e.g., a GitHub commit) Note thatthefix type is meant for viewing by people using web browsers. Programsinterested in analyzing the exact commit range would do better to use theGIT-typedaffected[].ranges entries (described above).
• INTRODUCED: A source code browser link to the introduction of the vulnerability(e.g., a GitHub commit) Note that theintroduced type is meant for viewing by people usingweb browsers. Programs interested in analyzing the exact commit range would do betterto use theGIT-typedaffected[].ranges entries (described above).
• PACKAGE: A home web page for the package.
• EVIDENCE: A demonstration of the validity of a vulnerability claim, e.g.app.any.run replaying the exploitation of the vulnerability.
• WEB: A web page of some unspecified kind.

credits fields

{"credits":[{"name":string,"contact":[string],"type":string,}]}

Thecredits field is a JSON array providing a way to give credit for thediscovery, confirmation, patch, or other events in the life cycle of avulnerability.

Each of the objects in thecredits array must contain at minimum aname fieldspecifying the name of the individual or entity being credited, using whatevernotation they prefer. It can also optionally include acontact JSON array.

credits[].name field

credits[].name should specify the name, label, or other identifier of theindividual or entity being credited, using whatever notation the creditor prefers.For instance, this could contain a real name likeKovács János, an Internet handlelikeerikamustermann, an entity name likeGitHub, or something else. This fieldis required for eachcredits entry.

credits[].contact[] field

Eachcredits[].contact[] entry should be a valid, fully qualified, plain-text URLat which the credited can be reached. Providing contacts is optional.

credits[].type field

The optionalcredits[].type field should specify the type or role of theindividual or entity being credited. It must be one of the following definedcredit types:

• FINDER: identified the vulnerability.
• REPORTER: notified the vendor of the vulnerability to a CNA.
• ANALYST: validated the vulnerability to ensure accuracy or severity.
• COORDINATOR: facilitated the coordinated response process.
• REMEDIATION_DEVELOPER: prepared a code change or other remediation plans.
• REMEDIATION_REVIEWER: reviewed vulnerability remediation plans or code changes for effectiveness and completeness.
• REMEDIATION_VERIFIER: tested and verified the vulnerability or its remediation.
• TOOL: names of tools used in vulnerability discovery or identification.
• SPONSOR: supported the vulnerability identification or remediation activities.
• OTHER: any other type or role that does not fall under the categories described above.

These values and their definitions correspond directly to the credit types defined in theMITRE CVE specification.

Examples

Including a URL and an email address incredits[].contact[] and a credit type:

{"credits":[{"name":"Janina Kowalska","contact":["https://twitter.com/JaninaKowalska01","mailto:nina@kowalska-family.net"],"type":"REMEDIATION_DEVELOPER",}]}

database_specific field

The top-leveldatabase_specific field is a JSON object holding additionalinformation about the vulnerability as defined by the database from which therecord was obtained. The meaning of the values within the object is entirelydefined by the database and beyond the scope of this document.

Unlike theaffected[].database_specific field which is specific to eachaffected product, this top-level field allows aggregator databases to addcustom data that they considered applicable to the whole vulnerability.

Note that this is a single field with key “database_specific”, which itselfcontains a JSON object with unspecified fields.

Examples

Go vulnerability

TheGo vulnerability database uses this format.Seehttps://go.dev/security/vuln/database for example entries and details ofecosystem_specific fields.

NPM vulnerability in GitHub database

GitHub uses this format already for its vulnerabilities. Here is the encoding of one entry:

{"schema_version":"1.2.0","id":"GHSA-r9p9-mrjm-926w","modified":"2021-03-08T16:02:43Z","published":"2021-03-08T16:06:50Z","aliases":["CVE-2020-28498"],"summary":"Use of a Broken or Risky Cryptographic Algorithm","details":"The npm package `elliptic` before version 6.5.4 are vulnerable to Cryptographic Issues via the secp256k1 implementation in elliptic/ec/key.js. There is no check to confirm that the public key point passed into the derive function actually exists on the secp256k1 curve. This results in the potential for the private key used in this implementation to be revealed after a number of ECDH operations are performed.","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N"}],"affected":[{"package":{"ecosystem":"npm","name":"elliptic"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.5.4"}]}]}],"references":[{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2020-28498"},{"type":"WEB","url":"https://github.com/indutny/elliptic/pull/244/commits"},{"type":"WEB","url":"https://github.com/indutny/elliptic/commit/441b7428b0e8f6636c42118ad2aaa186d3c34c3f"},{"type":"WEB","url":"https://github.com/christianlundkvist/blog/blob/master/2020_05_26_secp256k1_twist_attacks/secp256k1_twist_attacks.md"},{"type":"WEB","url":"https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1069836"},{"type":"WEB","url":"https://snyk.io/vuln/SNYK-JS-ELLIPTIC-1064899"},{"type":"WEB","url":"https://www.npmjs.com/package/elliptic"}],"database_specific":{"cwe_ids":["CWE-327"],"severity":"MODERATE","github_reviewed":true}}

OSV vulnerability

OSV uses this format already for its vulnerabilities. Here is the encoding of one entry:

{"schema_version":"1.2.0","id":"OSV-2020-584","published":"2020-07-01T00:00:18.401815Z","modified":"2021-03-09T04:49:05.965964Z","summary":"Heap-buffer-overflow in collator_compare_fuzzer.cpp","details":"OSS-Fuzz report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15499\nCrash type: Heap-buffer-overflow WRITE 3\nCrash state:\ncollator_compare_fuzzer.cpp\n","references":[{"type":"REPORT","url":"https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15499"}],"affected":[{"package":{"ecosystem":"OSS-Fuzz","name":"icu"},"ranges":[{"type":"GIT","repo":"https://github.com/unicode-org/icu.git","events":[{"introduced":"6e5755a2a833bc64852eae12967d0a54d7adf629"},{"fixed":"c43455749b914feef56b178b256f29b3016146eb"}]}]}]}

Rust vulnerability

TheRust advisory DB exports thisformat. Here’s an example entry:

{"schema_version":"1.2.0","id":"RUSTSEC-2019-0033","published":"2019-11-16T00:00:00Z","modified":"2021-01-04T19:02:00Z","aliases":["CVE-2020-25574","CVE-2019-25008"],"summary":"Integer Overflow in HeaderMap::reserve() can cause Denial of Service","details":"HeaderMap::reserve() used usize::next_power_of_two() to calculate\nthe increased capacity. However, next_power_of_two() silently overflows\nto 0 if given a sufficently large number in release mode.\n\nIf the map was not empty when the overflow happens, the library will invoke self.grow(0)\nand start infinite probing. This allows an attacker who controls\nthe argument to reserve() to cause a potential denial of service (DoS).\n\nThe flaw was corrected in 0.1.20 release of http crate.\n","references":[{"type":"REPORT","url":"https://github.com/hyperium/http/issues/352"},{"type":"ADVISORY","url":"https://rustsec.org/advisories/RUSTSEC-2019-0033.html"}],"affected":[{"package":{"ecosystem":"crates.io","name":"http"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.1.20"}]}],"ecosystem_specific":{"functions":["http::header::HeaderMap::reserve"],"keywords":["http","integer-overflow","DoS"],"categories":["denial-of-service"],"severity":"HIGH"}}]}

Python vulnerability

Python currently has acommunity vulnerabilitydatabase using this format. Here is apotential encoding of a vulnerability entry.

{"schema_version":"1.2.0","id":"PYSEC-2021-XXXX","published":"2021-04-01T20:15:00Z","modified":"2021-04-07T15:14:00Z","aliases":["CVE-2021-29421"],"summary":"XXE in pikepdf","details":"models/metadata.py in the pikepdf package 2.8.0 through 2.9.2 for Python allows XXE when parsing XMP metadata entries.","references":[{"type":"FIX","url":"https://github.com/pikepdf/pikepdf/commit/3f38f73218e5e782fe411ccbb3b44a793c0b343a"}],"affected":[{"package":{"ecosystem":"PyPI","name":"pikepdf"},"ranges":[{"type":"GIT","repo":"https://github.com/pikepdf/pikepdf","events":[{"introduced":"0"},{"fixed":"3f38f73218e5e782fe411ccbb3b44a793c0b343a"}]},{"type":"ECOSYSTEM","events":[{"introduced":"2.8.0"},{"fixed":"2.10.0"}]}],"versions":["2.8.0","2.8.0.post1","2.8.0.post2","2.9.0","2.9.1","2.9.2"],"ecosystem_specific":{"severity":"HIGH"}}]}

Debian vulnerability

Debian security advisory (DSA) does not use this format currently, but using theconversion tool,the DSA can be converted into the OSV format.

{"id":"DSA-3029-1","summary":"nginx - security update","affected":[{"package":{"ecosystem":"Debian:7","name":"nginx"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.1-2.2+wheezy3"}]}]}],"aliases":["CVE-2014-3616"],"published":"2014-09-20T00:00:00Z","modified":"2014-09-20T08:18:07Z","details":"\nAntoine Delignat-Lavaud and Karthikeyan Bhargavan discovered that it was\npossible to reuse cached SSL sessions in unrelated contexts, allowing\nvirtual host confusion attacks in some configurations by an attacker in\na privileged network position.\n\n\nFor the stable distribution (wheezy), this problem has been fixed in\nversion 1.2.1-2.2+wheezy3.\n\n\nFor the testing distribution (jessie), this problem has been fixed in\nversion 1.6.2-1.\n\n\nFor the unstable distribution (sid), this problem has been fixed in\nversion 1.6.2-1.\n\n\nWe recommend that you upgrade your nginx packages.\n\n\n","references":[{"type":"ADVISORY","url":"https://www.debian.org/security/2014/dsa-3029"}]}

Ruby vulnerability

Ruby does not use this format currently, but here is a potential translation of one Ruby advisory:

{"schema_version":"1.2.0","id":"CVE-2019-3881","published":"2018-04-23T00:00:00Z","modified":"2021-05-10T00:00:00Z","summary":"Insecure path handling in Bundler","details":"Bundler prior to 2.1.0 uses a predictable path in /tmp/, created with insecure permissions as a storage location for gems, if locations under the user's home directory are not available. If Bundler is used in a scenario where the user does not have a writable home directory, an attacker could place malicious code in this directory that would be later loaded and executed.","affected":[{"package":{"ecosystem":"RubyGems","name":"bundler"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.14.0"},{"fixed":"2.1.0"}]}],"versions":["1.14.0","1.14.1","1.14.2","1.14.3","1.14.4","1.14.5","1.14.6","1.15.0.pre.1","1.15.0.pre.2","1.15.0.pre.3","1.15.0.pre.4","1.15.0","1.15.1","1.15.2","1.15.3","1.15.4","1.16.0.pre.1","1.16.0.pre.2","1.16.0.pre.3","1.16.0","1.16.1","1.16.2","1.16.3","1.16.4","1.16.5","1.16.6","1.17.0.pre.1","1.17.0.pre.2","1.17.0","1.17.1","1.17.2","1.17.3","2.0.0.pre.1","2.0.0.pre.2","2.0.0.pre.3","2.0.0","2.0.1","2.0.2","2.1.0.pre.1","2.1.0.pre.2","2.1.0.pre.3"]}],"references":[{"type":"ADVISORY","url":"https://github.com/advisories/GHSA-g98m-96g9-wfjq"}]}

Haskell Hackage vulnerability

{"affected":[{"package":{"ecosystem":"Hackage","name":"x509-validation"},"ranges":[{"events":[{"introduced":"1.4.0"},{"fixed":"1.4.8"}],"type":"ECOSYSTEM"}],"severity":[{"score":"CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N","type":"CVSS_V3"}]}],"details":"# x509-validation does not enforce pathLenConstraint\n\n*x509-validation* prior to version 1.4.8 did not enforce the\npathLenConstraint value.  Constrained CAs could accidentally (or\ndeliberately) issue CAs below the maximum depth and\n*x509-validation* would accept certificates issued by the\nunauthorised intermediate CAs.\n","id":"HSEC-2023-0006","modified":"2023-07-26T10:34:39Z","published":"2023-07-19T13:59:54Z","references":[{"type":"FIX","url":"https://github.com/haskell-tls/hs-certificate/commit/06d15dbbc53739314760d8504ca764000770e46e"}],"schema_version":"1.5.0","summary":"x509-validation does not enforce pathLenConstraint"}

Haskell GHC vulnerability

We don’t yet have a GHC vulnerability, but it would look like the followingone (similar to the Hackage example, but changing ecosystem to"GHC"):

{"affected":[{"package":{"ecosystem":"GHC","name":"RTS"},"ranges":[{"events":[{"introduced":"9.2.2"},{"fixed":"9.2.3"}],"type":"ECOSYSTEM"}],"severity":[{"score":"CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N","type":"CVSS_V3"}]}],"details":"# x509-validation does not enforce pathLenConstraint\n\n*x509-validation* prior to version 1.4.8 did not enforce the\npathLenConstraint value.  Constrained CAs could accidentally (or\ndeliberately) issue CAs below the maximum depth and\n*x509-validation* would accept certificates issued by the\nunauthorised intermediate CAs.\n","id":"HSEC-2023-0006","modified":"2023-07-26T10:34:39Z","published":"2023-07-19T13:59:54Z","references":[{"type":"FIX","url":"https://github.com/haskell-tls/hs-certificate/commit/06d15dbbc53739314760d8504ca764000770e46e"}],"schema_version":"1.5.0","summary":"x509-validation does not enforce pathLenConstraint"}

R CRAN & Bioconductor vulnerability

R currently has acommunity vulnerabilitydatabase using this format. Here is anexample encoding of a vulnerability entry.

{"id":"RSEC-2023-2","details":"The readxl R package is exposed to a vulnerability owing to its underlying use of libxls library version 1.6.2. The vulnerability originates in the xls_getWorkSheet function within xls.c in libxls. Attackers can exploit this flaw by utilizing a specially crafted XLS file, leading to a Denial of Service (DoS) attack.","affected":[{"package":{"name":"readxl","ecosystem":"CRAN"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.4.1"},{"fixed":"1.4.2"}]}],"versions":["1.4.1"]}],"references":[{"type":"WEB","url":"https://github.com/tidyverse/readxl/issues/679"},{"type":"WEB","url":"https://readxl.tidyverse.org/news/index.html#readxl-142"},{"type":"WEB","url":"https://security-tracker.debian.org/tracker/source-package/r-cran-readxl"},{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-27836"}],"aliases":["CVE-2021-27836"],"modified":"2023-07-13T02:46:57.600Z","published":"2023-07-13T02:46:57.600Z"}

Appendix

Android SoC Vendors

When a package in theAndroid ecosystem is the Linux kernel source code, itsname will be:linux_kernel:, optionally appended with one of the following SoC vendor names indicating applicability of the vulnerability to kernels of that particular vendor:

• AMLogic
• ARM
• Broadcom
• MediaTek
• Marvell
• NVIDIA
• Qualcomm
• Unisoc