Bug 2494345

Summary:	CVE-2026-27145 toolbox: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries [fedora-all]
Product:	[Fedora] Fedora	Reporter:	jkelly <jkelly>
Component:	toolbox	Assignee:	Debarshi Ray <debarshir>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	high
Version:	rawhide	CC:	debarshir, go-sig, harrymichal, nixuser, patrick, sumukher
Target Milestone:	---	Keywords:	Security, SecurityTracking
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	{"flaws": ["1765a0c8-adb1-4223-88bf-d35a230e256a"]}
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-07-01 21:06:14 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2484207

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 {