# Java, Node.js, Go, Python 의 인증서 문제는 모두 동일했습니다. eMudhra 키 붕괴와 이번 주 업데이트 순서

> https://bookfactory.kr/board/news/23869
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-10-26T00:50:07.212Z

---

이번 주 Java, Node.js, Go, Python 에서 각각 '인증서' 관련 업데이트가 발표되었습니다. 겉으로는 별개의 사건처럼 보이지만, 근본은 동일한 사건이었습니다. 인도 인증기관 eMudhra 의 중간 인증서 8 개에서 비밀키가 누구나 계산 가능한 값으로 설정되어 있었습니다.

그 중 하나의 키는 '4'였습니다. 이 키가 있다면 어떤 사이트의 위조 인증서를 만들 수 있습니다.

브라우저는 주말에 자동으로 차단되었습니다. 그러나 자신만의 인증서 목록을 가진 런타임은 다릅니다. 본체나 목록을 업데이트하지 않는 한, 위조 인증서를 믿고 그대로 유지됩니다.

같은 주에 Node.js 보안 릴리스, Oracle Java 정기 패치, jackson-databind, Tomcat 수정이 겹쳤습니다. 모두 한 번에 처리하기는 어렵기 때문에, 우선순위를 정해 어디부터 시작할지 고려해 보았습니다.

## 키가 '4'였던 중간 인증서

문제가 된 것은 eMudhra 의 중간 인증서 8 개입니다. TLS 용 6 개, 코드 서명용 2 개입니다. 모두 P-384 타원 곡선 키를 사용했는데, 본래 거대한 무작위 값이어야 할 비밀 값이 매우 작았습니다.

8 개의 값은 156, 230, 115, 56, 155, 4, 66, 237 이다. 4 는 'EM OV TLS CA - G3C'의 키였다. 모두 256 보다 작으므로 완전 탐색으로 즉시 구할 수 있다.

eMudhra 의 설명에 따르면, 2025 년 4 월 30 일의 키 생성 시 스크립트에 결함이 있어 약한 두 번째 키가 생성되었고, 이름이 유사하여 실제 환경에서 사용되었다는 것입니다. 근본 원인은 아직 '확인되지 않음'으로 보고되고 있습니다.

그 상태가 약 17 개월 동안 지속되었습니다. 발견된 날짜는 10 월 17 일이며, 연구자 '웨인'이 발견하고 보고했습니다. 스콧 헬메 또한 독립적으로 잠금 장치를 복원했습니다.

유효기간에 차이가 있습니다. Mozilla 의 버그 관리 시스템 (Bugzilla) 은 10 월 18 일 오전 9 시 38 분 (UTC) 을, eMudhra 공식은 10 월 19 일로 명시하고 있습니다.

## 브라우저는 보호받았으나 런타임은 버림받았다

브라우저 측의 대응 속도가 매우 빠르었습니다. 크롬은 UTC 시간 10 월 17 일 19 시 45 분, 일본 시간으로는 18 일 새벽에 CRLSet이라는 기제로 차단했습니다. 안드로이드는 UTC 시간 19 일 22 시 경입니다.

파이어폭스는 17 일 22 시 59 분 (유니버설 시간대) 까지 OneCRL 로 차단했다. 애플은 19 일, 마이크로소프트는 20 일 대응했다고 보도되었다. 다만 이 두 회사에 대한 정보는 이차적인 것뿐이라 차단된 구체적인 방식은 확인되지 않았다.

크롬은 10 월 27 일 루트 인증서 'emSign ECC Root CA - G3'도 제거할 예정이며, 파이어폭스는 158.0.1(NSS 3.131.1) 버전에서 해당 루트를 제거했습니다.

Google 은 악용에 대해 "차단 전 이 중계 CA 에 연결된 TLS 인증서는 CT 로그에 단 한 건도 기록되지 않았다"고 밝힌 바 있으며, eMudhra 와 Cloudflare 역시 악용을 확인하지 않았습니다. CISA 가 악용이 확인된 취약점을 정리한 KEV 목록 10 월 21 일 버전에도 관련 CVE 가 포함되어 있지 않습니다.

이 부분에서 말할 수 있는 것은「남용은 확인되지 않았다」까지입니다. CT 로그를 확인하지 않은 클라이언트가 실제로 사용되었는지는 누구도 알 수 없습니다. 17 개월이라는 기간을 고려하면「없었다」と는 표현은 적절하지 않습니다.

