x/vulndb: potential Go vuln in go.etcd.io/bbolt

[quocvibui]

Acknowledgement

• The maintainer(s) of the affected project have already been made aware of this vulnerability.

Description

Bucket.Stats() in go.etcd.io/bbolt panics with an index out-of-range
when encountering a branch page with zero elements. At line 664 of
bucket.go, p.BranchPageElement(p.Count() - 1) is called without
checking if Count() != 0. When a branch page has zero elements
(e.g., due to database corruption or partial writes), the index
underflows causing an unrecoverable panic.

This is a public API that does not return an error, so callers have
no way to handle the failure. Any process calling Stats() on a
corrupted bucket crashes entirely. This affects downstream users
such as etcd, Kubernetes components, and Consul.

CWE: CWE-125 (Out-of-bounds Read)

Fix PRs:

• Main: bucket: add count guard for branch pages in Stats etcd-io/bbolt#1171
• Backport 1.4: bucket: add count guard for branch pages in Stats (backport 1.4) etcd-io/bbolt#1172
• Backport 1.3: bucket: add count guard for branch pages in Stats (backport 1.3) etcd-io/bbolt#1173

Maintainer confirmed: 2026-03-30
Fix merged: All PRs merged (main + backports to 1.4 and 1.3)
Issue: etcd-io/bbolt#1170

Affected Modules, Packages, Versions and Symbols

Module: go.etcd.io/bbolt
Package: go.etcd.io/bbolt
Symbol: Bucket.Stats
Versions: all versions before fix (introduced: 0, fixed: see merged PRs #1171, #1172, #1173)

CVE/GHSA ID

No response

Fix Commit or Pull Request

etcd-io/bbolt#1171

References

etcd-io/bbolt#1170
etcd-io/bbolt#1170 (comment)
etcd-io/bbolt#1171
etcd-io/bbolt#1172
etcd-io/bbolt#1173

Additional information

No response

[gopherbot]

Change https://go.dev/cl/762741 mentions this issue: data/reports: add GO-2026-4923

[ahrtr]

I (as a bbolt maintainer) didn't know you raised this vulnerability for etcd-io/bbolt. If you read my comment etcd-io/bbolt#1171 (comment), I wouldn't treat it as a vulnerability as it would never happen in a production environment.

[ahrtr]

Can we mark this CVE as invalid to avoid unnecessary confusion?

[ahrtr]

Just raised #4938 to request to mark this CVE as invalid

[quocvibui]

Sorry about the hassle and confusion. I should have contacted you before submitting. I would also like to withdraw the report.

[ahrtr]

I would also like to withdraw the report.

Yes, please if it's possible. Note I also raised #4938. I am OK either way. It's up to golang security team.

[twpayne]

It would also be helpful if govulncheck had a flag to ignore invalid vulnerabilities like this one. Many build pipelines fail when any vulnerability is found, and currently the only other option is to disable govulncheck completely when the database contains invalid vulnerabilities.

See mescon/Muximux@954b5e3 as an example of a project disabling govulncheck because of this exact invalid vulnerability. I've also started a discussion on golang-nuts.