Oracle Java 긴급 보안 업데이트 - HTTPS인데도 데이터를 도둑맞을 수 있다고?
Java 인증서 신뢰 취약점 CVE-2026-91403 이해하기
HTTPS 주소에 접속하면 통신이 암호화되니 안전하다고 생각하기 쉽다. 하지만 암호화만큼 중요한 조건이 하나 더 있다. 지금 통신하는 상대가 진짜 서버인지 확인하는 것이다.
이번에 공개된 Java 보안 이슈는 바로 이 신뢰 과정과 관련된다.
Oracle은 2026년 10월 21일, Java SE와 GraalVM에 영향을 주는 CVE-2026-91403에 대한 긴급 보안 업데이트를 발표했다. 공식 위험도는 CVSS 3.1 기준 9.1점으로 치명적(Critical)이다. Oracle 공식 공지
1. 어떤 문제인가?
핵심은 Java 프로그램이 공격자가 제시한 인증서를 신뢰하고, 악성 서버와 통신할 수 있다는 것이다.
Java에는 HTTPS 같은 보안 통신을 처리하는 JSSE(Java Secure Socket Extension)라는 구성요소가 있다. 이번 취약점은 이 구성요소와 관련된 인증서 신뢰 문제다. Oracle 공식 공지
이해하려면 먼저 HTTPS가 상대방을 확인하는 방식을 알아야 한다.
2. HTTPS는 어떻게 진짜 서버를 구분할까?
인증서는 서버의 신분증이다
사용자가 은행 사이트에 접속한다고 가정하자.
암호화된 연결을 만들기 전에 브라우저나 프로그램은 상대방이 정말 해당 은행 서버인지 확인해야 한다. 이때 서버가 제시하는 것이 디지털 인증서다.
인증서는 서버의 신분증에 비유할 수 있다. 하지만 신분증에 이름이 적혀 있다고 무조건 믿을 수는 없다. 누가 발급했고, 그 발급기관을 신뢰할 수 있는지도 확인해야 한다.
이 역할을 맡는 곳이 인증기관(CA, Certificate Authority)이다.
인증서는 신뢰의 사슬로 연결된다
일반적인 인증서 구조는 다음과 같다.
루트 인증기관이 중간 인증기관을 보증하고, 중간 인증기관이 서버 인증서를 보증하는 구조다. 이를 인증서 체인이라고 한다.
이번 사건을 이해할 때 중요한 부분은 가운데에 있는 중간 인증기관이다.
3. eMudhra와 관련해 무엇이 잘못됐을까?
Red Hat의 기술 설명에 따르면, 이번 문제에는 eMudhra가 발급한 취약한 개인키를 가진 중간 인증기관 인증서가 관련돼 있다.
공격자가 이를 악용하면 임의의 서버 이름에 대한 인증서를 만들 수 있고, 영향을 받는 Java 프로그램은 그 인증서를 신뢰할 수 있다. Red Hat 기술 설명
개인키는 인증기관이 인증서에 서명할 때 사용하는 중요한 비밀 정보다. 신분증 비유로 돌아가면 발급기관의 공식 도장을 다른 사람이 악용할 수 있는 상황에 가깝다.
서버 인증서만 그럴듯하게 꾸미는 문제가 아니다.
그 인증서를 보증하는 기관의 신뢰를 악용한다는 점이 핵심이다.
이에 대한 대응은 문제가 된 중간 인증기관 인증서를 더 이상 신뢰하지 않도록 차단하는 것이다. Red Hat은 OpenJDK 측 수정이 해당 중간 인증서를 차단하는 방식이라고 설명한다. Red Hat 대응 설명
4. 실제 공격은 어떤 흐름으로 일어날까?
Java로 만든 프로그램이 외부 API에 연결하는 상황을 생각해보자.
정상적인 경우에는 API 서버의 인증서를 확인한 뒤 암호화된 통신을 시작한다. 하지만 공격자가 연결을 가로채거나 악성 서버로 유도하고, 프로그램이 신뢰하는 위조 인증서를 제시할 수 있다면 문제가 생긴다.
위 그림은 공격 원리를 단순화한 것이다. 실제 공격에는 공격자가 통신 경로에 개입하는 등의 조건이 필요하다. 취약한 Java를 사용한다는 사실만으로 모든 통신이 즉시 탈취되는 것은 아니다. Red Hat 기술 설명
암호화됐는데 왜 위험할까?
암호화는 통신 내용을 아무나 읽지 못하게 보호한다. 하지만 암호화된 연결의 상대방이 공격자라면 공격자는 자신에게 전달된 내용을 읽을 수 있다.
택배 상자를 단단히 잠갔더라도, 받는 사람이 사기꾼이고 그 사람이 열쇠를 가지고 있다면 내용물을 보호할 수 없는 것과 비슷하다.
그래서 HTTPS에는 다음 두 가지가 모두 필요하다.
- 기밀성: 통신 내용을 제3자가 읽지 못해야 한다.
- 상대방 확인: 통신하는 서버가 의도한 서버인지 검증해야 한다.
이번 문제는 그중 상대방을 신뢰하는 과정을 흔든다.
5. 어떤 피해가 가능할까?
Oracle은 이번 취약점의 영향을 다음과 같이 평가했다.
| 항목 | 공식 | 평가의미 |
| 기밀성 | 높음 | 민감한 데이터가 노출될 수 있다. |
| 무결성 | 높음 | 데이터가 허가 없이 변경될 수 있다. |
| 가용성 | 영향 없음 | 해당 평가에서 서비스 중단 영향은 부여되지 않았다. |
또한 공격 복잡도는 낮고, 공격에 별도 권한이나 사용자 상호작용이 필요하지 않은 것으로 평가됐다. Oracle 위험도 평가
여기서 사용자 상호작용이 필요 없다는 말은 피해자가 반드시 링크를 클릭하거나 파일을 실행해야 하는 유형이 아니라는 뜻이다. 서버 프로그램이 자동으로 외부 시스템과 통신하는 환경도 확인 대상이 된다.
다만 9.1점이라는 점수 자체가 현재 대규모 공격이 발생했다는 증거는 아니다. 위험도 점수와 실제 악용 현황은 구분해서 읽어야 한다.
6. Node.js 취약점과 같은 사건인가?
앞서 알려진 Node.js Brotli 취약점과는 별개다.
| 구분 | Node.js Brotli 취약점 | 이번 Java 취약점 |
| CVE | CVE-2026-111497 | CVE-2026-91403 |
| 문제 지점 | 압축 해제 과정 | 인증서 신뢰 과정 |
| 핵심 위험 | 메모리 손상과 원격 코드 실행 가능 | 위조 서버 신뢰와 데이터 탈취·변조 |
| 주요 대응 | 수정된 Node.js 배포 | 공급업체의 Java·인증서 보안 업데이트 적용 |
다만 연결되는 부분은 있다. Node.js의 10월 21일 보안 릴리스에도 eMudhra 중간 인증기관 문제에 대응하는 인증서 업데이트가 포함됐다. Brotli 수정과 인증서 업데이트가 같은 릴리스에 들어간 것이다. Node.js 공식 보안 공지
따라서 다음처럼 구분하면 이해하기 쉽다.
Brotli 문제는 압축 해제 결함이다.
eMudhra 문제는 여러 실행 환경에 영향을 줄 수 있는 인증서 신뢰 문제다.
7. 개발자와 운영자는 무엇을 해야 할까?
① 실행 중인 Java와 공급업체를 확인한다
다음 명령으로 Java 정보를 확인할 수 있다.
java -version개발자 PC뿐 아니라 운영 서버, 컨테이너, 배치 작업이 실제로 사용하는 Java를 확인해야 한다.
Java는 Oracle JDK 외에도 여러 배포판이 있으므로, 버전 번호와 함께 공급업체도 확인하는 것이 좋다.
② 해당 공급업체의 보안 업데이트를 적용한다
Oracle JDK나 GraalVM을 사용한다면 Oracle의 패치 안내를 따른다. 다른 OpenJDK 배포판을 사용한다면 해당 공급업체의 공지를 확인한다.
인증서 신뢰 저장소를 관리하는 방식도 다를 수 있다.
예를 들어 Red Hat은 일부 OpenJDK 패키지가 운영체제의 ca-certificates를 사용하고, 별도 배포용 빌드는 자체 인증서 저장소를 포함한다고 설명한다. Java 업데이트와 운영체제 인증서 패키지 업데이트 중 무엇이 필요한지 배포 방식에 따라 확인해야 한다. Red Hat 업데이트 안내
③ 서비스를 재시작하고 외부 연결을 점검한다
업데이트 후에는 실행 중인 서비스에 변경 사항을 반영하고 외부 API나 인증 서버 등과의 연결을 확인한다.
특히 인증서 차단 이후 연결 오류가 발생한다면 상대 서버의 인증서 체인을 확인할 필요가 있다.
④ 인증서 검증을 끄는 방식으로 해결하지 않는다
연결 오류를 없애려고 모든 인증서를 신뢰하도록 바꾸면 서버의 신원을 확인하는 보호 장치 자체가 사라진다.
문제가 생겼다면 인증서 체인과 공급업체 지침을 확인해야 한다. 검증 우회는 보안 업데이트의 대안이 될 수 없다.
8. 일반 사용자도 대응해야 할까?
Java를 직접 설치해 프로그램을 실행하고 있다면 해당 프로그램과 Java 공급업체의 업데이트 안내를 확인하면 된다.
회사 업무용 프로그램처럼 Java가 제품 안에 포함돼 있다면 사용자가 Java만 임의로 교체하기보다 제품 공급업체가 제공하는 보안 업데이트를 적용하는 편이 적절하다.
이번 사건은 HTTPS의 안전이 암호화 기술 하나로 끝나지 않는다는 점을 보여준다. 누구를 믿고 연결하는지, 그 신뢰 정보가 최신 상태인지도 보안의 일부다.
참고 자료