Bug 2494345 - CVE-2026-27145 toolbox: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries [fedora-all]
Summary: CVE-2026-27145 toolbox: golang crypto/x509: Denial of Service via excessive p...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: toolbox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Debarshi Ray
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["1765a0c8-adb1-4223-88bf-d...
Depends On:
Blocks: CVE-2026-27145
TreeView+ depends on / blocked
 
Reported: 2026-06-29 14:25 UTC by jkelly
Modified: 2026-07-01 21:06 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-07-01 21:06:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description jkelly 2026-06-29 14:25:23 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname. With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.

Comment 1 Debarshi Ray 2026-07-01 21:06:14 UTC
I don't think the toolbox RPM is vulnerable to this certificate validation bug.  Here's an actual analysis of the code.

First, let's get rid of all the Go tests:

[rishi@topinka toolbox-0.3]$ find src -name "*_test.go" -delete

Let's find the shortest path in the import graph to crypto/x509:

[rishi@topinka toolbox-0.3/src]$ go mod why -vendor crypto/x509
# crypto/x509
github.com/containers/toolbox/pkg/utils
github.com/spf13/viper
github.com/spf13/afero
net/http
crypto/tls
crypto/x509

To be sure that there are no other paths in the import graph, let's remove pkg/utils and try again:

[rishi@topinka toolbox-0.3/src]$ rm --force --recursive pkg/utils
[rishi@topinka toolbox-0.3/src]$ go mod why -vendor crypto/x509
# crypto/x509
(main module does not need to vendor package crypto/x509)

Now let's dig deeper.

[rishi@topinka toolbox-0.3/src]$ grep --line-number --recursive crypto/x509 *
[rishi@topinka toolbox-0.3/src]$ grep --line-number --recursive crypto/tls *
[rishi@topinka toolbox-0.3/src]$ grep --line-number --recursive net/http *
vendor/github.com/stretchr/testify/assert/assertion_format.go:6:	http "net/http"
vendor/github.com/stretchr/testify/assert/assertion_forward.go:6:	http "net/http"
vendor/github.com/stretchr/testify/assert/http_assertions.go:5:	"net/http"
vendor/github.com/stretchr/testify/assert/http_assertions.go:6:	"net/http/httptest"
vendor/github.com/spf13/afero/httpFs.go:18:	"net/http"

Of these, vendor/github.com/stretchr/testify is a module that's meant for testing.  So, let's ignore that, which leaves:

vendor/github.com/spf13/afero/httpFs.go:18:	"net/http"

In vendor/github.com/spf13/afero/httpFs.go, net/http is used to implement the HttpFs type, which is instantiated by the NewHttpFs function.  There's nothing in Toolbx or its dependencies that uses this type:

[rishi@topinka toolbox-0.3/src]$ grep --line-number --recursive NewHttpFs *
vendor/github.com/spf13/afero/README.md:321:httpFs := afero.NewHttpFs(<ExistingFS>)
vendor/github.com/spf13/afero/httpFs.go:52:func NewHttpFs(source Fs) *HttpFs {


Note You need to log in before you can comment on or make changes to this bug.