CVE-2026-111943: eMudhra 인증 기관 사고 이후 절취된 eMudhra CA 키 차단

주요 공개 키 인프라 사고로 인해 브라우저, 프로그래밍 언어 생태계, 인증서 저장소 및 소프트웨어 패키지 전반에서 긴급 보안 조치가 촉발되었습니다. 여덟 개의 eMudhra 중간 인증 기관 인증서와 관련된 개인 키가 손상되어 승인되지 않은 당사자가 취약한 클라이언트에게 신뢰 가능한 것으로 보일 수 있는 인증서를 만들 수 있는 가능성이 있습니다.

이 사건은 도메인 검증, 조직 검증, 확장 검증 인증서에 사용되는 여섯 개의 TLS 중간 인증서와 두 개의 코드 서명 중간 인증서에 영향을 미칩니다. 중간 CA가 신뢰할 수 있는 루트 아래에서 인증서를 발행할 수 있기 때문에 개인 키 소유는 일반 웹사이트 인증서 손상과는 상당히 다른 위험을 만듭니다. 공격자는 영향을 받은 체인의 신뢰를 상속받는 위조 인증서를 만들 수 있습니다.

Go 프로젝트는 영향을 받은 중간 인증서가 포함된 인증서 체인을 계속 신뢰할 수 있는 사례를 해결하기 위해 CVE-2026-111943을 도입하여 대응했습니다. Go 1.26.10과 1.27.3는 crypto/x509에 거부 목록을 추가하여 알려진 신뢰할 수 없는 중간 키가 체인에 나타날 때 인증서 검증을 실패하도록 합니다.

CVE-2026-111943 탐지 기회를 찾는 보안 팀은 기존의 취약점 악용 텔레메트리를 넘어선 관찰이 필요합니다. 이 사건은 인증서 신뢰와 관련된 문제이므로 방어자는 TLS 인증서 체인, 예상치 못한 인증서 발급자, 인증서 유효성 검사 실패, 의심스러운 암호화 세션, 브라우저 철회 메커니즘 대신 자체 인증서 번들을 유지하는 소프트웨어를 모니터링해야 합니다.

SOC Prime의 AI-Native 탐지 인텔리전스 플랫폼은 다양한 SIEM, EDR 및 데이터 레이크 기술을 통해 지속적으로 업데이트되는 탐지 콘텐츠를 활용하여 보안 팀이 새로운 위협에 대한 가시성을 강화할 수 있게 합니다. 클릭 탐지 살펴보기 신규 공격 동작에 대한 관련 탐지 콘텐츠와 헌팅 논리를 확인하려면.

보안 전문가는 Prime Architect를 사용하여 새로운 위협 인텔리전스와 지표를 헌팅 쿼리와 탐지 논리로 변환함으로써 CVE-2026-111943 관련 노출을 감지하고 환경 내에서 의심스러운 인증서 활동을 조사할 수 있습니다.

영업 문의

CVE-2026-111943 분석

이 사건은 2026년 10월 17일, 한 보안 연구자가 emSign 인증 기관 인프라 하에서 eMudhra가 운영하는 여덟 개의 중간 인증서를 포함하는 암호학적 약점을 발견하면서 시작되었습니다. 연구자는 모든 여덟 개 인증서의 유효한 서명된 인증서를 브라우저 루트 프로그램과 eMudhra에 제출함으로써 관련 개인 키의 소유 권한을 입증했습니다.

Mozila는 그 후 이 손상을 확인하고, 특히 연구자의 방법에 대한 세부 정보를 받지 않고도 자사의 엔지니어들이 개별적으로 영향을 받은 개인 키를 복구할 수 있음을 보고했습니다. Mozilla는 기본 키 생성 프로세스가 결함이 있고 악용하기 쉬웠다고 결론지었습니다.

영향을 받은 인증 기관에는 다음이 포함됩니다:

• EM DV TLS CA – G3B
• EM DV TLS CA – G3C
• EM OV TLS CA – G3B
• EM OV TLS CA – G3C
• EM EV TLS CA – G3B
• EM EV TLS CA – G3C
• EM OV CS CA – G3B
• EM OV CS CA – G3C

첫 여섯 개는 웹사이트 인증을 위해 사용되는 인증서 체인에 참여할 수 있는 TLS 중간 인증서입니다. 나머지 두 개는 코드 서명 중간 인증서입니다. G3B 인증서는 네덜란드의 eMudhra BV와 관련이 있고, G3C 인증서는 미국의 eMudhra Inc.와 관련이 있습니다.

