Oracle Java 2026년 10월 취약점, 정기 패치 다음 날 긴급 수정까지

Oracle 이 2026년 10월 20일(미국 시간) 정기 패치(CPU, Critical Patch Update)로 Java SE 취약점 55건을 고쳤고, 일본 IPA 는 다음 날 서둘러 적용하라는 주의 환기를 냈다. 그런데 하루 뒤 따로 나온 CVE-2026-91403(CVSS 9.1)은 그 10월 업데이트판까지 영향 범위에 넣는다. 그러니 10월 업데이트에서 멈추지 말고 그 뒤 나온 재배포판으로 한 번 더 올리거나 OS 인증서를 갱신해야 한다. 고친 판이 아예 없는 26 계열은 다른 계열로 옮겨야 한다.

01 IPA 가 꼽은 대상은 8개 판이고, 고친 판은 계열마다 하나다

IPA(일본 정보처리추진기구)는 2026년 10월 21일 「Oracle Java 취약점 대책(2026년 10월)」을 올렸다. Oracle 이 일본 시간 21일에 보안 업데이트를 냈고, 악용되면 애플리케이션이 비정상 종료되거나 공격자가 PC 를 장악할 수 있으니 서둘러 적용하라는 내용이다. 대책은 Oracle 이 내놓은 최신판으로 올리는 것 하나다. 끝에는 라이선스 안내가 붙는다. 2019년 4월 16일 이후 릴리스부터 라이선스가 바뀌었으니, 상용으로 쓰는 조직은 조건을 확인하고 필요하면 Oracle 에 직접 문의하라는 것이다.

대상은 지원 중인 Oracle 제품 8개 판이다. 아래 표는 버전 문자열을 JEP 322 형식에 맞춰 풀어 썼다. 이 형식은 계열.중간.업데이트.패치 순서이고 끝자리 0은 적지 않는다. 그래서 "업데이트 12 패치 1" 은 셋째 자리가 12, 넷째 자리가 1인 판이다. Java 8 만 옛 표기인 8u 뒤 번호를 쓴다.

표의 대상보다 오래된 판도 물론 영향을 받는다. 같은 날 나온 OpenJDK 권고도 영향 버전 목록 끝에 "그 이전 판 전부" 를 붙였다. 26 계열은 후속 계열이 9월에 정식 출시되면서 업데이트가 끊겼고, OpenJDK 의 10월 위험 표에도 26 열이 없다. 26 을 쓰는 곳은 고칠 판이 없으니 27 이나 장기 지원(LTS) 계열로 옮기는 수밖에 없다.

02 55건 가운데 서버에 닿는 쪽은 네트워크와 보안 라이브러리다

Oracle 의 10월 CPU 는 전 제품에 걸쳐 1,295개 패치를 담았다. Tenable 집계로 고유 CVE 는 1,209개다. 이 가운데 Java SE 몫이 55건이고, 그중 49건은 인증 없이 네트워크로 공격할 수 있다. 가장 높은 점수는 CVSS 7.5 두 건이고 치명 등급은 없다. 하나는 네트워크로 인증 없이 닿는 JavaFX 항목, 다른 하나는 로컬 접근을 전제로 하는 Java 플러그인 항목이다.

OpenJDK 도 같은 날 권고를 내고 OpenJDK 47건, OpenJFX 6건을 공개했다. 7월 권고는 둘을 합쳐 18건이었으니, 한 분기 만에 세 배 가까이 늘어난 셈이다. OpenJDK 쪽 최고점은 2D 그래픽 라이브러리의 CVE-2026-91415(CVSS 7.0)이고, 이 항목은 지원 중인 모든 계열에 걸린다.

구성 요소별로 세어 보면 보안 라이브러리(java.security·JGSS·javax.net.ssl·javax.security)가 12건, 네트워크(java.net)가 10건이다. HTTP 통신·TLS·인증 처리처럼 서버 애플리케이션이 늘 쓰는 영역이라, GUI 를 쓰지 않는 서버도 업데이트를 미룰 이유가 없다. Oracle 의 55건과 OpenJDK 의 53건은 세는 범위가 다르다. Java 플러그인처럼 Oracle JDK 에만 있는 구성 요소가 Oracle 쪽 숫자에 들어간다.

이번 55건에 실제 악용 표시는 없다(2026년 10월 22일 일본 보도 기준). 대신 Oracle 은 패치를 늦게 적용한 고객이 공격받았다는 보고가 계속 들어온다고 경고한다.

