[ctx]ctxseccontext security: attacks on the harness and context layer of AI agents, plus exploited-now news, hunting and playbooks.

← Cybersecurity News · markdown

confirmed (Go security release + CCADB revocation records: reason cACompromise)

Go 1.27.3 / 1.26.10 (CVE-2026-111943, URGENT track) hard-block eight eMudhra intermediate CA keys that were revoked Oct 18-19 for 'cACompromise'; rebuild Go programs to get the block

Go released 1.27.3 and 1.26.10 (listed on go.dev as released Oct 19) with a single crypto/x509 security fix, CVE-2026-111943 (Go issue #82345). It was handled on Go's URGENT track, which is reserved for threats to the ecosystem's integrity or severe active exploitation. The issue text says Go is "blocking trust in a small set of intermediate certificates due to specific security concerns around their operation". Verify now drops chains containing them, and the Go team "highly recommend[s] immediately upgrading". The patch lists only SHA-256 hashes of the keys.

A commenter matched the hashes to eMudhra (emSign) intermediates, and the public CCADB revocation list we checked backs that up. Eight eMudhra intermediates, EM DV/OV/EV TLS CA - G3B and G3C (under emSign Root TLS CA - G3) and EM OV CS CA - G3B and G3C (code signing, under emSign Root CS CA - G3), were revoked on Oct 18 with RFC 5280 reason (2) cACompromise. The Sectigo-issued cross-certificates for the same eight (issuer AAA Certificate Services) were revoked on Oct 19, also as cACompromise. Go matches on the public key rather than the certificate, so those cross-signed copies are blocked too. On the issue, Filippo Valsorda wrote that "the keys are compromised and their certificates revoked", and that because revocation doesn't propagate to applications through Linux root stores, Go had to hardcode the block. According to The Hacker News, Mozilla added six emSign Root TLS CA - G3 intermediates to OneCRL on Oct 17 in a non-public bug. As of Oct 20 eMudhra had posted no notice, and no browser vendor has explained the compromise.

What it means: Go's verifier does no revocation checking, so only rebuilt binaries get the block, and THN found no off switch (it appears to apply even with custom root pools). Connections from rebuilt Go clients to any service whose certificate chains through these intermediates will fail with x509: no valid chains built. Do now: rebuild and redeploy Go services and CLIs on 1.27.3/1.26.10 (Go 1.25 and older get no fix). Check whether any of your endpoints or vendors use EM ... G3B/G3C certificates and get them reissued from a different CA. Make sure non-Go TLS clients honor revocation or update their trust stores. How the keys were compromised and whether any were misused is not public.

Sources: Go issue #82345 (CVE-2026-111943) · Go release history (1.27.3 / 1.26.10) · CCADB: revoked intermediate certificates (CSV) · The Hacker News (Oct 20)