CVE-2026-33810

What it actually does

The flaw is in Go certificate-chain verification. When a trusted certificate chain contains DNS name constraints that explicitly exclude a domain, the verifier may fail to apply those excluded constraints to wildcard DNS Subject Alternative Names if the wildcard name uses different letter casing than the constraint. Because DNS names are case-insensitive, a certificate such as a mixed-case wildcard SAN could be accepted even though it should be rejected by the issuing CA's name constraints. This can undermine TLS identity validation or other X.509-based trust decisions in Go applications that rely on the affected verifier and trust the relevant root or system certificate pool.

Why it matters to the business

Applications written in Go may trust certificates for names that should have been blocked by CA name constraints, creating a risk of impersonation, traffic interception, or acceptance of unauthorized service identities. The highest business risk is to systems that depend on private PKI, constrained intermediates, mutual TLS, service mesh identity, API clients, or certificate-based authorization. Although EPSS is currently low and stable, the CVSS score is high because exploitation can affect confidentiality without credentials or user interaction. Go is widely used in infrastructure, cloud tooling, and backend services, so remediation often requires rebuilding and redeploying statically linked applications rather than only patching an operating system package.

How an attack unfolds

An attacker first needs a certificate chain that is otherwise trusted by the target Go application, typically through a root CA in the application's VerifyOptions.Roots pool or the host system trust store. The chain includes a CA certificate with excluded DNS name constraints that should prevent issuance for a target domain or DNS subtree. The attacker obtains or presents an end-entity certificate containing a wildcard DNS SAN for the excluded name but with different letter casing than the constraint. When the affected Go verifier processes the chain, it may not correctly match the excluded constraint against the mixed-case wildcard SAN. If hostname verification and the rest of the chain validation succeed, the application can accept the certificate as valid. In a realistic attack, this could enable a man-in-the-middle position, fraudulent service endpoint, or unauthorized mTLS identity to be accepted by Go-based clients or services.

How to fix it

Upgrade to a Go release that contains the certificate-verification fix when available from the Go project or operating-system/vendor distribution. Because Go applications are commonly statically linked, rebuild and redeploy all binaries built with affected Go toolchains; patching only the runtime host may not remediate deployed binaries. If exact fixed versions are not yet available in advisory metadata, track the Go security advisory and vendor package channels, then standardize on the first patched release or later. Review applications using crypto/x509, crypto/tls, custom VerifyOptions.Roots, system certificate pools, private PKI, constrained intermediates, or mTLS identity. As temporary risk reduction, restrict trusted roots and intermediates to the minimum necessary, avoid trusting constrained CA hierarchies for high-risk external connections where possible, add application-level post-verification checks for expected DNS identities, and consider rejecting certificates with wildcard DNS SANs whose casing does not match normalized policy expectations until patched.

How to confirm the fix worked

Inventory Go versions used to build deployed binaries using source build metadata, SBOMs, container image metadata, package managers, and commands such as go version -m on binaries where available. Confirm that all relevant applications have been rebuilt with a patched Go toolchain, not merely restarted on patched hosts. Create a regression test using a trusted test root, a constrained intermediate with an excluded DNS constraint, and a leaf certificate containing a mixed-case wildcard DNS SAN for the excluded domain; a fixed verifier should reject the chain. Validate TLS and mTLS paths that use custom root pools, system pools, private PKI, service mesh certificates, API clients, agents, and gateways. Review CI/CD build images and base containers to ensure future builds use the patched Go release.

Typical attack path

1. Identify a Go-based client, service, proxy, or agent that validates X.509 certificates using the affected Go certificate verifier.
2. Determine that the application trusts a root or CA hierarchy containing DNS name constraints with excluded domains.
3. Obtain or craft a certificate chain that is otherwise trusted and includes a wildcard DNS SAN using different casing than the excluded DNS constraint.
4. Present the certificate during a TLS, mTLS, API, service-mesh, or other X.509-authenticated connection.
5. Rely on the affected verifier to accept the wildcard SAN despite the excluded DNS constraint.
6. Use the accepted certificate to impersonate a service, intercept traffic, or gain unauthorized certificate-based access.

How to detect it

There is no reliable universal host artifact for exploitation because the issue occurs during certificate validation and may leave no application error. Detection should focus on certificate and connection telemetry. Review TLS inspection logs, reverse-proxy logs, service-mesh telemetry, API gateway logs, mTLS authentication logs, endpoint EDR network metadata, and packet captures for certificates containing wildcard DNS SANs with unusual or mixed-case domain names. Compare observed certificate chains against approved issuing CAs and expected service identities, especially where constrained intermediates are used. Search certificate transparency logs and internal CA issuance records for wildcard SANs whose case differs from policy or from excluded DNS constraints. Investigate successful TLS or mTLS connections using unexpected certificate chains, unexpected wildcard certificates, newly issued certificates for sensitive domains, or certificate issuers that should be constrained away from those names. If exploitation is suspected, preserve certificate chains, TLS handshake metadata, application access logs, proxy logs, and any captured leaf/intermediate certificates, then assess whether secrets, session tokens, or credentials may have been exposed through an impersonated endpoint.

What your security team should do

• Prioritize inventory of externally exposed Go services, security gateways, API clients, agents, service mesh components, and any Go software using private PKI or mTLS.
• Track the official Go and vendor advisories and upgrade to the first fixed Go version or later as soon as it is available.
• Rebuild and redeploy statically linked Go binaries; do not assume host patching remediates compiled applications.
• Identify trusted CA chains with DNS name constraints and excluded DNS subtrees, especially private or partner PKI hierarchies.
• Temporarily reduce trust scope for constrained intermediates and high-risk roots until patched builds are deployed.
• Add tests to CI that verify excluded DNS constraints are enforced against wildcard SANs with mixed case.
• Increase monitoring for unusual certificates, mixed-case wildcard SANs, unexpected issuing CAs, and certificate changes on sensitive TLS or mTLS endpoints.
• Treat suspected exploitation as potential service impersonation or traffic interception and rotate credentials or tokens that may have traversed affected TLS sessions.