오라클 자바 긴급 경고(CVE-2026-91403)의 정체: 인증기관 개인키가 "4"였다, eMudhra 사태와 10월 오라클 CPU 1,295건 정리

CVE-2026-91403은 오라클이 2026년 10월 21일 정기 패치 일정 밖에서 긴급 발표한 자바(Java SE·GraalVM) 보안 경고다. 원인은 자바 코드의 버그가 아니다. 인도의 인증기관 eMudhra가 발급한 중간 인증서 8개의 개인키가 사실상 공개된 상태로 드러났고, 자바가 이 인증서들을 더 이상 믿지 않도록 바꾼 것이다.

그 개인키 중 하나는 말 그대로 숫자 4였다. 같은 주 오라클은 분기 정기 패치(CPU)로 1,295건을 한꺼번에 내놨다. 둘 다 "오라클 보안 이슈"로 묶여 기사가 쏟아졌지만 성격이 완전히 다르다. 하나씩 풀어 보고, 내 서버에서 직접 확인한 결과도 같이 적는다.

3줄 요약

eMudhra 중간 인증서 8개의 개인키가 4, 56, 115 같은 아주 작은 숫자였다. 이 키가 있으면 아무 도메인의 HTTPS 인증서나 위조할 수 있다. 실제 악용은 아직 확인되지 않았다.
브라우저는 10월 17~20일 사이에 대부분 자동으로 막았다. 문제는 자바, 파이썬, Go 바이너리, 도커 이미지처럼 자기만의 인증서 목록을 들고 다니는 소프트웨어다.
10월 20일 CPU로 자바를 올렸어도 다음 날 나온 긴급 경고 업데이트를 한 번 더 받아야 한다. 경고 대상 버전이 바로 CPU 최신 버전이기 때문이다.

9.1

CVE-2026-91403 CVSS 3.1 점수

8개

개인키가 노출된 eMudhra 중간 인증서

6천만+

eMudhra가 발급했다고 밝힌 인증서 수

1,295

10월 오라클 CPU 신규 보안 패치

PART 01일주일 동안 무슨 일이 있었나

사건의 뿌리는 1년 반 전이다. Endor Labs와 여러 분석에 따르면 문제의 중간 인증서 8개는 2025년 4월에 만들어졌고, 처음부터 공개 인증서만 보고도 개인키를 알아낼 수 있는 상태였다. 그게 2026년 10월 셋째 주에 한꺼번에 터졌다. 시간은 발표 기준 UTC다.

2025년 4월

문제의 중간 인증서 8개 생성

eMudhra가 중간 인증서를 만들면서 약한 개인키가 함께 쓰였다. 이 시기 인증서 투명성(CT) 로그에는 이 인증서들로 발급된 기록이 없다고 Endor Labs는 밝혔다.

10월 17일 20:06

Mozilla에 제보 접수, 3시간 만에 차단

제보를 받은 Mozilla는 OneCRL(원격 차단 목록)로 해당 인증서를 막았고, 22시 59분에 배포를 마쳤다. 사용자 업데이트나 재시작이 필요 없는 방식이다. 크롬도 같은 날 차단했다.

10월 19일

애플 차단, eMudhra 인증서 폐기

애플이 차단했고, eMudhra는 8개 인증서를 모두 폐기(revoke)했다. Go는 1.27.3과 1.26.10을 냈다.

10월 20일

마이크로소프트 차단, 오라클 정기 CPU

Firefox 158.0.1과 NSS 3.131.1이 나왔다. NSS는 이 인증서들에 서명한 루트 인증서를 신뢰 목록에서 뺐다. 같은 날 오라클은 분기 정기 패치(CPU)로 1,295건을 공개했다.

10월 21일

오라클 자바 긴급 경고 CVE-2026-91403

오라클이 정기 일정 밖에서 Security Alert를 냈다. 내용은 한 줄이다. "eMudhra 관련 중간 CA 인증서들을 신뢰하지 않도록 하는 자바 업데이트를 제공한다."

PART 02개인키가 "4"라는 게 무슨 뜻인가

HTTPS 인증서 체계에서 인증기관(CA)의 개인키는 사실상 인터넷 신뢰의 열쇠다. 이번에 쓰인 타원곡선 암호(P-384)에서 개인키는 그냥 하나의 큰 숫자다. 정상이라면 384비트짜리, 십진수로 100자리가 넘는 무작위 수여야 한다. 그래야 공개키를 보고 거꾸로 개인키를 찾는 게 불가능하다.