보안 영향을 상당합니다. 중간 CA 개인 키를 유도하거나 얻을 수 있는 사람은 해당 중간 인증서를 통해 인증서를 발급하는데 합법적인 인증 기관 발급 절차를 거치지 않고도 발급할 수 있습니다. TLS 맥락에서, 공격자는 피해자의 연결을 가로채거나 리디렉션할 수 있다면 도메인을 가장하는 데 사용할 수 있는 위조 인증서를 사용할 수 있습니다.

Mozilla는 해당 공격자가 연결을 가로챌 위치에 있을 때 웹사이트를 가장하고 트래픽을 읽거나 수정할 수 있음을 주목했습니다. 이는 해당 문제가 중간자 공격 시나리오, 손상된 네트워크 인프라, 악성 프록시, 또는 DNS 및 라우팅 조작과 특히 관련이 있습니다.

하지만 제공된 증거는 방어적 대응 이전의 위조 TLS 인증서의 광범위한 악용을 입증하지 않습니다. The Hacker News에 의해 인용된 Chrome Root Program 발견에 따르면, 여섯 개의 영향을 받은 웹사이트 중간 인증서로 연결된 TLS 인증서는 Chrome이 키를 차단하기 전에 인증서 투명성 로그에 나타나지 않았습니다. Chrome과 다른 브라우저가 CT 로깅을 요구했던 이유로 인해 기록되지 않은 공개적으로 신뢰받는 인증서를 거부할 것이기 때문에, 이를 통해 해당 클라이언트를 통한 공공 TLS 악용 가능성이 상당히 제한되었습니다.

Chrome은 10월 17일 18:05 UTC에 보고서를 받았으며 19:45 UTC까지 여섯 개의 TLS 중간 인증서에 대한 CRLSet 블록을 배포했습니다. Mozilla는 그날 저녁에 보고서를 받았고 22:59 UTC까지 표준 Firefox 설정에 OneCRL 블록을 배포했습니다. Firefox 사용자는 Remote Settings를 수신하여 수동 업데이트나 브라우저 재시작 없이 보호를 받았습니다.

CVE-2026-111943 PoC 상황은 이는 통상적인 메모리 손상 또는 원격 코드 실행 취약점 악용 코드가 아닌 독특한 상황입니다. 대신, 연구자는 모든 여덟 개 개인 키에 대한 제어의 암호학적 증명을 제공했고, Mozilla는 독립적으로 키 복구를 재현하여 암호학적 실패가 악용될 수 있음을 효과적으로 시연했습니다.

CVE 자체는 Go 프로젝트에 의해 할당되었습니다. 이는 Go 표준 라이브러리에서 인증서 검증에 관련된 더 좁은 문제를 설명합니다. 대부분의 플랫폼에서는 Go가 시스템 루트 인증서 저장소에 의존합니다. 그러나 해당 신뢰 구성 업데이트가 지연된 시스템에서는 신뢰할 수 없는 중개자를 통해 체인을 계속 수락할 수 있습니다.

이 gap을 해소하기 위해 Go 프로젝트는 crypto/x509에 명시적인 거부 목록을 추가했습니다. 업데이트된 검증 로직은 손상된 중개자 공개 키가 포함되어 있을 때마다 인증서 체인 검증 실패를 반환합니다.

CVE-2026-111943은 Go 표준 라이브러리 버전 1.26.10 이전과 Go 1.27 브랜치 1.27.3 버전 이전에 영향을 미칩니다. 영향을 받은 버전을 사용하여 빌드된 애플리케이션은 새로운 보호를 받기 위해 수정된 Go 릴리즈를 사용하여 재구축이 필요할 수 있습니다.

CVE-2026-111943에 대한 세부 사항은 애플리케이션 소유자에게 특히 중요합니다. 브라우저 수정은 TLS 검증을 수행하는 모든 프로그램을 자동으로 보호하지 않습니다. 많은 애플리케이션이 언어별 또는 임베디드 인증서 저장소를 사용하고, Chrome CRLSet이나 Mozilla OneCRL과 같은 브라우저 해지 시스템을 사용하지 않을 수 있습니다.

The Hacker News는 이러한 구별이 여러 생태계에 걸쳐 업데이트를 촉발했다고 보고합니다. Go는 명시적인 차단을 추가했고 Mozilla는 NSS를 업데이트했으며, Python의 certifi 인증서 번들은 영향을 받은 루트를 제거했으며, Rust의 webpki-roots 생태계는 업데이트를 배포했습니다. RustSec는 웹 PKI 루트 패키지에 대해 패치된 버전 1.0.10 이상을 별도로 식별합니다.

