crypto/x509: TLS Impersonation via Compromised eMudhra Intermediate CA Keys

eMudhra generated the private keys of eight of its intermediate CA certificates incorrectly, which makes the keys trivially recoverable. These intermediates chain to roots that most operating system and language trust stores include, such as emSign Root TLS CA - G3. Anyone holding the keys can issue a certificate for any hostname, or a client certificate, that validates as trusted. The intermediates were revoked for key compromise on October 18 and 19, 2026, and browsers block them, but Go does not check revocation, so a Go program keeps accepting these chains for as long as its trust store includes the roots.

Go 1.26.10 adds a hardcoded denylist to crypto/x509: Certificate.Verify now rejects any chain that goes through one of the eight intermediates, regardless of the system trust store or the CA files you configure.

KrakenD verifies certificate chains in two directions, and both are exposed:

• Gateway to services: TLS connections to HTTPS backends, JWK and identity provider URLs, and telemetry exporters. An attacker able to intercept that traffic can present a forged certificate and read or alter requests and responses, including credentials.
• Clients to gateway with mTLS: when you enable enable_mtls, KrakenD also trusts the system CA pool unless you set disable_system_ca_pool to true. An attacker can mint a client certificate under a compromised intermediate and authenticate against the gateway without intercepting any traffic.

Upgrading changes behavior on purpose: once you run the fixed version, any service whose certificate chains through one of these intermediates fails verification with an x509 error. Those certificates are already revoked, so their owners must reissue them anyway. If you cannot upgrade right away, update the CA bundle of the operating system or image where KrakenD runs, and set disable_system_ca_pool to true with an explicit ca_certs list on mTLS deployments.