그런데 The Register 보도에 따르면 보안 연구자 Scott Helme가 확인한 키 하나는 4였다. 다른 키도 56, 115였고, 연구자들은 66, 155, 156, 230, 237까지 찾아냈다. 8개 모두 255보다 작은 수다. Helme는 공개 인증서에서 56과 115를 알아내는 데 1초도 안 걸렸다고 했다. 비유하자면 은행 금고 비밀번호가 "4"였던 셈이다.

The Register, The CyberSec Guru 보도 기준
항목	정상적인 CA 키	이번 eMudhra 중간 인증서 키
키 종류	P-384 타원곡선 개인키	같음
키 크기	약 2³⁸⁴ 범위의 무작위 수	4, 56, 66, 115, 155, 156, 230, 237
공개키로 역산	현실적으로 불가능	1초 이내 (Scott Helme)
가능해지는 일	없음	어떤 도메인이든 신뢰받는 HTTPS 인증서 위조

어쩌다 이렇게 됐을까. eMudhra는 HSM(하드웨어 보안 모듈)이 뚫린 게 아니라 키 생성 의식 중 키를 감싸고 푸는(wrap/unwrap) 절차에서 문제가 생겼다고 설명했다. 원래 강한 키와 별개로 약한 키 쌍이 만들어졌고, 하필 그 약한 쪽이 브라우저 신뢰 목록에 올라갔다는 것이다. 일부 보도는 2025년 5월 인증서 폐기 목록(CRL) 서명이 실패하자 서명 키를 약한 키로 바꿔 문제를 "해결"한 정황도 전했다. 다만 이 부분은 회사의 공식 근본 원인 분석이 아직 나오지 않은 상태다.

영삼

영삼의 한마디

이번 사건에서 제일 무서운 건 해커가 아니다. 1년 반 동안 아무도 몰랐다는 점이다. 인증서는 공개 정보라 누구든 열어 볼 수 있었다. 그런데 "설마 CA 키가 작은 숫자겠어"라는 전제 때문에 아무도 안 봤다. 보안은 결국 확인한 것만 믿을 수 있다는 걸 다시 배운다.

PART 03왜 위험한가, 그리고 왜 브라우저만으론 끝나지 않나

Cloudflare는 이 키로 "어떤 도메인이든 위조 인증서를 만들어 서버를 사칭하고 트래픽을 가로채거나 바꿀 수 있다"고 설명했다. 내 은행 사이트, 사내 API, 업데이트 서버 무엇이든 가짜 인증서가 진짜처럼 통과할 수 있다는 얘기다. 물론 공격자가 통신 중간에 끼어들 수 있어야 한다. 공용 와이파이, 해킹된 공유기, 악성 프록시 같은 위치다.

다행히 아직 실제 악용 사례는 보고되지 않았다. eMudhra는 8개 중간 인증서로 최종 인증서가 발급된 적이 없다고 밝혔다. 그런데 이 말이 안심으로 이어지지 않는 이유가 있다. 키를 아는 사람은 이제 누구나 새 인증서를 찍어낼 수 있기 때문이다.

폐기(revoke)만으로는 안 막히는 이유

eMudhra가 인증서를 폐기했지만, Endor Labs 지적대로 브라우저가 아닌 대부분의 TLS 프로그램은 폐기 여부를 확인하지 않는다. 자바 서버가 외부 API를 부를 때, 파이썬 스크립트가 requests로 접속할 때, Go로 만든 CLI가 업데이트를 받을 때 모두 마찬가지다. 결국 각 프로그램이 쓰는 신뢰 저장소에서 문제의 인증서를 빼는 것만이 확실한 방법이다.

PART 04오라클 자바 긴급 경고 CVE-2026-91403 해부

여기서 오라클이 등장한다. 오라클 JDK는 OS의 인증서 목록이 아니라 자기 안에 들어 있는 cacerts 파일을 쓴다. 그래서 OS가 업데이트돼도 오라클 자바는 여전히 eMudhra를 믿는다. 오라클이 정기 일정을 기다리지 않고 긴급 경고를 낸 이유다.

오라클 Security Alert 원문, Rapid7·SOC Prime 정리 기준
항목	내용
CVE	CVE-2026-91403
구성 요소	JSSE (자바의 TLS/SSL 처리 모듈)
CVSS 3.1	9.1 (네트워크, 인증 불필요, 사용자 동작 불필요, 기밀성·무결성 High)
영향 제품	Oracle Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1 GraalVM for JDK 17.0.21, 21.0.13 / GraalVM Enterprise 21.3.20
조치	eMudhra 관련 중간 CA 인증서를 신뢰하지 않도록 한 자바 업데이트 적용
발표일	2026년 10월 21일 (Rev 1)
실제 악용	10월 22일 기준 CISA KEV 미등재, 공개 공격 코드 없음