03 왜 10월 업데이트를 적용해도 끝나지 않나

10월 업데이트판이 믿는 루트 인증서 아래에, 개인키를 누구나 계산할 수 있는 중간 인증서 8개가 걸려 있어서다. Mozilla 버그 트래커의 분석을 보면 인증 기관 eMudhra 가 2025년 4월 키 생성 의식(key ceremony)에서 만든 P-384 키가 제대로 무작위가 아니었다. 8개 모두 개인키 값이 256보다 작아, 공개 인증서만 보고도 곧바로 풀렸다. 6개는 TLS용이고 2개는 코드 서명용이다.

처리는 빨랐다. 2026년 10월 17일 제보가 주요 루트 프로그램에 들어갔고, Mozilla 는 그날 안에 Firefox 에서 이 인증서들의 신뢰를 끊었다. eMudhra 는 이튿날(UTC) 8개를 모두 CA 침해(caCompromise) 사유로 폐기했다. Sectigo 가 일부를 교차 서명해 둔 탓에 그 교차 인증서도 함께 폐기됐다.

Java 쪽 문제는 신뢰 저장소에 있다. 개인키를 손에 넣은 사람은 이 중간 인증서 이름으로 아무 도메인의 인증서나 서명할 수 있다. 런타임에 묶인 신뢰 저장소(cacerts)가 그 위의 루트(emSign ECC Root CA - G3, Sectigo 의 AAA Certificate Services)를 믿는 한, Java 로 짠 HTTPS 클라이언트는 위조 인증서도 정상으로 받아들인다. 실제로 OpenJDK 27 업데이트 1 빌드로 문제 체인을 쓰는 시험 서버에 붙어 본 외부 검증 글에서는 기본 설정 그대로 접속이 성공했다.

Oracle 은 10월 21일(미국 시간) 정기 일정 밖의 보안 알림으로 이 문제에 CVE-2026-91403 을 붙였다. 구성 요소는 JSSE(Java Secure Socket Extension, Java 의 TLS 구현)이고 CVSS 3.1 점수는 9.1이다. 네트워크로 인증이나 사용자 동작 없이 노릴 수 있고, 기밀성과 무결성 영향이 모두 높음이다. Oracle 이 밝힌 영향 대상은 다음과 같다.

• Oracle Java SE 8u511, 8u511-perf
• Oracle Java SE 11·17·21·25·27 계열의 10월 업데이트판
• Oracle GraalVM for JDK 17·21 계열의 10월 업데이트판
• Oracle GraalVM Enterprise Edition 21.3 계열

OpenJDK 도 같은 날 같은 CVE 로 권고를 냈다. 지원 중인 여섯 계열의 10월 판과 그 이전 판이 모두 대상이고, 번호 체계가 다른 OpenJDK 8 은 8u512 이하로 적혀 있다. 고친 판은 업데이트 번호 뒤에 .0.2 가 붙은 재배포판이다.

jdk.java.net 의 27 계열 페이지는 10월 22일 현재 업데이트 1 의 .0.2 판을 정식 빌드로 걸었다. 25 계열 소스 저장소에도 버전 날짜를 10월 22일로 바꾼 .0.2 커밋이 올라왔다. 일본 보도는 Oracle JDK 도 11부터 27까지 같은 꼴의 판이 나왔다고 전한다(10월 22일 오전 기준). Java 8 재배포판 표기는 출처마다 달라, Oracle 알림 페이지에서 직접 확인하는 편이 안전하다.

04 업데이트가 늦으면 설치 형태에 맞춰 인증서부터 막는다

할 일은 런타임이 어느 인증서 저장소를 쓰느냐로 갈린다. OpenJDK 권고를 표로 옮기면 이렇다.

먼저 지금 도는 런타임을 확인한다. 컨테이너라면 이미지 안에서 실행한다.

# 계열·업데이트 번호·배포처 확인
java -version
# 런타임에 묶인 신뢰 저장소(cacerts) 목록
keytool -list -cacerts

당장 올릴 수 없을 때 권고가 드는 임시 조치는 두 가지이고, 설치본마다 따로 해 줘야 한다. 첫째는 차단 목록 교체다. 권고 페이지에서 OS 에 맞는 blocked.certs 를 받아 $JDK_HOME/lib/security/blocked.certs 와 바꾼다. 이 파일에 직접 넣어 둔 항목이 있으면 백업한 뒤 새 파일에 다시 넣고, JDK 8 은 같은 자리에 blacklisted.certs 라는 이름으로 둔다.

