핵심 POINT
Oracle과 OpenJDK는 한 인증기관의 중간 인증서 개인키 8개가 손상된 문제에 대응해 자바(Java) 긴급 보안 업데이트를 내놓았습니다. 위험도는 CVSS 9.1(심각)이며 자바 8, 11, 17, 21, 25, 27 계열이 모두 영향 범위에 들어갑니다.
마이크로소프트가 윈도우와 엣지의 신뢰 목록을 고쳤더라도 벤더 사이트에서 내려받아 설치한 자바는 자체 인증서 저장소를 씁니다. OpenJDK 프로젝트는 업데이트한 지 며칠 안 된 런타임도 다시 확인하라고 안내했습니다.
설치된 자바 버전, 프로그램에 포함된 자바, 벤더 릴리스 노트의 수정 문구, 공식 점검 도구 실행의 4가지로 확인할 수 있습니다. 업데이트가 어렵다면 인증서 삭제나 폐기 여부 확인 같은 임시 조치도 공식 안내에 있습니다.
윈도우 패치했는데 자바는 그대로? 자바(Java) 긴급 업데이트, 내 JDK 확인 방법 4가지
Oracle은 2026년 10월 21일 자바 SE와 GraalVM에 대한 보안 경보(CVE-2026-91403)를 발표했습니다. 같은 날 OpenJDK 취약점 그룹도 같은 취약점을 공지하고 가능한 한 빨리 업그레이드하라고 권고했으며, KISA는 10월 23일 영향 버전 사용자에게 업데이트를 권고했습니다. 10월 24일에는 Oracle과 OpenJDK가 관련 루트 인증서를 제거하는 후속 경보(CVE-2026-114820)를 추가로 냈습니다. 마이크로소프트는 10월 20일 윈도우의 신뢰하지 않는 인증서 목록을 먼저 갱신했고, 10월 26일에는 윈도우 대역 외 업데이트로 관련 인증서 7개를 신뢰 목록에서 제거했습니다.
이 일련의 조치는 모두 같은 사건에서 비롯됐습니다. 한 인증기관이 운영하는 중간 인증서 8개의 개인키가 복구될 수 있는 상태였고, 이 키로 만든 인증서는 브라우저와 운영체제에 정상 인증서처럼 보일 수 있기 때문입니다. 마이크로소프트는 이 문제가 자사 시스템의 침해가 아니라 해당 인증기관의 인증서 체계에서 발생했다고 밝혔습니다. 이번 공지에서는 실제 악용 사례가 언급되지 않았습니다.
이 글에서는 자바 업데이트가 왜 윈도우 업데이트와 별도로 필요한지, 내 PC와 서버의 자바를 확인하는 방법 4가지, 업데이트 적용과 임시 조치 방법, 윈도우 업데이트가 닫혀 있는 환경의 점검 사항을 차례로 살펴봅니다.
■ 인증기관 개인키 손상, 위조 인증서가 정상으로 인식될 수 있는 문제
출처: AI(ChatGPT) 생성 이미지
인증서는 접속하려는 서버나 내려받은 프로그램이 믿을 만한지 알려 주는 신분증과 같습니다. 인증기관이 이 신분증을 발급하고, 브라우저와 운영체제, 자바 같은 실행 환경은 믿을 수 있는 인증기관 목록을 미리 갖고 있다가 이 목록에 있는 기관이 서명한 인증서를 정상으로 받아들입니다.
마이크로소프트 MSRC가 10월 26일 공개한 글에 따르면 이번에 문제가 된 중간 인증기관 개인키는 8개이고, 이 중 6개는 웹사이트 통신(TLS)용, 2개는 코드 서명용입니다. TLS용 키로는 웹사이트나 서비스를 사칭해 통신을 가로챌 가능성이 있고, 코드 서명용 키로는 악성코드가 믿을 수 있는 게시자에게서 나온 것처럼 꾸밀 수 있다고 설명했습니다.
Oracle의 두 차례 경보는 이 문제를 다루는 순서를 보여 줍니다. 10월 21일 첫 경보는 영향을 받는 중간 인증서를 신뢰하지 않도록 하는 자바 업데이트를 내놓았고, 10월 24일 후속 경보(CVE-2026-114820)는 관련 루트 인증서까지 제거하는 업데이트를 내놓았습니다. 두 경보 모두 CVSS 9.1이고, 인증 없이 네트워크로 악용될 수 있는 조건이 위험도에 반영됐습니다.
| 날짜 | 발표 주체 | 조치 내용 |
|---|---|---|
| 10월 20일 | 마이크로소프트 | 윈도우의 신뢰하지 않는 인증서 목록 갱신, 엣지와 WebView2에 폐기 목록 배포 |
| 10월 21일 | Oracle, OpenJDK | 자바 보안 경보(CVE-2026-91403), 영향 중간 인증서 신뢰 해제 |
| 10월 23일 | KISA | Oracle 제품 보안 업데이트 권고 게시 |
| 10월 24일 | Oracle, OpenJDK | 후속 경보(CVE-2026-114820), 관련 루트 인증서 제거 업데이트 |
| 10월 26~27일 | 마이크로소프트 | 윈도우 대역 외 업데이트(KB5134133)와 엣지 신뢰 목록에서 인증서 7개 제거 |
[표] 인증서 신뢰 철회 관련 주요 일정 (Oracle 보안 경보, OpenJDK 공지, KISA 보호나라, 마이크로소프트 MSRC)
■ 윈도우를 업데이트해도 자바는 따로 확인해야 하는 이유
마이크로소프트의 조치는 윈도우와 엣지, WebView2의 신뢰 목록을 대상으로 합니다. 반면 OpenJDK 프로젝트의 안내 문서는 벤더 사이트에서 내려받은 독립 실행형 자바 런타임이라면 런타임 안에 있는 인증서 저장소(cacerts 파일)를 직접 정리해야 한다고 설명합니다. 운영체제의 인증서 목록을 고쳐도 이 파일은 그대로 남아 있을 수 있다는 뜻입니다.
OpenJDK 안내 문서는 설치 방식에 따라 대응이 달라진다고 정리했습니다.
• 벤더 사이트에서 내려받은 독립 실행형 런타임은 업데이트된 런타임을 설치하거나, 업데이트가 아직 없으면 인증서를 직접 삭제하거나, 폐기 여부 확인 옵션을 켜야 합니다.
• 운영체제 패키지로 설치한 런타임은 대부분 운영체제의 인증서를 사용합니다. 문서는 Arch Linux, Fedora, Gentoo, Oracle Linux, Red Hat Enterprise Linux에서는 운영체제 인증서를 갱신하면 대체로 충분하다고 설명합니다.
• 데비안 계열(우분투 포함)은 인증서 패키지를 갱신해도 충분하지 않아 별도 작업이 필요하고, FreeBSD와 Homebrew 패키지는 운영체제 인증서를 쓰지 않으므로 패키지 업데이트를 기다려야 합니다.
업무 환경에서는 자바가 눈에 띄지 않게 숨어 있는 경우가 많습니다. 서버의 웹 애플리케이션 서버뿐 아니라, 자바를 내장한 설치형 업무 프로그램과 서명된 JAR 파일을 쓰는 서비스도 같은 영향 범위에 들 수 있습니다. 시스템에 설치된 자바 하나만 확인하고 끝내면 놓치기 쉽습니다.
■ 자바 버전과 인증서 상태 확인 방법 4가지
출처: AI(ChatGPT) 생성 이미지
아래 순서대로 개발 서버나 시험 환경에서 먼저 확인한 뒤 운영 환경으로 넓혀 가면 좋습니다.
❶ 설치된 자바 버전 확인
• 명령 프롬프트나 터미널에서 java -version 명령을 실행하면 현재 경로에 잡힌 자바 버전이 나옵니다.
• 10월 23일 KISA 권고는 첫 경보(CVE-2026-91403) 기준으로, 영향 버전을 Java SE 8u511 이하, 11.0.33 이하, 17.0.21 이하, 21.0.13 이하, 25.0.5 이하, 27.0.1 이하, OpenJDK 8u504 이하, 11.0.32.1 이하, 17.0.21 이하, 21.0.13 이하, 25.0.5 이하, 27.0.1 이하로 안내했습니다.
• 버전 숫자만으로 판단하지 않는 것이 안전합니다. 10월 24일 후속 경보에서는 Oracle이 8u511-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2, 27.0.1.0.2를, OpenJDK가 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2 이하를 영향 버전으로 올렸습니다. 첫 경보 직후 나온 긴급 빌드도 다시 업데이트 대상이라는 뜻입니다.
❷ 프로그램에 포함된 자바 찾기
• 명령 프롬프트에서 where java(리눅스는 which -a java)를 실행하면 경로에 잡힌 자바 위치가 나옵니다.
• 설치형 업무 프로그램, 웹 애플리케이션 서버, 빌드 도구, 컨테이너 이미지는 자체 자바를 포함하는 경우가 있어 이 명령으로는 보이지 않습니다. 각 제품의 설치 폴더에서 jre나 jdk 폴더가 있는지 확인하고, 제품 벤더에 자바 업데이트 계획을 문의해야 합니다.
❸ 벤더 릴리스 노트에서 수정 문구 확인
• OpenJDK 안내 문서는 업데이트된 런타임의 릴리스 노트에 JDK-8395690, CVE-2026-114820을 수정했다는 내용이 있는지 보라고 안내합니다.
• 사용 중인 자바 배포판이 Oracle이든 다른 OpenJDK 빌드든, 해당 벤더의 릴리스 노트에서 이 번호를 확인하는 것이 가장 확실한 기준입니다.
❹ 공식 점검 도구로 인증서 상태 확인
• OpenJDK 프로젝트는 CheckCerts.java 프로그램을 실행해 런타임이 위험한 상태인지 확인하라고 안내합니다. 이 프로그램은 JDK 8 이후 버전에서 동작합니다.
• 설치된 자바가 여러 개라면 각 설치본마다 따로 실행해야 합니다.
■ 자바 업데이트 적용 방법
출처: AI(ChatGPT) 생성 이미지
OpenJDK 안내 문서가 권하는 방법은 업데이트된 런타임을 설치하는 것입니다. 이미 최근에 업데이트했더라도 후속 수정이 포함됐는지 확인하는 것이 좋다는 설명이 함께 있습니다.
• 사용 중인 배포판 벤더의 최신 릴리스를 내려받아 설치합니다. OpenJDK는 10월 20일 정기 보안 공지에서도 여러 취약점 수정을 함께 내놓았으므로, 최신 릴리스를 받으면 정기 수정도 같이 반영됩니다. KISA 권고는 Oracle 제품은 Oracle 보안 패치를, OpenJDK는 벤더 보안 업데이트를 적용하라고 안내합니다.
• 자바를 실행 중인 서비스는 업데이트 후 다시 시작해야 새 인증서 저장소가 반영됩니다. OpenJDK 문서도 실행 중인 런타임 인스턴스를 재시작하라고 안내합니다.
• 컨테이너로 배포하는 서비스는 기본 이미지를 새 자바 버전으로 다시 빌드해 배포해야 운영 환경에 반영됩니다.
• 적용한 뒤에는 앞의 확인 방법 4가지를 다시 실행해 결과가 바뀌었는지 점검합니다.
■ 업데이트가 어려울 때의 임시 조치
벤더가 아직 업데이트를 내놓지 않았거나 서비스 사정으로 바로 적용하기 어렵다면 OpenJDK 안내 문서의 두 가지 임시 조치를 검토할 수 있습니다.
❶ 관련 루트 인증서 삭제
• 먼저 런타임의 인증서 저장소를 백업합니다. JDK 11 이상은 $JDK_HOME/lib/security/cacerts, JDK 8은 $JDK_HOME/jre/lib/security/cacerts 파일입니다.
• 삭제할 인증서의 이름은 OpenJDK 안내 문서(openjdk.org/emudhra)에 명령어와 함께 나와 있으므로, 별칭을 임의로 추측하지 말고 해당 문서의 목록을 그대로 따라야 합니다.
• 작업 후에는 실행 중인 자바 프로세스를 재시작해야 하고, 자바가 여러 개 설치돼 있다면 설치본마다 반복합니다.
❷ 인증서 폐기 여부 확인 켜기
• TLS를 쓰는 애플리케이션이라면 실행 명령에 아래 두 옵션을 추가하는 방법이 안내돼 있습니다.
-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=true
• 서명된 JAR 파일은 JDK 17 이상에서 아래 명령으로 서명과 폐기 여부를 함께 검증할 수 있습니다.
jarsigner -verify -revcheck -strict 서명된.jar
• 두 방법 모두 업데이트를 대신하는 영구 해법이 아니라 임시 조치입니다. 업데이트가 가능해지는 즉시 적용해야 합니다.
■ 윈도우 업데이트가 닫힌 환경의 인증서 점검
마이크로소프트의 10월 26일 대역 외 업데이트(KB5134133)는 인터넷이 차단된 환경의 디바이스, 마이크로소프트 인증서 업데이트 서비스에 접근할 수 없는 디바이스, 자동 인증서 신뢰 목록 업데이트를 꺼 둔 디바이스를 위한 것입니다. 일반적인 자동 업데이트 환경은 신뢰 목록이 자동으로 갱신됩니다.
• 폐쇄망이나 업데이트 승인 절차가 따로 있는 서버는 갱신된 신뢰하지 않는 인증서 목록과 신뢰 목록 변경이 실제로 배포됐는지 확인합니다.
• 마이크로소프트는 제거되는 7개 인증서에 연결된 자사 인증서가 있다면 변경이 적용되기 전에 대체 인증서나 다른 신뢰 체인을 마련하라고 안내했습니다.
• 호환성 때문에 제거된 인증서를 로컬에서 다시 신뢰하도록 설정하는 경우에는 위험을 충분히 평가해야 한다는 설명도 있습니다. 폐기 여부를 제대로 확인하지 않는 소프트웨어에서는 문제가 있는 인증서가 정상으로 받아들여질 수 있기 때문입니다.
SK쉴더스는 취약점 진단과 보안 컨설팅, 관제 서비스를 통해 기업의 서버와 업무 프로그램에서 자바를 비롯한 실행 환경의 보안 업데이트 현황을 점검하도록 지원하고 있습니다.
■ 자주 묻는 질문
Q. 윈도우 업데이트를 했는데도 자바를 따로 해야 하나요?
A. 벤더 사이트에서 내려받아 설치한 독립 실행형 자바는 런타임 안의 인증서 저장소를 쓰므로 별도 확인이 필요합니다. OpenJDK 안내 문서는 이런 런타임에 업데이트 설치나 인증서 삭제 같은 조치를 하라고 설명합니다.
Q. 이미 공격에 쓰이고 있나요?
A. Oracle과 OpenJDK, KISA, 마이크로소프트의 이번 공지에는 실제 악용 사례가 언급되지 않았습니다. 다만 개인키가 복구될 수 있는 상태였고 CVSS 9.1로 평가된 만큼 업데이트가 권고됩니다.
Q. 내 자바가 업데이트됐는지 어떻게 알 수 있나요?
A. 사용 중인 배포판의 릴리스 노트에서 JDK-8395690, CVE-2026-114820 수정 내용이 있는지 확인합니다. 첫 경보 직후 나온 빌드는 후속 경보의 영향 버전에 들어 있어 버전 번호만으로는 판단하기 어렵습니다. OpenJDK의 CheckCerts.java 프로그램으로 런타임 상태를 점검하는 방법도 있습니다.
Q. 자바를 직접 설치한 적이 없는데 확인해야 하나요?
A. 설치형 업무 프로그램이나 웹 애플리케이션 서버, 빌드 도구는 자바를 내장하는 경우가 있습니다. 이런 경우는 제품 벤더가 제공하는 업데이트를 따로 확인해야 합니다.
Q. 업데이트하기 전에 할 수 있는 조치가 있나요?
A. OpenJDK 안내 문서에는 관련 루트 인증서를 직접 삭제하는 방법과 폐기 여부 확인 옵션을 켜는 방법이 임시 조치로 소개돼 있습니다. 어느 쪽이든 업데이트를 대신하지는 못합니다.
[콘텐츠 출처]
Oracle, Security Alert Advisory CVE-2026-91403 (2026.10.21)
Oracle, Security Alert Advisory CVE-2026-114820 (2026.10.24)
OpenJDK, Vulnerability Advisory 2026/10/21
OpenJDK, Vulnerability Advisory 2026/10/24
OpenJDK, Compromised Certificates and OpenJDK Java Runtimes (2026.10.24 갱신)
KISA 보호나라, Oracle 제품 보안 업데이트 권고 (2026.10.23)
Microsoft MSRC, 손상된 인증기관 키에 대한 Microsoft의 대응 (2026.10.26, 10.27 갱신)