표에서 눈여겨볼 건 영향 버전이다. 21.0.13, 17.0.21 같은 숫자는 바로 전날 10월 CPU로 나온 최신 버전이다. 오라클의 10월 CPU 자바 위험 표를 보면 직전 버전(21.0.12.1 등)이 영향 대상으로 적혀 있다. 즉 10월 20일에 부지런히 자바를 올린 사람도 21일 경고 업데이트를 한 번 더 받아야 한다. 또 오라클은 지원 기간(Premier·Extended Support) 안의 버전에만 패치를 주고, 그 밖의 버전은 시험하지 않았지만 영향받을 가능성이 높다고 적었다.

OpenJDK는 사정이 조금 다르다. 우분투·데비안의 OpenJDK는 보통 OS 인증서 목록에서 자바용 저장소(/etc/ssl/certs/java/cacerts)를 만들어 쓴다. 그러니 OS 패키지만 올리면 될 것 같지만, 실제로는 그렇지 않은 경우가 있다. 바로 내 서버가 그랬다.

현장 기록

OS는 고쳐졌는데 자바는 그대로였다

오늘 아침 내 서버(우분투 26.04)부터 확인했다. 먼저 OS 인증서 목록. ca-certificates 패키지는 10월 21일 새벽 6시 13분에 자동 보안 업데이트로 20260816ubuntu0.26.04.1이 설치돼 있었다. Endor Labs가 정리한 수정 버전과 같다. grep -c emSign 결과도 0. 여기까진 깔끔했다.

다음은 자바. 이 서버엔 OpenJDK 21이 깔려 있다. keytool로 자바 신뢰 저장소를 열어 보니 emSign 루트 인증서 4개가 그대로 있었다. 파일 수정 시각은 8월 19일. OS 목록은 바뀌었는데 자바용 저장소는 다시 만들어지지 않은 것이다.

다행히 이 서버에는 지금 상시 돌아가는 자바 서비스가 없다. 당장 위험한 상황은 아니었다는 뜻이다. 하지만 자바 서버를 운영하는 곳이었다면 "OS 패치 다 했다"고 보고하고 끝냈을 상황이다. 이게 이번 사건의 핵심 함정이다.

PART 05내 서버 점검 명령어

1) OS 인증서 목록

# 패키지 버전 확인 (수정 버전: 우분투 20260816ubuntu0.*, 데비안 20250419~deb12u2 등)
dpkg -l ca-certificates | tail -1

# eMudhra(emSign) 항목이 0이어야 한다
grep -c "emSign" /etc/ssl/certs/ca-certificates.crt

# 아직이라면
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates

2) 자바 신뢰 저장소

# 지금 쓰는 자바의 cacerts에서 emSign 찾기 (0이어야 한다)
keytool -list -cacerts -storepass changeit | grep -ci emsign

# 우분투·데비안 OpenJDK: OS 목록 기준으로 자바 저장소를 다시 맞춘다
sudo update-ca-certificates --fresh
sudo dpkg --triggers-only -a      # 위 명령이 걸어 둔 자바 저장소 갱신 작업을 바로 실행
keytool -list -cacerts -storepass changeit | grep -ci emsign

# 오라클 JDK·GraalVM: JDK 자체를 Security Alert 업데이트 버전으로 교체
java -version

update-ca-certificates --fresh는 OS 인증서 링크를 새로 만들고, 자바 저장소 갱신(ca-certificates-java)을 dpkg 작업으로 예약만 해 둔다. 그래서 dpkg --triggers-only -a로 그 작업을 바로 실행해야 OS 목록에 없는 인증서(이번엔 emSign)가 자바 저장소에서도 빠진다. 끝난 뒤 자바 애플리케이션은 재시작해야 새 목록을 읽는다. 오라클 JDK는 JDK 안의 lib/security/cacerts를 쓰므로 이 명령으로는 안 바뀐다.

3) 실제로 막히는지 시험

사건을 정리한 공개 사이트가 문제의 중간 인증서로 서명한 시험용 주소를 열어 두었다. 접속이 실패해야 정상이다.

# 인증서 오류가 나야 안전한 상태
curl -sS https://dv-g3b-emudhra.we-have-a-problem.com/ -o /dev/null && echo "위험: 아직 신뢰함" || echo "안전: 거부됨"