따라서 CVE-2026-111943 IOCs는 IP 주소, 도메인 또는 파일 해시와 같은 전통적인 악성코드 지표보다 주로 인증서 지향적입니다. 조직은 영향을 받은 여덟 개의 중양 인증서 정체성과 해당 키를 명시적으로 차단하는 데 사용되는 공개 키 해시를 중심으로 집중해야 합니다. 이러한 중간 인증서가 포함된 인증서 체인은 신뢰할 수 없는 것으로 취급하고 조사해야 합니다.

CVE-2026-111943 완화

Go 환경에 대한 가장 중요한 수정은 Go 1.26.10, Go 1.27.3 또는 이후 지원되는 릴리즈로 업데이트하고 Go의 TLS 인증서 검증에 의존하는 애플리케이션을 새로 빌드하는 것입니다. 개발 서버에서 Go 도구 체인을 단순히 업그레이드한다고 해도 이미 컴파일된 바이너리에는 소급적으로 변화가 적용되지 않습니다. 영향을 받은 애플리케이션은 수정된 표준 라이브러리로 재구축하고 재배포해야 합니다.

조직은 또한 독립적인 CA 저장소 또는 인증서 번들을 유지하는 애플리케이션을 재고해야 합니다. Chrome과 Firefox와 같은 브라우저는 중앙 집중식 해지 메커니즘을 통해 신속하게 반응했지만, 명령 줄 유틸리티, 서버 애플리케이션, 컨테이너, 에이전트, 임베디드 장치 및 언어 실행 환경은 다른 인증서 소스에 의존할 수 있습니다.

표준 구성을 가진 Firefox 사용자는 10월 17일 자동으로 OneCRL 블록을 받았습니다. Mozilla는 추가로 Remote Settings가 정상적으로 작동하지 않는 정책이나 네트워크 환경을 가진 사용자에게 업데이트된 블록 목록을 제공하기 위해 Firefox 158.0.1, Firefox ESR 115.43.1 및 Firefox ESR 153.5.1을 출시했습니다. 또한 Mozilla는 신뢰할 수 있는 인증서 집합에 대한 변경 사항을 포함하는 NSS 3.131.1을 배포했습니다.

보안 팀은 다음을 수행해야 합니다:

• Go 애플리케이션을 업데이트하고 영향을 받은 바이너리를 재구성하십시오.
• 시스템 CA 번들과 언어별 신뢰 저장소를 업데이트하십시오.
• 브라우저 및 운영 체제의 인증서 해지 메커니즘이 작동하는지 확인하십시오.
• 손상된 여덟 개 중간 인증서 키를 차단하거나 신뢰를 철회하십시오.
• 내부에 임베디드 또는 정적으로 패키징된 인증서 저장소가 있는 애플리케이션 식별.
• 영향을 받은 중간 인증서가 포함된 인증서 체인에 대한 TLS 텔레메트리를 검사하십시오.
• 신뢰를 잃은 인증서 체인에 의존하는 기존 서비스가 있다면 정당한 인증서를 다시 발행합니다.
• 루트 저장소 업데이트 후 중요한 서비스를 테스트하십시오. CA 루트를 제거하면 이전에 이를 통해 체인된 정당한 서비스가 중단될 수 있습니다.

팀은 또한 장기적으로 사용하는 소프트웨어 어플라이언스, 컨테이너, 내부 개발자 도구, 지원되지 않는 소프트웨어에 주의를 기울여야 합니다. 이러한 시스템은 주류 브라우저가 손상된 CA를 차단한 후에도 오랜 기간 동안 오래된 인증서 번들을 신뢰할 수 있습니다.

루트 인증서를 제거하면 운영 측면에 영향을 미칠 수 있습니다. 해당 루트를 통해 체인된 합법적인 인증서도 개별 인증서가 손상되지 않았더라도 유효성을 잃을 수 있습니다. 따라서 조직은 신뢰 스토어 제거가 가용성에 영향을 미치지 않는다고 가정하기보다는 신속한 신뢰 철회와 종속성 발견 및 인증서 교체를 결합해야 합니다.

SOC 팀은 인증서 검증 실패, TLS 가로채기 텔레메트리, 비정상적인 DNS 활동, 예상치 못한 프록시 동작, 인증서 발급자 변경을 결합하여 방어 태세를 강화할 수 있습니다. 공격자는 일반적으로 위조된 TLS 인증서가 유용해지기 전에 트래픽을 지정하거나 가로채는 메커니즘이 필요하므로 인증서 이상 현상은 네트워크 수준의 증거와 함께 조사되어야 합니다.