projectdiscovery / projectdiscovery/utils
x/crypto/openpgp (GO-2026-5932, no fix available) pulled in via go-github v30 in utils/update
@dwisiswant0 is already working on this.
Since Sep 16, 2026.
- Dominant language
- Go
- Stars
- 142
- Forks
- 56
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 7
Description
Summary
cdncheck transitively pulls in golang.org/x/crypto/openpgp, which carries the Go vulndb advisory GO-2026-5932 ("unmaintained, unsafe by design, and has known security issues"). The advisory has no fixed version — the package is deprecated outright — so it cannot be cleared by bumping x/crypto.
It can be cleared by bumping google/go-github, which is where the import actually comes from.
Dependency chain
go mod why golang.org/x/crypto/openpgp at v1.3.1:
github.com/projectdiscovery/cdncheck/internal/runner
github.com/projectdiscovery/utils/update
github.com/google/go-github/v30/github
golang.org/x/crypto/openpgp
projectdiscovery/utils/update depends on go-github v30, released in 2020. That version imports x/crypto/openpgp in github/git_commits.go for commit signing.
Why bumping go-github fixes it
Current go-github has no x/crypto dependency at all. v92.0.0's go.mod requires only go-cmp and go-querystring — commit signing was refactored behind a MessageSigner interface, and openpgp now appears only in a doc comment.
So bumping go-github from v30 to a current major in projectdiscovery/utils drops the openpgp import entirely, with no replacement crypto dependency needed.
Scope
The fix belongs in projectdiscovery/utils rather than here — happy to move this issue there if you'd prefer. Filing it against cdncheck because that's where it surfaced, and because utils/update is shared, this likely affects every ProjectDiscovery tool that uses the self-update machinery, not just cdncheck.
How this surfaced
We build cdncheck from pinned source in our own CI and gate on govulncheck, which is reachability-aware. At v1.3.1 it reported 7 reachable vulnerabilities. Six clear cleanly:
| Advisory | Resolution |
|---|---|
GO-2026-6218 (net/url) |
Go 1.25.13 |
GO-2026-6090 (crypto/tls) |
Go 1.25.13 |
GO-2026-6088 (encoding/xml) |
Go 1.25.13 |
GO-2026-5972 (encoding/asn1) |
Go 1.25.13 |
GO-2026-5026 (net/http idna) |
Go 1.25.13 |
GO-2026-5320 (yuin/goldmark XSS) |
goldmark v1.7.17 |
GO-2026-5932 is the only one left, and it's the only one with no available fix — hence this issue.
Every reported trace reaches it through update.init, i.e. the self-update code path, not through cdncheck's actual classification logic. Reproduced with:
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./cmd/cdncheck/...
Thanks for the tool — the embedded dataset and JSONL output made it straightforward to vendor.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.