4) 런타임별로 따로 챙길 것

버전은 Endor Labs 10월 21일 정리 기준, 이후 바뀔 수 있다
런타임·도구	신뢰 저장소	수정 버전 (Endor Labs 정리)
우분투 / 데비안	OS 패키지	`ca-certificates` 20260816ubuntu0.* / 20250419~deb12u2 등
오라클 JDK / GraalVM	JDK 내장 cacerts	오라클 CVE-2026-91403 Security Alert 업데이트
파이썬 (requests 등)	`certifi`	certifi 2026.10.19 이상, pip 26.2.2
Node.js	바이너리 내장	22.23.4 / 24.22.1 / 26.12.1
Go	바이너리에 섞여 들어감	1.27.3 / 1.26.10 으로 다시 빌드
Electron 앱	바이너리 내장	44.9.1 / 43.8.1 / 42.11.16
Rust (rustls)	`webpki-roots`	1.0.10
PHP Composer	`composer/ca-bundle`	1.4.16 / 1.6.0
도커 이미지	이미지 안 OS 패키지	수정된 베이스 이미지로 다시 빌드

Endor Labs의 한 문장이 이번 사건을 정확히 요약한다. "오늘 패치한 호스트가 지난달 만든 이미지를 고쳐 주지 않는다." 도커 이미지와 Go로 빌드한 실행 파일은 만들 당시의 인증서 목록을 그대로 품고 있다.

PART 06같은 주의 또 다른 오라클 이슈: 10월 CPU 1,295건

오라클은 분기마다 셋째 화요일 즈음 정기 보안 패치(CPU)를 낸다. 10월 20일 CPU는 새 보안 패치 1,295건이다. 오라클 공식 문서의 제품군별 수치를 추려 보면 이렇다.

오라클 Critical Patch Update Advisory - October 2026 원문 기준
제품군	신규 패치	인증 없이 원격 공격 가능
Fusion Middleware	206	134
E-Business Suite	194	31
Database 제품군 (Essbase·REST Data Services 등 포함)	126	제품별 상이
Siebel CRM	122	66
Communications	110	77
PeopleSoft	109	41
JD Edwards	102	44
MySQL	98	29
Java SE	55	49

숫자보다 중요한 건 몇 개의 고위험 항목이다.

모두 인증 없이 원격 공격 가능 (오라클 위험 매트릭스)
CVE	제품 / 구성 요소	CVSS	영향 버전
CVE-2026-101809	E-Business Suite Workflow / Notification Mailer	10.0	12.2.3 ~ 12.2.15
CVE-2026-101767	E-Business Suite Application Object Library / Core	9.8	12.2.3 ~ 12.2.15
CVE-2026-75803	Oracle Database RDBMS (OpenSSL) / TLS	9.8	19.3~19.32, 23.4.0~23.26.3

EBS 두 건은 인증 없이 HTTP로 공격할 수 있다. Horizon3.ai는 CVE-2026-101767을 Thin Client Framework 서블릿의 SQL 인젝션으로 분석했고, 원격 코드 실행으로 이어질 수 있다고 봤다. 현재까지 실제 악용 보고는 없다. 하지만 EBS는 전력이 있다. 2025년 랜섬웨어 조직 Cl0p 관련 세력이 EBS 취약점(CVE-2025-61882)을 제로데이로 악용했고, CISA는 2026년 7월에도 다른 EBS 취약점을 악용 목록에 올렸다. EBS를 쓰는 조직이라면 이번 CPU는 미루지 않는 게 맞다.

EBS 패치가 바로 어렵다면

Rescana가 정리한 권고는 EBS 웹 계층을 인터넷에서 떼고 신뢰하는 내부망에서만 HTTP(S) 접근을 허용하는 것이다. Horizon3.ai는 패치 전까지 EBS URL 방화벽 허용 목록에서 /OA_HTML/AppsTCFServer를 빼라고 권했다. 오라클이 공식 우회책을 낸 것은 아니므로 어디까지나 시간 벌기다. DR·테스트·복제 환경도 네트워크로 닿는다면 같이 패치 대상이다.

다음 오라클 보안 업데이트 일정도 적어 둔다. 11월 17일과 12월 15일에는 CSPU(월간 보안 패치)가, 2027년 1월 19일에는 다음 분기 CPU가 나온다.

영삼

영삼의 생각

