Go vulnerability reports are collected from several sources, curated by the Go security team, and published in the OSV format. Each report carries a review status. REVIEWED means a person checked it. UNREVIEWED means a tool generated it from another source such as a CVE or a GitHub advisory.
What a report contains
The Go vulnerability database documents its own record shape. Key points:
- IDs take the form GO-YEAR-ENTRYID.
- The ecosystem is always Go, and the package name is the module path, with
stdlibfor the standard library andtoolchainfor the go command. - An
importslist under the ecosystem specific data names affected import paths and symbols, and can include operating system and architecture. - A
database_specific.urlpoints to the report page. - An
aliaseslist gives IDs of the same issue elsewhere.
The symbol list is the unusual part. Most advisory data stops at the package. Naming symbols lets a tool ask a sharper question: does your code call the affected function, or only import the module?
Review status
| Status | How it was made | What to expect |
|---|---|---|
| UNREVIEWED | Generated automatically from another source such as a CVE or GHSA | Fast, but module and version mapping may be broad |
| REVIEWED | Written by the Go team, or generated and then checked by a team member who added data where fit | More precise ranges and symbols |
The documentation warns that tooling "attempts to automatically map modules and versions" from source advisories, and that the mapping can fail. When it does, a report may conservatively list all Go versions as affected. If a scan shows a Go module flagged across every version, check the review status before assuming the module is broken.
Excluded reports
Some CVEs and GHSAs are deliberately left out for reasons such as NOT_A_VULNERABILITY or WITHDRAWN. The documentation says excluded reports are not currently served through the API.
How to read the data yourself
- Fetch
https://vuln.go.dev/index/vulns.jsonfor IDs, modified times and aliases. - Fetch
/ID/GO-YEAR-ENTRYID.jsonfor one full report. - Look at
affected[].rangesfor the introduced and fixed versions. - Look at
ecosystem_specific.importsfor symbols. - Check the review status in the database specific fields.
The endpoints take no query parameters and need no special headers. The documentation also says the modified time should not be compared with the wall clock for cache invalidation, so store the value and compare it to the next value you read.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a finding drops down the list when the vulnerable function is never called. Symbol data in a report is what makes that check possible.
Safeguard reachability analysis checks whether your code reaches the affected code path, and SBOM scanning shows what you ship. A free scan takes a few minutes.
Quick check
Is an UNREVIEWED Go report wrong?
No. It is machine generated from another source and may be less precise on versions or symbols. Treat it as a lead to confirm.
Why would every Go version be listed as affected?
The documentation says automatic mapping can fail, and in that case a report may conservatively list all versions.
Sources
Last reviewed: 19 October 2026.