둘째는 인증서 폐기 확인을 켜는 것이다. TLS 를 쓰는 애플리케이션은 실행 옵션 두 개를 더한다.

java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -jar app.jar

JDK 17 이상에서 서명된 JAR 를 검증할 때는 jarsigner 에 폐기 확인을 붙인다.

jarsigner -verify -revcheck -strict app.jar

폐기 확인은 인증서에 적힌 배포 지점에서 CRL(인증서 폐기 목록)을 받아 오는 방식이라, 그 주소로 나가는 통신이 열려 있어야 한다. 앞의 외부 검증 글에서도 옵션을 켜자 문제 체인이 CertificateRevokedException(사유 CA_COMPROMISE)으로 거부됐다. 어디까지나 재배포판을 깔기 전까지 버티는 수단이다.

05 Oracle JDK 21 은 이번 업데이트부터 상용 운영에 구독이 필요하다

IPA 의 라이선스 안내는 이번 달 JDK 21 사용자에게 특히 걸린다. Oracle 은 JDK 21 업데이트를 무상 조건인 NFTC(No-Fee Terms and Conditions)로 2026년 9월까지 내겠다고 했고, 그 뒤 업데이트에는 OTN 라이선스를 붙인다. OTN 은 개인·개발 용도에는 무상이지만, 상용 운영에는 Java SE 구독이 있어야 한다. 일본 보도는 이번 10월 판을 OTN 이 붙는 첫 JDK 21 업데이트로 짚었다.

구독을 이어 가지 않을 생각이라면 같은 OpenJDK 수정이 들어간 다른 배포판(Eclipse Temurin, Azul 등)으로 옮기는 길이 있다. 다만 배포판 빌드는 공개 시점이 저마다 다르다. 예컨대 Temurin 25 계열의 10월 업데이트는 10월 22일 GitHub 에 올라왔다. 배포판마다 cacerts 를 따로 꾸리므로, 옮길 곳의 CVE-2026-91403 대응 공지도 함께 본다.

06 우리 상황에 적용: 런타임 목록을 만들고 두 번 올린다

Java 를 쓰는 서비스라면 이번 달은 업데이트를 두 번 하는 셈이다. Spring Boot 서버처럼 외부 API 를 HTTPS 로 부르는 애플리케이션은 CVE-2026-91403 이 노리는 TLS 클라이언트 자리에 그대로 선다. 서버 프로세스뿐 아니라 컨테이너 베이스 이미지와 CI 빌드 에이전트에 든 JDK 까지 목록에 넣고, 아래 순서로 처리한다.

1. 런타임마다 java -version 으로 계열·업데이트 번호·배포처를 적는다.
2. 26 계열은 27 이나 LTS 인 25 로 옮긴다.
3. 10월 업데이트에 이어 .0.2 재배포판을 깔고, 배포판 패키지라면 OS 인증서도 갱신한다.
4. 컨테이너는 베이스 이미지를 새로 받아 다시 빌드한다.
5. 바로 못 올리는 곳은 blocked.certs 교체나 폐기 확인 옵션으로 막아 둔다.
6. Oracle JDK 21 을 상용으로 쓰면 라이선스부터 확인한다.

25 를 기준 LTS 로 잡는 이유는 JDK 28 AOT 코드 컴파일과 값 객체, Spring 서버에서 달라지는 범위에서 다뤘다. 앞으로 일정도 촘촘해진다. Oracle 은 분기 CPU 사이에 월간 보안 업데이트를 끼워 넣고 있어서, 다음 Java 보안 업데이트는 2026년 11월 17일이다. 다음 정기 CPU 는 2027년 1월 19일로 잡혀 있다(2026년 10월 보도 기준).

07 자주 묻는 질문

OS 인증서만 갱신하면 10월 정기 수정도 끝나나?

아니오. 인증서 갱신은 CVE-2026-91403 만 막는다. 정기 수정은 런타임 코드에 들어간 것이라, 배포판이 내는 OpenJDK 패키지 업데이트를 따로 받아야 한다.

폐기 확인 옵션을 켜 두면 업데이트를 미뤄도 되나?

아니오. OpenJDK 권고는 업데이트할 수 없을 때의 임시 조치로만 이 옵션을 든다. CRL 을 받아 올 바깥 통신이 열려 있어야 한다는 조건도 붙는다.