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.
Summary
cdnchecktransitively pulls ingolang.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 bumpingx/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/openpgpatv1.3.1:projectdiscovery/utils/updatedepends ongo-githubv30, released in 2020. That version importsx/crypto/openpgpingithub/git_commits.gofor commit signing.Why bumping go-github fixes it
Current
go-githubhas nox/cryptodependency at all. v92.0.0'sgo.modrequires onlygo-cmpandgo-querystring— commit signing was refactored behind aMessageSignerinterface, and openpgp now appears only in a doc comment.So bumping
go-githubfrom v30 to a current major inprojectdiscovery/utilsdrops the openpgp import entirely, with no replacement crypto dependency needed.Scope
The fix belongs in
projectdiscovery/utilsrather than here — happy to move this issue there if you'd prefer. Filing it against cdncheck because that's where it surfaced, and becauseutils/updateis 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. Atv1.3.1it reported 7 reachable vulnerabilities. Six clear cleanly:net/url)crypto/tls)encoding/xml)encoding/asn1)net/httpidna)yuin/goldmarkXSS)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:Thanks for the tool — the embedded dataset and JSONL output made it straightforward to vendor.