CVE-2026-111943: Compromised Intermediate Certificate Authority

Original Article ↗ Hacker News Discussion ↗

A compromised intermediate certificate authority operated by eMudhra has been found to use disastrously weak elliptic-curve keys, allowing attackers to derive private keys from public certificates and mint “valid” TLS certificates for any domain. Operating systems, languages, and tools are racing to revoke or blacklist the affected intermediates, with special attention on cases where software ships its own trust store (e.g. Go’s crypto/x509, Python’s certifi, uv, containers, and embedded devices) rather than relying solely on OS updates. Commenters highlight both how to test whether clients still trust the bad CAs and how fragmented trust-store management and layered package managers make timely, comprehensive remediation surprisingly difficult.

Nature of the incident

  • eMudhra generated eight intermediate CA keys so weakly that private keys can be derived from the public certs.
  • Anyone with those keys can issue “valid” TLS certs for arbitrary domains (banks, PyPI, etc.), enabling MITM attacks.
  • Multiple posters link to the same explanation site and prior HN threads; this Go-focused CVE is part of a larger, ongoing eMudhra incident.

Go-specific angle and trust stores

  • Discussion centers on Go’s crypto/x509 using the system trust store plus an internal denylist.
  • The CVE is essentially: some Go versions lack the updated denylist entries for the compromised intermediates.
  • Clarified that Go will reject the certs if either the OS has removed them or the Go denylist is updated.
  • Important nuance: binaries statically embed Go’s trust logic, so you must rebuild/redeploy apps with a newer Go toolchain to benefit.

OS and distro responses

  • Gentoo and Slackware are reported as updated; specific Gentoo emerge commands are shared.
  • macOS appears to distrust the certs at the OS level, though some tools see different trust views.
  • Red Hat’s response is criticized as incomplete and slow; only a workaround removing two Comodo roots is noted, marked “ongoing.”
  • Comparisons are drawn: some prefer Debian due to faster security updates; others still favor RHEL’s overall patch quality but note persistent delays.

Other ecosystems and tooling

  • Python, certifi, uv, bun, Java (AWS Corretto), and other stacks may embed their own CA bundles and need explicit updates.
  • Separate guidance is referenced for Python users; uv itself is noted as having its own trust store.
  • Browsers often have independent CRLs and may be safe even when CLI tools (curl, wget) are not.

Testing and local mitigation

  • Several test endpoints are shared; a correct outcome is TLS failure with “unable to get local issuer certificate.”
  • People use curl and Python urllib against these hosts to verify trust behavior.
  • Workarounds include pointing curl on macOS to an updated Homebrew CA bundle; scripts for managing CA certs on Debian are shared.

Operational and meta themes

  • Many express frustration with multi-layered package management, containers, and scattered trust stores.
  • Some advocate containers; others argue for simpler host-based deployment and systemd hardening.
  • There is debate about relying on LLMs/agents for automated patching: helpful for coverage, but risks operator complacency.
  • Brief discussion on terminology (“monster-in-the-middle” vs “man-in-the-middle”) and on how quickly this became “old news.”