오라클 치명적 수준 취약점 긴급 패치... “신뢰 깨진 인증서가 백엔드 노린다”

코드 버그 아닌 ‘CA 개인키 유출’ 여파, 자바 기본 TLS 검증 메커니즘 무력화
CVSS 9.1점 원격 무인증 취약점으로 외부 API 호출 과정서 중간자 공격(MitM) 성립
상용 솔루션·컨테이너 내부 숨은 JRE 전수 색출하고 데이터 접근 무결성 역추적해야

전 세계 엔터프라이즈 백엔드와 금융·공공 기간망의 핵심 언어인 오라클 자바(Java) 환경에서 인증 절차나 사용자 개입 없이 네트워크를 통해 원격에서 악용될 수 있는 치명적 보안 결함이 확인됐다.

암호화 통신의 신뢰 체계를 무너뜨릴 수 있다는 우려다. 이 취약점은 '공통 취약점 점수 시스템'(CVSS) v3.1 기준 9.1점을 기록했다. 

오라클은 정기 패치 주기를 기다리지 않고 비정기 긴급 보안 경보를 내고 '자바 보안 소켓 확장'(JSSE) 구성요소의 고위험 취약점 CVE-2026-91403을 해결한 보안 업데이트를 배포했다.

인도 CA '이무드라' 중간 인증서 8개 개인키 노출... 1바이트 난수 생성 결함이 화근

오라클 공식 보안 권고문에 따르면 CVE-2026-91403 패치의 핵심은 글로벌 인증기관(CA)인 이무드라(eMudhra)와 연관된 중간 CA 인증서 세트의 신뢰를 강제로 해제하는 것이다. 보안 분석 기업 SOC프라임 등의 초기 보고서에는 오라클의 세부 기술 비공개 정책 탓에 구체적 공격 원리가 모호하게 서술됐으나, 실제 원인은 자바 내부 코드 메모리 오류가 아닌 외부 인증기관 개인키 유출에 따른 자바 신뢰 저장소 마비에 있던 것으로 드러났다.

외부 위협 인텔리전스 및 오픈JDK 보안 그룹의 기술 분석을 종합하면, 이무드라가 발급한 중간 CA 인증서 8개(웹사이트 TLS 인증용 6개, 코드 서명용 2개·교차 서명 포함 총 16개 인증서 객체)의 개인키가 취약한 난수 생성 메커니즘으로 인해 외부에 노출됐다. 

개인키는 거대한 무작위 난수로 생성돼야 하지만, 문제의 키들은 마지막 1바이트를 제외한 모든 바이트가 '0'으로 채워져 있어 누구나 공개된 인증서에서 역산해 개인키를 복구할 수 있는 상태였다.

중간 CA의 개인키를 손에 넣은 공격자는 어떤 도메인 이름으로든 정상 서명된 '전송 계층 보안'(TLS) 웹사이트 인증서를 임의로 위조해 찍어낼 수 있다. 악성코드에 정상 기업 명의의 디지털 코드 서명을 입혀 보안 검사를 우회하는 것도 가능하다.

▲오라클(Oracle)이 공지한 JSSE 취약점 정보 [출처: 오라클]

브라우저는 3시간 만에 막았는데... 자바 'JSSE'가 무방비로 뚫린 2가지 이유

17일 개인키 복구 증명을 전달받은 구글 크롬과 모질라 파이어폭스 등 주요 웹브라우저는 'CRLite'와 'OneCRL' 등 자체 실시간 차단 목록을 가동해 3시간 만에 이들 인증서를 차단했다. 이무드라도 18-19일 문제의 중간 인증서들을 'CA 침해' 사유로 전면 폐기했다.

문제는 기업 서버에서 돌아가는 자바 런타임의 독특한 보안 구조다. 자바 기본 TLS 통신 엔진인 JSSE는 웹브라우저의 실시간 차단 목록이나 운영체제(OS)의 루트 인증서 업데이트를 공유하지 않고, 자바 설치 경로 내부에 자체 내장된 신뢰 저장소 파일('cacerts' 또는 'jssecacerts')만 독립적으로 참조한다. 리눅스 등 OS의 인증서 패키지를 최신으로 업데이트해도 자바 애플리케이션은 유출된 인증서를 계속 정상으로 신뢰한다.

자바는 기본 설정상 인증서 폐기 여부를 실시간 확인하는 옵션이 비활성화돼 있다는 점도 문제다. 인증기관이 인증서를 폐기해도 기본 설정의 자바 서버는 이를 인지하지 못한 채 공격자가 위조한 인증서와 정상적으로 TLS 핸드셰이크를 맺는다.

이 때문에 자바 기반 백엔드 서버나 미들웨어, 웹 서비스가 외부 응용프로그램 인터페이스(API)와 HTTPS로 통신할 때 공격자가 네트워크 경로에서 위조 인증서를 제시하면 완벽한 '중간자 공격'(MitM)이 성립한다. 

서버가 중단되는 가용성 피해가 전혀 나타나지 않기 때문에 관리자가 이상 징후를 눈치채지 못하는 사이 기밀 데이터와 인증 토큰이 탈취되거나 응답 데이터가 은밀히 조작 또는 삭제될 수 있다. 자바 샌드박스에 의존해 외부 코드를 실행하는 '자바 웹 스타트'(Java Web Start)나 애플릿 환경에서는 위조된 코드 서명을 통한 악성코드 실행 위험에도 노출된다.

상용 SW·컨테이너 내장 JDK 전수 조사해야... 즉시 패치 어렵다면 수동 차단

이번 취약점의 영향을 받는 오라클 공식 지원 버전은 △Oracle Java SE(8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1) △Oracle GraalVM for JDK(17.0.21, 21.0.13) △Oracle GraalVM Enterprise Edition(21.3.20)이다. 오라클 기술 지원이 종료된 구버전 자바나 오픈JDK, 리베리카(Liberica) JDK 등 다른 배포판 역시 같 루트 인증서를 내장하고 있어 영향권에 포함된다.

기업 보안팀은 사내 인프라에 설치된 자바 런타임 인벤토리를 파악해야 한다. 단독 서버뿐 아니라 상용 소프트웨어, 미들웨어, 도커(Docker) 컨테이너 이미지, 서드파티 보안 장비 내부에 번들로 숨어 있는 개별 JDK·JRE 디렉터리를 찾아내 오라클 긴급 패치를 적용해야 한다. 이번 패치는 자바 내부 'blocked.certs' 파일에 침해당한 이무드라 중간 인증서 지문(Fingerprint) 16개를 등록해 연결을 원천 거부한다.

즉각적 자바 버전 업그레이드가 어려운 상황이라면 수동 완화 조치를 취해야 한다. 자바 'keytool' 명령어를 사용해 신뢰 저장소('cacerts')에서 이무드라와 연결된 상위 루트 인증서 별칭('emsigneccrootcag3 [jdk]', 'comodoaaaca [jdk]')을 직접 삭제하거나 'blocked.certs' 목록에 문제의 인증서 지문을 수동 추가하면 된다.

관제 조직은 자바 프로세스의 비정상적 아웃바운드 연결, 예기치 않은 TLS·JSSE 핸드셰이크 오류, 정당한 비즈니스 활동 없는 애플리케이션 데이터 변경 및 의심스러운 프로세스 생성 로그를 역추적해 침해 여부를 점검해야 한다.