문제는 여기에 있습니다. Java, Node.js, Go, Python 의 일부는 OS 나 브라우저와 별도로 자체 인증서 목록을 보유하고 있습니다. 브라우저가 보호되어 있더라도 각자가 이를 갱신하지 않으면 가짜 인증서를 계속 믿게 됩니다.

![画像](https://assets.st-note.com/img/1792655848-t1rh5WziK6LJR8kxj3DdVIHu.png?width=1200)

## 런타임별 대응 현황

### 이 글은 현재 제공된 일본어 텍스트가 없습니다. 번역 요청하신 'note.com' 게시글 본문 청크 19/99 의 내용을 입력해 주시면, 즉시 자연스럽고 정확한 한국어로 번역해 드리겠습니다.

Go 는 10 월 19 일에 1.27.3 와 1.26.10 버전을 출시했습니다. crypto/x509 모듈에서 해당 중간 인증 기관을 거부하는 수정을 통해 CVE-2026-111943 이 해결되었습니다.

거부 목록은 표준 라이브러리에 포함되므로, 작성한 프로그램을 최신 Go 버전으로 재빌드하지 않으면 변경되지 않는다는 점을 여러 자료에서 언급하고 있습니다. Go 공식 문서에는 명시된 기록이 발견되지 않아 이는 2 차 정보로 판단됩니다. 또한 1.25 버전의 수정이 나오지 않는다는 점 역시 2 차 정보에 해당합니다.

### Node.js

Node.js 는 10 월 21 일의 22.23.4, 24.22.1, 26.12.1 버전에서 내장된 루트 인증서를 NSS 3.131.1 로 업데이트했습니다. 공식 블로그의 의존성 항목에도 'ca-cert (eMudhra Intermediate CA Compromise)'가 명시되어 있습니다.

### 파이썬

Certifi 는 2026 년 10 월 19 일, pip 은 26.2.2, uv 는 0.13.4 로 대응이 완료된 것으로 알려졌습니다. 버전 번호는 목록 사이트와 BleepingComputer 의 기록과 일치하지만, PyPI 와 같은 1 차 출처는 직접 확인하지 못했습니다.

표준 라이브러리의 SSL 은 OS 의 인증서 스토어를 읽습니다. requests 와 같이 certifi 를 사용하는 코드와는 별도로, OS 측의 업데이트도 필요하다는 뜻입니다.

### Linux 의 ca-certificates

Ubuntu 는 10 월 20 일 USN-8944-1 를 통해 업데이트를 배포했습니다. Debian 역시 bookworm 에게 20250419~deb12u2, trixie 에게 20250419+deb13u1 을 배포했습니다.

Alpine 의 20261020-r0, Fedora 의 2026.2.92_v9.0.31 이라는 버전 번호는 2 차 정보에서 확인한 것입니다. RHEL 은 RHSB-2026-012 로 '처리 중' 상태로 남아있으며, 10 월 21 일 현재 수정 패키지가 출시되지 않았습니다.

### Java(프로세서 버전에는 포함되지 않음)

가장 복잡한 건 Java 입니다. 처음에는 이번 주 정기 패치 (CPU) 에 대응책이 들어갔다고 생각했으나, 다시 확인한 결과 그렇지 않았습니다.

오라클은 10 월 20 일 CPU 를 배포했습니다. 배포 버전은 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u511 입니다. 그러나 다음 날인 21 일 오라클은 CVSS 3.1 점수 9.1 의 CVE-2026-91403(대역 밖 경고) 를 발표했습니다. 이 CPU 버전 자체를 '영향받는 버전'으로 명시했습니다.

경고 버전은 '8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1'로 표시됩니다. GraalVM for JDK 17.0.21/21.0.13 및 GraalVM EE 21.3.20도 대상입니다. CPU 버전의 릴리스 노트에는 eMudhra 나 emSign에 대한 언급이 없습니다.

해결책이 적용되는 것은 이후 출시되는 마지막 버전이 '0.2'로 끝나는 버전이기 때문입니다. OpenJDK 저장소에서 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2 버전의 업데이트가 확인되었습니다. 27.0.1.0.2 와 11.0.33.0.2 는 목록 사이트의 표에서만 확인된 것입니다.

주의해야 할 점은 오라클 경고 자체에 수정 버전 번호가 명시되어 있지 않다는 것입니다. 단지 패치 문서를 확인하라고 안내하고 있을 뿐입니다.

8u 는 아직 불확실하다. 목록 사이트는 8u511 을 수정 버전으로 명시하고 있으나, Oracle 은 이를 영향 버전으로 분류하고 있다. 일차 정보와 내용이 상충하므로, 8u511 에는 대응이 완료되었다고 단정할 수 없다. 8u 의 수정 버전 번호는 아직 확인되지 않았다.

또 하나의 함정은 JDK 인증서 목록 (cacerts) 의 위치입니다. Debian, Ubuntu, Fedora, RHEL 등 배포판의 OpenJDK 패키지는 OS 스토어와 연동되어 있습니다. 이는 ca-certificates 를 업데이트하면 해결됩니다.

반면, 벤더 버전 JDK, tarball 을 배포한 JDK, 또는 Docker 이미지 내의 JDK 는 자체 cacerts 를 사용합니다. OS 를 업데이트해도 이 부분은 변하지 않습니다. 아이러니하게도, OS 스토어 연동 측면의 RHEL 은 해당 OS 패키지가 아직 출시되지 않았습니다.

![画像](https://assets.st-note.com/img/1792655858-a5MEXWkJgFdItzDVxA08KLRj.png?width=1200)

BellSoft 의 검증에서는 Liberica 21.0.10, 8u504, 21.0.12.1 이 확인용 12 호스트 모두를 신뢰할 수 있었습니다. Temurin 25.0.4.1 은 그 중 6 개였습니다. 두 버전의 패치 버전 번호는 22 일 기준으로 확인되지 않았습니다. GraalVM 의 native-image 로 생성된 것은 재빌드가 필요합니다.

BellSoft 는 0.2 버전이 아직 사용자에게 도달하지 않았을 때의 임시 방안으로, keytool 을 사용하여 두 개의 별명을 삭제하는 방법을 안내하고 있습니다.

emSign 로 발급된 인증서만 제거해서는 안 됩니다. 총 8 개의 중간 인증서는 Sectigo 의 'AAA Certificate Services' 하에서도 교차 인증 방식으로 발급되었기 때문입니다. OpenJDK 본체의 수정은 cacerts 에서 인증서를 삭제하는 방식이 아니라, blocked.certs 에 인증서를 추가하는 방식으로 이루어진다는 것입니다.

다만, ComodoAAACA 는 Sectigo 계열의 루트 인증서입니다. 이를 삭제하면 다른 정상적인 사이트에도 연결이 실패할 수 있으므로, 실제 환경에 적용하기 전에 연결 대상에 미치는 영향을 먼저 확인해야 합니다.

## curl 로 해결 여부를 확인합니다.

확인용으로는 Dennis Jackson 명의로 제작된 목록 사이트를 제공하는 호스트를 사용할 수 있습니다. 이는 Mozilla 공식 사이트가 아닌 커뮤니티에서 만든 것입니다. Dennis Jackson 은 또한 Bugzilla 에서 이 문제를 제기한 사람입니다.

시작할 때는 적어도 다음 두 가지를 눌러보세요. 아무런 표시가 나타나지 않는다면 연결이 성공했음을 의미하며, 아직 신뢰하고 있다는 뜻입니다.

사이트 설명은 다음 한 문장으로 요약됩니다.

> 
> 
> 인증서 오류는 클라이언트가 손상된 중간 인증서를 신뢰하지 않는다는 것을 의미합니다.
> 

저의 해석은 "인증서 오류가 발생하면 해당 클라이언트는 문제의 중간 인증서를 신뢰하지 않는다는 뜻입니다."입니다.

첫 번째는 emSign 루트를 경유하는 시스템만 테스트 가능합니다. 두 번째는 Sectigo AAA 를 경유하는 시스템이 됩니다. Temurin 과 같이 한쪽만 거부하는 예가 있으므로, 두 곳에서 모두 오류가 발생해야 안심할 수 있습니다. 호스트는 총 12 개이며, 모두 테스트하려면 BellSoft 의 검증 코드를 사용할 수 있습니다.

하지만 curl 로 확인할 수 있는 것은 curl 이 사용하는証明書 스토어뿐입니다. Java, Node.js, Go, certifi 는 각각 별도의 스토어를 가지고 있으므로 각각 테스트해봐야 합니다. Node.js 의 경우 다음과 같이 작성할 수 있습니다.

에러의 내용도 확인해야 합니다. 인터넷 연결이 끊기거나, 호스트가 응답하지 않거나, 호스트가 다운되었더라도 에러가 발생할 수 있습니다. 메시지를 통해 인증서 검증이 거부되었는지 확인하세요.

사내 TLS 검사 프로кси를 경유하는 환경에서는 근본적으로 판단 자체가 불가능하며, 인증서가 프로кси에서 교체되기 때문에 결과는 프로кси 측의 신뢰 판단에 의존하게 됩니다.

![画像](https://assets.st-note.com/img/1792655867-EMWly5TZt6GdjRDbrI2QwvzJ.png?width=1200)

## 개인의 개발 환경에서 놓치기 쉬운 부분

서버뿐만 아니라 개발용 머신에도 같은 문제가 있습니다. 자신의 머신을 다시 점검해 보니, 주의해야 할 점은 다음과 같습니다.

먼저 Node.js 제조사의 개발 도구를 소개합니다. CLI 나 에디터 확장, 로컬에서 실행 중인 MCP 서버 등은 각기 사용하는 Node.js 스토어에서 검증합니다. nvm 나 Volta 로 여러 버전을 설치해 둔 경우, 사용 중인 모든 버전을 업그레이드하세요.

다음은 파이썬 관련 내용입니다. certifi 는 프로젝트의 가상 환경 전체에 포함됩니다. pip 와 uv 도 본문에 인증서 목록을 포함하고 있으므로, 도구 자체의 업데이트도 필요합니다.

Go 의 바이너리도 놓치기 쉽습니다. go install 로 설치한 도구나 배포된 바이너리는 생성 당시의 Go 버전을 그대로 유지합니다. 어떤 Go 버전으로 생성되었는지 확인하려면 다음 명령어를 사용하세요.

macOS 에 내장된 curl, git, python3 도 주의해야 합니다. 목록 사이트의 정보에 따르면 이 프로그램들은 /etc/ssl/cert.pem 파일을 읽는데, Apple 이 이 파일을 아직 업데이트하지 않았습니다. Apple 이 차단 효과를 발휘하는 것은 macOS 표준 인증서 검증 기능을 사용하는 앱에만 국한된다는 것입니다. 이 내용은 커뮤니티에서 공유된 정보입니다.

## 동일한 주에 겹친 Node.js 관련 10 가지

Node.js 2024 년 10 월 21 일 릴리스에는 인증서와 별개로 취약점 10 개가 수정되었습니다. 세부 내용은 고중요도 4 개, 중중요도 3 개, 저중요도 3 개입니다. 수정 대상은 26 세, 24 세, 22 세 버전입니다.

가장 심각한 것은 CVE-2026-111497이다. Brotli라는 압축 형식의 디코딩 과정에서 메모리 영역 밖으로 데이터를 쓰게 된다. 공식 제목에는 '리모트 코드 실행을 허용한다'는 내용이 있다.

다만, 공식적으로 활성화 조건이나 영향을 미치는 API, CVSS 값은 공개되지 않았습니다. Brotli 는 HTTP 의 'Content-Encoding: br' 헤더에서 사용되므로, 외부에서 수신한 압축 데이터를解压하는 처리가 궁금한 것은 제 추측일 뿐입니다.

남은 취약점은 총 3 개로, TLS 2 개와 DNS 1 개입니다. CVE-2026-105483 은 가짜 숫자로 작성된 IP 주소로 TLS 호스트명 검증을 우회할 수 있는 문제입니다. 영향을 받는 버전은 26 세기와 24 세기로, 22 세기는 포함되지 않습니다.

CVE-2026-106069 는 호스트가 느슨하게 IP 로 해결될 경우 호스트명 확인을 우회할 수 있는 취약점이며, 이 취약점은 22 버전에도 해당됩니다. CVE-2026-105482 는 dns.resolve 가 NUL 문자를 포함한 이름을 중간에 잘라버리는 취약점입니다.

수정 버전은 22.23.4, 24.22.1, 26.12.1 입니다. 함께 제공되는 OpenSSL(22 세기 버전 3.5.9), c-ares, undici 또한 업데이트되었습니다.

노드 20 은 2026 년 4 월 30 일 지원이 종료되었으며, 수정 패치가 제공되지 않습니다. 공식 웹사이트는 "지원 종료 버전은 항상 영향을 받는다"고 명시하고 있습니다.

## Java 의 주변 환경에서 세 가지가 동시에 실행되었습니다.

### 오라클 10 월 CPU

Oracle 의 CPU 에서 Java SE 관련 취약점이 55 건 발견되었습니다. 최고 점수는 CVSS 7.5 로, JavaFX 의 WebKitGTK 과 Java 플러그인 두 건입니다. 이 두 가지는 모두 "신뢰할 수 있는 코드만 실행하는 서버에는 해당되지 않는다"고 명시되어 있습니다. 또한 IPA 는 10 월 21 일에 주의보를 발령했습니다.

이 '최대 7.5'는 eMudhra 의 CVE-2026-91403(9.1) 과는 별개의 문제입니다. CPU 수치만 보고 가볍게 추산하면 9.1 을 놓칠 수 있습니다.

### 제이콥슨 데이터 바인드 CVE-2026-110879

Java 생태계에서 가장 치명적인 취약점은 이 것입니다. 10 월 20 일에 공개되었으며, 심각도 등급은 Critical, CVSS 점수는 9.8 입니다. 이전에 공개된 CVE-2026-54512 의 패치가 불완전했기 때문입니다.

외부 클래스는 타입 체크가 수행되지만, 제네릭의 인수나 배열 요소의 타입은 체크가 느슨합니다. 직접 지정하면 거부되는 클래스라도 해당 위치에 넣으면 통과해버립니다.

조건은 클래스 이름을 기반으로 타입을 결정하는 설정 (기본 타입 지정 등) 이 활성화되어 있고, 공격자가 생성한 JSON 이 해당 위치로 도달하는 경우이며, Spring 이 있다면 ProcessBuilder.start() 를 통한 명령어 실행까지 경로가 명시되어 있습니다.

스프링이 없더라도 안전한 것은 아닙니다. JDK 만으로 구성된 경로에서도 파일 생성, 절단, URL 요청 등 피해 사례가 보고되고 있습니다. PoC(재현용 코드) 는 공개되었으나, 실제 악용 사례는 아직 없습니다.

수정 버전은 2.18.12, 2.21.8, 2.22.4 입니다. 2.19 시리즈와 2.20 시리즈는 2.21.8 으로 업그레이드됩니다. 3.x 시리즈의 경우 3.1.8 또는 3.2.4 입니다. 즉시 업그레이드가 불가능한 경우, 신뢰할 수 없는 데이터로 클래스 이름을 기반으로 타입을 판별하지 않고, 허용하는 서브타입을 축소하며, 불필요한 의존성을 제거하는 등의 회피 전략을 취해야 합니다.

### 토마캣

Tomcat 의 수정 버전은 11.0.27, 10.1.61, 9.0.123 입니다. 각 페이지의 제목에 명시된 릴리스 날짜는 10 월 12 일이나, 취약성 공개는 10 월 20 일이었습니다.

중요한 점은 세 가지입니다. CVE-2026-101296 는 JNDIRealm 에서 GSSAPI 가 아닌 SASL 인증을 구성할 경우, 올바른 비밀번호 없이도 인증이 통과되는 취약점입니다. CVE-2026-101356 은 비동기 서블릿과 HTTP/2 를 결합했을 때 요청과 응답이 혼동될 수 있는 문제입니다. 이 두 가지 취약점은 모든 세 시스템에 해당합니다.

CVE-2026-103119 의 세 번째 취약점은 AJP 응답 처리 오류로, 11 계통만이 영향을 받습니다.

Tomcat 은 자체적으로 cacerts 파일을 보유하지 않습니다. eMudhra 대응은 Tomcat 을 실행 중인 JVM 에서 처리하게 됩니다.

## 업데이트 순서

오늘 안에 모두 마무리할 수 있는 현장이라고 생각되는 곳은 많지 않다고 봅니다. 처음 계획했던 순서대로 조사하여 발견한 수정 사항을 반영하면 다음과 같이 됩니다.

![画像](https://assets.st-note.com/img/1792655876-evOlGu5ViWQZEDpPcyA72FzU.png?width=1200)

1 단계: Node.js 를 수정판으로 업그레이드합니다.

22.23.4, 24.22.1, 26.12.1 중 하나를 선택하십시오. Brotli 관련 활성화 조건이 명시되지 않았으므로, 외부 URL 을 접근하는 서버나 도구를 먼저 처리해야 합니다. 이 버전에는 동봉된 루트 인증서가 업데이트되므로 eMudhra 대응 작업도 여기에서 완료됩니다. Node 20 이 전인 경우, 여기에서 22 시리즈 이상으로 업그레이드하십시오.

단계 2: eMudhra 대응을 추가합니다.

대상은 OS 의 ca-certificates, Go 도구 재빌드, certifi·pip·uv, JDK 의 cacerts 입니다. 디스트리 버전의 OpenJDK 은 OS 업데이트로 해결됩니다. 벤더 버전이나 tarball, 컨테이너 JDK 은 .0.2 버전이 출시되었다면 이를 업그레이드하고, 출시되지 않았다면 BellSoft 의 임시 방안을 참고하여 검토합니다. Docker 이미지는 재작성합니다.

완료되면 curl 을 사용하여 두 호스트를 각각 호출하여 인증서 오류가 발생하는지 확인하고, Java, Node.js, Python 은 각 런타임에서도 테스트해 보십시오. RHEL 은 패키지 대기 중이므로 이 부분만 별도로 추적하십시오.

단계 3: jackson-databind 업그레이드

외부에서 JSON 을 읽어오는 앱이 대상입니다. 클래스 이름에 따른 타입 판별을 통해 JSON 을 읽어야 합니다. 2.18.12, 2.21.8, 2.22.4, 3.1.8, 3.2.4 중 하나를 선택하세요. Spring 이 있는지 여부에 따라 처리를 미루지 마십시오.

4 단계: Java 실행 환경과 Tomcat 배포

Java 본체는 10 월 20 일 CPU 버전에서 중단하지 않고 0.2 버전을 목표로 합니다. CPU 버전은 Oracle 이 자체적으로 eMudhra 영향 버전으로 분류했기 때문입니다. 8u 는 수정 버전 번호가 명확해질 때까지 벤더 발표를 계속 추적합니다.

Tomcat 을 11.0.27, 10.1.61, 9.0.123 으로 업그레이드합니다. JNDIRealm 에서 SASL 을 사용하거나 HTTP/2 에서 비동기 서블릿을 사용하는 환경은 이 중에서도 우선적으로 진행해야 합니다.

## 브라우저에 맡길 수 없는 장소를 미리 알아두세요

이번 사건을 통해 다시 한번 깨달은 점은 인증서의 신뢰가 브라우저 내부에만 국한되지 않는다는 점입니다. 크롬이 하루 만에 차단해 주더라도, 그 뒤에서 작동하는 Node.js 나 Java, Go 바이너리는 사용자가 직접 업데이트할 때까지 오래된 목록 그대로 작동합니다.

또한 목록의 저장 위치는 런타임마다 각기 다릅니다. OS 스토어, JDK 의 cacerts, certifi, Go 의 표준 라이브러리, Node.js 내장 버전 등 같은 머신 안에 여러 개 존재합니다. 어디에 무엇이 있는지 기록된 대장표는 다음 인증 기관 사고에서도 그대로 유효합니다.

귀하의 환경에서는 curl 의 두 호스트 모두 에러가 발생했나요? 각 런타임마다 결과가 달라졌거나, 예상치 못한 곳에 오래된 JDK 가 남아있었다는 등의 이야기가 있다면 댓글로 알려주세요.

이 기사는 2026 년 10 월 22 일 현재 공개된 정보를 바탕으로 작성되었습니다. Oracle 의 .0.2 버전이나 8u 수정 버전, RHEL 패키지, 각 JDK 벤더의 대응 내용은 앞으로 나올 것이 많으므로, 새로운 발표가 나오면 반드시 해당 내용을 우선적으로 확인하시기 바랍니다.

# 취약점 #보안 #인증서 #eMudhra #Java #Node.js #Go #Python #Tomcat #Jackson

**출처:** [note 원문](https://note.com/zephel01/n/n9398c1db9eb6)

*번역: Qwen 3.5(.48) 초벌 + 교정 62청크*

[원문 보기](https://note.com/zephel01/n/n9398c1db9eb6) | 출처: note.com