두 사건을 나란히 놓고 보니 공통점이 보인다. 1,295건짜리 정기 패치도, 인증서 8개짜리 긴급 경고도 결국 "내 시스템에 무엇이 들어 있는지 아는가"를 묻는다. 나는 이번 일 이후로 신뢰 저장소를 라이브러리처럼 관리하기로 했다. 어떤 프로그램이 어떤 인증서 목록을 쓰는지, 그 목록이 언제 마지막으로 바뀌었는지 서버마다 적어 두는 것이다. 오늘 아침 자바 저장소가 8월 그대로였던 걸 본 뒤로는 이게 과한 일이라는 생각이 안 든다.

점검 체크리스트

OS ca-certificates가 수정 버전이고 grep -c emSign이 0인가
서버의 모든 자바(오라클 JDK, OpenJDK, 앱에 묶인 JRE) 신뢰 저장소에서 emSign이 빠졌는가
오라클 JDK·GraalVM은 10월 21일 Security Alert 업데이트까지 적용했는가
파이썬 certifi, Node.js, Go 바이너리, Electron 앱을 수정 버전으로 올리거나 다시 빌드했는가
도커 이미지를 수정된 베이스로 다시 빌드·배포했는가
EBS·Database·Fusion Middleware 등 오라클 제품에 10월 CPU를 적용했는가

정리하면

CVE-2026-91403은 자바 버그가 아니라 eMudhra 중간 인증서 8개의 개인키 노출에 대한 대응이다.
브라우저는 대부분 자동으로 막혔다. 위험은 자기만의 인증서 목록을 쓰는 서버 쪽 소프트웨어에 남아 있다.
OS 패치와 자바 저장소는 따로 확인하자. OS가 고쳐져도 자바 cacerts는 그대로일 수 있다.
10월 20일 CPU를 받았어도 오라클 자바는 21일 업데이트를 또 받아야 한다.
EBS 10.0·9.8 취약점은 인증 없이 원격 공격이 가능하다. 패치 전까지 웹 계층을 외부에서 떼어 두자.

자주 묻는 질문

CVE-2026-91403은 무엇인가요?

CVE-2026-91403은 오라클이 2026년 10월 21일 발표한 Java SE·GraalVM 긴급 보안 경고입니다. 인도 인증기관 eMudhra의 중간 인증서 8개 개인키가 노출된 사건에 대응해, 자바가 해당 인증서들을 신뢰하지 않도록 바꾼 업데이트입니다. CVSS 3.1 점수는 9.1입니다.

eMudhra 인증서 사태는 일반 사용자에게도 위험한가요?

크롬, 파이어폭스, 사파리, 엣지 등 주요 브라우저는 10월 17일부터 20일 사이에 문제의 인증서를 자동으로 차단했습니다. 브라우저를 최신으로 유지하고 있다면 추가로 할 일은 거의 없습니다. 위험이 남은 곳은 자체 인증서 목록을 쓰는 서버용 프로그램입니다.

OpenJDK를 쓰는데 오라클 패치가 필요한가요?

오라클 패치 자체보다 신뢰 저장소 확인이 중요합니다. 우분투·데비안의 OpenJDK는 OS 인증서 목록에서 만든 자바 저장소를 쓰므로, ca-certificates를 업데이트한 뒤 update-ca-certificates --fresh와 dpkg --triggers-only -a로 자바 저장소를 다시 맞추고 keytool로 emSign 항목이 사라졌는지 확인하세요.

10월 20일 오라클 CPU를 이미 적용했는데 또 업데이트해야 하나요?

오라클 자바를 쓴다면 그렇습니다. CVE-2026-91403 경고의 영향 버전이 Java SE 21.0.13, 17.0.21 등 10월 CPU로 나온 최신 버전이기 때문입니다. 21일 공개된 Security Alert 패치를 추가로 적용해야 합니다.

인증서가 이미 폐기됐는데 왜 따로 조치해야 하나요?

브라우저가 아닌 대부분의 TLS 프로그램은 인증서 폐기 여부를 확인하지 않습니다. 또 개인키가 알려진 이상 누구나 새 위조 인증서를 만들 수 있습니다. 그래서 각 프로그램이 쓰는 신뢰 저장소에서 문제의 인증서를 빼는 것이 확실한 방법입니다.

2026년 10월 오라클 CPU에서 가장 위험한 취약점은 무엇인가요?

E-Business Suite Workflow Notification Mailer의 CVE-2026-101809가 CVSS 10.0으로 가장 높습니다. 같은 EBS의 CVE-2026-101767(9.8)과 Oracle Database의 OpenSSL 관련 CVE-2026-75803(9.8)도 인증 없이 원격 공격이 가능해 우선 패치 대상입니다.