The Whistle: Special Bulletin - mTLS bypasses in Traffic Server and Traefik
A short alert between digests: Traffic Server’s Tuesday release fixes fifteen flaws and two of them hand out the wrong client certificate identity; Traefik patched a second connection-identity bug in the same month on related plumbing; and Red Hat is pulling two roots out of its system CA bundle over the eMudhra key leak. mTLS origins, meet your change window.
Traffic Server: fifteen fixes, two of them identity bypasses
Apache shipped the batch Tuesday evening in 9.2.16, 10.1.5, and 10.2.1 (the PMC announcement). The two the watch flagged: CVE-2026-111814 hands a pooled origin TLS session authenticated with one client certificate to a transaction configured to present a different one; the default server_session_sharing.match omits the certificate mask. CVE-2026-111815 resumes a TLS ticket across SNI virtual hosts without the resumed host’s verify_client STRICT re-check. Both carry CVSS v3.1 10.0 (v4.0 trims them to 7.8); if you terminate mTLS toward origins, your identity checks are not doing what the config claims until you patch. The rest bites too: a 10.0 in the experimental magick plugin (client-controlled ImageMagick arguments in its default config), a 9.4 unauthenticated cache read/write through tsmemcache, a 9.3 malformed-302 carve-out ending in cache poisoning and framing desync, and request-smuggling paths including CVE-2025-31699 and CVE-2026-111809. No exploitation reported, no public PoC. Upgrade to 9.2.16 / 10.1.5 / 10.2.1 and drop the experimental plugins you did not consciously deploy (magick, tsmemcache, wasm, plus origin_server_auth, whose CVE-2026-111812 signs client-controlled AWS headers with the proxy’s IAM credentials). If you are still on 8.x, no fix is coming.
Traefik: second NTLM-connection fix this month
CVE-2026-114642 is the follow-on to early October’s HTTP/3 bug, same plumbing, different slot. When a backend answers with a WWW-Authenticate: NTLM or Negotiate challenge, Traefik pins a dedicated backend round tripper to the client connection. That slot was not keyed by the ServersTransport, so the next request on the same keep-alive connection could route to a different service and inherit the first service’s TLS client configuration wholesale: without the second service’s root CAs, server name, or certificate verification, and with the wrong client certificate presented to its backend. An unauthenticated client arms it with one ordinary request. CVSS 8.7 on the 3.1 scale (7.0 on 4.0). Fixed in v2.11.58 and v3.7.14; the 3.0-3.6 lines are past end-of-life and get nothing. The earlier fix in this class (CVE-2026-88007) landed in v2.11.57/3.7.13, so check which version your Helm charts actually pin before assuming you are clean.
The eMudhra cleanup reached the OS trust store
Yesterday’s bulletin covered the eight weak eMudhra/emSign intermediate keys; the browser, Go, and curl side has held. The new piece is CVE-2026-114406 (CVSS 6.8, Red Hat CNA): the system ca-certificates package in Red Hat products shipped root certificates of the authorities that signed the weak intermediates, so a holder of the leaked keys could mint certificates for arbitrary hostnames that RHEL-native TLS clients would trust. Per the Fedora/RH tracker, Red Hat is removing the “emSign ECC Root CA - G3” and Comodo “AAA Certificate Services” roots, since the crypto libraries behind the system store cannot reliably distrust only specific intermediates. The interim fix is a trust extract blocklist for those two roots, then update-ca-trust. Check your build images: run update-ca-trust on current packages, apply the tracker’s extract workaround on older ones, and confirm both roots are gone from the bundle.
Two proxy upgrades and one CA-bundle scrub is the whole bulletin. Something wrong here, or a stronger opinion? info@stackref.com always works.
This post was created with a Hermes AI agent (hermesagent.ai) from a weekly news gathering workflow, then reviewed and approved by Keith before publication.