CVE-2026-111943: 
Go 취약성 분석 및 완화

CVE-2026-111943 is a security feature bypass vulnerability in Go's crypto/x509 package, classified under CWE-295 (Improper Certificate Validation). It arises from security concerns around a small set of intermediate certificates issued by the Certificate Authority (CA) eMudhra, whose private keys were found to be compromised. Go releases 1.27.3 and 1.26.10 address the issue by blocking trust in the affected intermediate certificates within the Verify function. The CVE was published on October 20, 2026, and carries a CVSS v3.1 base score of 6.8 (Medium) per Red Hat's assessment, though Oracle's preliminary scoring rates it 8.1 (High) (Red Hat Bugzilla, Oracle Linux).

The root cause is improper certificate validation (CWE-295) in Go's crypto/x509 package, which previously trusted TLS certificate chains containing a specific set of eMudhra intermediate certificates whose keys were compromised. The Verify function did not filter out chains containing these distrusted intermediates, meaning any certificate issued under them could be presented as valid. Exploitation maps to CAPEC-459 (Creating a Rogue Certification Authority Certificate) and CAPEC-475 (Signature Spoofing by Improper Validation), enabling man-in-the-middle (MitM) attacks against Go-based TLS clients. The fix, committed in the Go repository and tracked as Go issue #82345, adds explicit distrust logic to filter chains containing the eight affected eMudhra intermediate CA keys (Red Hat Bugzilla, Go Issue, Go Commit).

An unauthenticated attacker in possession of a fraudulent certificate issued by the compromised eMudhra intermediate CAs could bypass TLS/SSL validation in Go applications, enabling man-in-the-middle attacks to intercept and decrypt encrypted communications or impersonate legitimate websites and services. The confidentiality and integrity impacts are both rated High, as sensitive data in transit could be exposed or tampered with. Availability is not directly impacted. The scope extends to any Go application or service relying on crypto/x509 for certificate chain validation, including downstream projects such as Docker and Atlantis that have issued updated releases in response (Red Hat Bugzilla, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). However, the underlying condition — compromised eMudhra intermediate CA private keys — is the prerequisite for exploitation, and the threat is considered credible enough that Mozilla, Google, and Apple also moved to block the affected certificates (BleepingComputer). The CVE status remains "Reserved" with no EPSS score or CISA KEV catalog entry published as of the disclosure date. The attack complexity is rated High, requiring an attacker to obtain or forge a certificate from the compromised intermediates and position themselves in the network path of a victim.

1. Obtain a fraudulent certificate: Leverage access to the compromised eMudhra intermediate CA private keys to sign a fraudulent TLS certificate for a target domain (e.g., a banking or enterprise service).
2. Position for MitM: Gain a network-level position between a Go-based TLS client and the target server — for example, via ARP spoofing, DNS hijacking, or a rogue Wi-Fi access point.
3. Present the fraudulent certificate: Intercept the TLS handshake and present the attacker-controlled certificate signed by the compromised eMudhra intermediate. On unpatched Go versions, crypto/x509's Verify function accepts the chain as valid.
4. Intercept or tamper with traffic: With TLS terminated at the attacker's node, decrypt, read, or modify the plaintext application data before re-encrypting and forwarding to the legitimate server.
5. Conduct phishing or credential theft: Alternatively, serve a cloned site using the fraudulent certificate to harvest credentials from users whose browsers or Go clients trust the eMudhra chain (Red Hat Bugzilla, Go Issue).

• Network: Unexpected TLS certificates presented during handshakes with Subject or Issuer fields referencing eMudhra intermediate CAs; certificate serial numbers not matching those issued by the legitimate target service; TLS connections terminating at unexpected IP addresses.
• Logs: TLS handshake logs showing certificate chains containing eMudhra intermediate CA subjects on Go services that do not use eMudhra-issued certificates; certificate validation errors or warnings in application logs after patching (indicating previously accepted fraudulent certs).
• File System: Presence of certificate files with eMudhra intermediate CA issuers in application trust stores or configuration directories that are not expected in the environment.
• Process/Application: Go applications (pre-patch) accepting TLS connections with certificates issued under the eight blocked eMudhra intermediate keys; downstream tools (Docker, Atlantis, etc.) running versions prior to their respective patched releases that include Go 1.27.3 or 1.26.10.

The primary remediation is to upgrade Go to version 1.27.3 or 1.26.10, which include the distrust of the affected eMudhra intermediate certificates in crypto/x509 (Red Hat Bugzilla). Red Hat has issued patches for RHEL 8 (RHSA-2026:86203), RHEL 9 (RHSA-2026:86196), and RHEL 10 (RHSA-2026:86093). Oracle Linux has released updated ca-certificates packages for OL 8, 9, and 10 (Oracle Linux). Organizations should also audit their environments for any TLS certificates issued by the affected eMudhra intermediates and replace them with certificates from a trusted, uncompromised CA. Downstream Go-based projects (e.g., Docker v29.9.2, Atlantis v0.48.2) should be updated to versions that incorporate the patched Go runtime.

The Go team issued an emergency security release (Go 1.27.3 and 1.26.10) and announced the issue via the golang-announce mailing list, strongly recommending immediate upgrades (golang-announce). Mozilla, Google, and Apple independently moved to block the compromised eMudhra CA certificates in their respective trust stores, signaling broad industry concern (BleepingComputer). The Hacker News community and security researchers on Mastodon (infosec.exchange) discussed the incident actively, with coverage from The Hacker News, BleepingComputer, and Cyberkendra highlighting the emergency nature of the release. The OkHttp project published a blog post on mitigating bad roots in their library, and the Rust ecosystem issued related advisories (RUSTSEC-2026-0381, RUSTSEC-2026-0382) for affected Rust crates, reflecting the cross-ecosystem impact of the eMudhra CA compromise.