hubly12/javafixCheck and fix Java runtimes for CVE-2026-91403 (compromised eMudhra intermediates) on Windows and macOS — consent-first, no dependencies, no network.
Java 인증서 취약점(CVE-2026-91403) 차단 목록 방식 임시 대응 도구 — Windows / macOS
PC에 설치된 Java(마인크래프트 런처, 모드 런처, 개발 도구, 직접 설치한 JDK)를 모두 찾아, OpenJDK가 안내한 **임시 조치(차단 목록에 문제의 인증서 16개 추가)**가 되어 있는지 확인합니다. 사용자가 동의하면 빠진 항목을 추가합니다. 선택하면 각 Java를 실제로 실행해 위장 인증서가 정말 거부되는지도 검사합니다.
이 도구는 완전한 해결책이 아닙니다. Java를 업데이트하지 않고, 신뢰 저장소(cacerts)를 고치지 않으며, 인증서 폐기 검사를 켜지 않습니다. 근본 해결은 Java와 런처를 수정된 버전으로 업데이트하는 것입니다. 자세한 내용은 3. 이 도구의 한계를 읽어 주세요.
외부 라이브러리 없이 Rust 표준 라이브러리만으로 만들어서, src/와 probe/ 폴더만 읽으면 하는 일을 모두 확인할 수 있습니다.
English: see English below.
2026년 10월, 인증기관 eMudhra의 중간 인증서 8개의 개인키를 누구나 알아낼 수 있다는 사실이 밝혀졌습니다. 같은 키로 Sectigo "AAA Certificate Services"가 교차 서명한 인증서까지 합치면 모두 16개입니다.
수정되지 않은 Java는 이 인증서들을 믿기 때문에, 공격자가 같은 네트워크(공용 Wi-Fi 등)에 있으면 아무 사이트로나 위장한 가짜 인증서를 만들 수 있고 Java는 그것을 진짜로 받아들입니다. 예를 들어 마인크래프트 로그인(세션) 서버나 모드 다운로드 서버로 위장할 수 있습니다.
OpenJDK가 안내한 조치는 아래 세 가지 중 하나입니다.
| 공식 조치 | 이 도구 |
|---|---|
| Java를 수정된 버전으로 업데이트 (Oracle/OpenJDK 기준 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2, 8u511 이상) | ❌ 하지 않음 (안내만) |
blocked.certs(Java 8은 blacklisted.certs)로 문제의 인증서 차단 | ✅ 16개 추가 |
인증서 폐기 검사 켜기 (-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true) | ❌ 하지 않음 (이유) |
참고 자료
impacted-intermediates.json)| 단계 | 내용 | 인터넷 |
|---|---|---|
| 파일 검사 | 찾은 Java마다 lib/security/blocked.certs(Java 8은 blacklisted.certs)와 release 파일을 읽어, 16개가 차단 목록에 있는지 봅니다. | 사용 안 함 |
| 실제 연결 검사 (선택) | 각 Java를 실제로 실행해 테스트 사이트 2곳과 Mojang 세션 서버에 접속해 보고, 위장 인증서가 거부되는지 확인합니다. 자세히 | 이 단계만 사용 |
| 차단 목록 추가 | 빠진 인증서 지문만 파일 끝에 추가합니다. 기존 줄은 지우거나 고치지 않고, 원본은 blocked.certs.bak-cve-2026-91403으로 백업합니다. 추가한 뒤 파일을 다시 읽어 확인합니다. | 사용 안 함 |
| 되돌리기 | 백업을 원래 자리에 복사합니다. | 사용 안 함 |
Y를 입력해야 진행합니다. 다른 입력은 모두 "아니오"입니다.%LOCALAPPDATA%\JavaFix, macOS ~/Library/Logs/JavaFix에 무엇을 검사하고 바꿨는지 남깁니다.cacerts)를 고치지 않습니다. 루트 인증서를 지우면 정상 사이트까지 막힐 수 있어서 건드리지 않습니다.
(예: Sectigo "AAA Certificate Services"는 많은 정상 사이트가 쓰는 루트입니다.)Releases 페이지에서 운영체제에 맞는 파일을 받습니다.
| 운영체제 | 파일 |
|---|---|
| Windows (대부분의 PC) | javafix-windows-x64.exe |
| Windows (ARM 노트북) | javafix-windows-arm64.exe |
| macOS (Intel / Apple Silicon 공통) | javafix-macos-universal.zip |
받은 파일이 원본인지 확인하려면 SHA256SUMS의 값과 비교하세요.
certutil -hashfile javafix-windows-x64.exe SHA256 (Windows)
shasum -a 256 javafix-macos-universal.zip (macOS)
Windows
javafix-windows-x64.exe를 더블클릭합니다.macOS
javafix-macos-universal.zip을 받아 압축을 풉니다(Safari는 자동으로 풉니다). javafix-macos 폴더가 생깁니다.javafix.command를 더블클릭하면 터미널이 열리고 실행됩니다.javafix.command를 우클릭 → 열기 → 열기를 누릅니다.터미널에서 바로 실행하려면:
cd ~/Downloads/javafix-macos
xattr -d com.apple.quarantine javafix.command
./javafix.command
v0.1.0의 압축되지 않은javafix-macos-universal파일은 내려받으면 실행 권한이 사라져서, 더블클릭하면 텍스트 편집기가 "텍스트 인코딩 유니코드(UTF-8)이(가) 적용되지 않습니다" 오류를 띄웁니다.v0.1.1부터 zip으로 배포합니다.
안내: 취약점 설명, 도구가 하는 일, 한계, 약속(백업·되돌리기·인터넷 사용 범위), 기록 파일 위치를 보여 줍니다.
메뉴: 1 검사하고 필요하면 차단 목록 추가 / 2 되돌리기 / 3 종료.
검사 동의 → 파일 검사: 1~3분 정도 걸립니다. 찾은 Java마다 상태, 버전, 위치를 보여 줍니다.
실제 연결 검사 동의 (선택): Y를 누르면 각 Java를 실행해 실제로 막히는지 확인합니다. Y가 아니면 건너뜁니다.
차단 목록 추가 설명: 무엇이 바뀌는지, 백업 위치, 영향 범위, 근본 해결 방법을 설명합니다. 실행 중인 Java 프로그램이 있으면 "다시 시작해야 적용된다"고 알려 줍니다. 이 도구는 프로그램을 종료하지 않습니다.
차단 목록 추가 동의: Y를 입력해야 추가합니다. 4번을 했다면, 추가한 Java를 다시 실제 연결 검사할지 묻습니다.
관리자 권한 동의 (필요할 때만): Program Files(Windows)나 /Library 같은 시스템 폴더(macOS)에 있는 Java는
관리자 권한이 있어야 바꿀 수 있습니다. 한 번 더 동의를 받은 뒤에
sudo로 다시 실행합니다(로그인 암호 입력).다시 실행된 쪽도 처음부터 설명하고 모든 단계에서 다시 동의를 받습니다.
마무리: 마인크래프트, 런처, IDE 등 Java 프로그램을 다시 시작하면 적용됩니다.
파일 검사
| 표시 | 뜻 | 도구가 하는 일 |
|---|---|---|
[차단 목록 적용] | 차단 목록에 16개가 모두 있음 (이것만으로 완전히 안전하다는 뜻은 아님) | 없음 |
[차단 목록 없음] | 일부 또는 전부가 없음 | 동의하면 추가 |
[차단 목록 없음] (관리자 권한 필요) | 위와 같지만 시스템 폴더에 있음 | 관리자 권한 동의 후 추가 |
[앱 업데이트] | macOS의 서명된 앱 안에 있는 Java | 바꾸지 않음 (앱 서명이 깨지므로). 해당 앱을 업데이트하세요. |
[확인 불가] | 차단 목록 형식이 다른 파일 | 바꾸지 않음. 해당 프로그램을 업데이트하세요. |
실제 연결 검사
| 표시 | 뜻 |
|---|---|
안전 (위장 인증서 거부) | 테스트 사이트 2곳이 모두 거부되고, Mojang 세션 서버에는 정상으로 접속됨 |
취약 (위장 인증서를 믿음) | 테스트 사이트 중 하나라도 접속됨. 차단 목록을 추가하거나 Java를 업데이트해야 합니다. |
판단 불가 (이유) | 인터넷 연결 없음, 너무 오래된 Java라 접속 자체가 안 됨, 실행 파일 없음, 시간 초과 등 |
차단 목록이 없어도 실제 연결 검사가 안전일 수 있습니다. 배포판이 문제의 루트 인증서를 빼는 방식으로 고친 경우입니다(예: Temurin 25.0.5+8).
반대로 차단 목록이 있는데 취약으로 나오면, 그 Java는 반드시 업데이트하세요.
파일만 보는 검사의 한계를 보완하기 위한 선택 단계입니다.
probe/JavafixProbe.java, Java 8 이상에서 실행)을
임시 폴더에 풀고, 찾은 각 Java로 실행합니다. 검사가 끝나면 임시 폴더를 지웁니다.dv-g3b-emudhra.we-have-a-problem.com: eMudhra 경로의 위장 인증서 → 거부되어야 정상dv-g3b-aaa-emudhra.we-have-a-problem.com: Sectigo AAA 경로의 위장 인증서 → 거부되어야 정상sessionserver.mojang.com: 비교용 → 접속되어야 정상 (안 되면 인터넷 문제로 보고 판단 불가 처리)HEAD 요청) 어떤 정보도 보내지 않습니다. JAVA_TOOL_OPTIONS 같은 환경 변수는 빼고 각 Java의 기본 설정으로 검사합니다.메뉴에서 2를 고르거나 --restore로 실행합니다. 이 도구가 만든 백업(*.bak-cve-2026-91403)이 있는 Java만 보여 주고,
동의하면 백업을 원래 파일 자리에 복사한 뒤 백업 파일을 지웁니다. 되돌리면 16개 인증서는 다시 신뢰되므로
Java를 업데이트한 뒤에만 되돌리는 것을 권장합니다.
javafix 대화형 실행 (더블클릭과 같음)
javafix --check 파일 검사만 하고 결과 출력 (아무것도 바꾸지 않음)
javafix --check --verify 파일 검사 + 실제 연결 검사 (인터넷 사용)
javafix --restore 되돌리기 모드로 바로 시작
javafix --lang ko|en 언어 선택 (기본: 시스템 언어)
javafix --scan-root <폴더> 지정한 폴더만 검사 (여러 번 사용 가능)
javafix --no-pause 끝날 때 엔터 대기 없이 종료
javafix --help / --version
--check의 종료 코드: 0 = 모든 차단 목록에 16개가 있음(--verify면 실제 검사에서 취약 없음), 2 = 조치가 필요한 항목 있음.
명령줄에 직접 입력한 것 자체를 검사 동의로 봅니다.