보안 가이드

eMudhra(emSign) 중간 CA 키 유출: Python 사용자가 pip, certifi, uv와 관련해 해야 할 일

eMudhra 중간 CA 키 8개는 누구나 복구할 수 있을 만큼 취약했습니다. Python 프로젝트는 사용자에게 pip 26.2.2, certifi 2026.10.19, uv 0.13.4로 이전할 것을 요청합니다. 영향을 받는 대상, 안전한 업데이트 순서, Docker, 잠금 파일, OS CA 번들, 완료 확인 방법을 정리합니다.

게시 2026-10-24 업데이트 2026-10-24 최종 확인 2026-10-24 17분 읽기

이 페이지에서

대상 독자: pip, uv, conda 또는 pixi로 패키지를 설치하는 모든 분, requests 같은 라이브러리로 HTTPS 호출을 하는 프로그램을 운영하는 분, Python Docker 이미지나 CI를 관리하는 분.

이 글은 Python 프로젝트(CPython 및 pip 개발자), certifi, uv, conda 프로젝트, Mozilla, Google, eMudhra, 그리고 Linux 배포판의 공식 발표를 바탕으로 작성되었습니다. 공격 방법이나 키가 어떻게 복구되었는지는 다루지 않습니다. 소셜 미디어에서는 이를 "Python 보안 비상사태"라고 부르고 있지만, Python 자체에서 코드 실행 결함은 발견되지 않았습니다.

모든 가상 환경과 Docker 이미지에서 pip를 26.2.2+, certifi를 2026.10.19+로 업그레이드하십시오

브라우저는 이미 영향을 받는 인증서를 차단하고 있습니다. 여전히 노출된 것은 pip나 requests처럼 브라우저 밖에서 자체 신뢰 CA 목록을 가진 프로그램입니다.

pip를 26.2.2 이상으로 업그레이드하십시오. 구버전 pip로 자기 자신을 일반적으로 내려받게 하지 마십시오. 공식 게시글의 해시 고정 명령을 사용하십시오
새 pip로 certifi를 2026.10.19+, uv를 0.13.4+로 업그레이드하십시오
모든 가상 환경에서 반복하십시오. Python 3.11과 3.12에서는 가상 환경을 만들 때마다 pip를 업그레이드하십시오
Docker 이미지는 캐시 없이 다시 빌드하고, 잠금 파일의 certifi 고정 버전을 올리십시오
Linux에서는 OS의 ca-certificates 패키지도 업데이트하십시오

続報待ち：この記事は公式発表に合わせて更新します

2026년 10월 24일 (JST)

まだ分かっていないこと

CPython의 ssl 모듈이 손상된 중간 키를 거부할지 여부(변경이 검토 중이며 아직 병합되지 않음)
Python 3.11 및 3.12와 해당 Docker 공식 이미지가 구버전 pip를 어떻게 처리할지(릴리스 관리자는 pip를 올리는 대신 손상된 중간 인증서를 차단하는 ssl 모듈 변경을 백포트할 계획이며, 10월 24일 기준 병합되지 않음)
eMudhra의 최종 근본 원인 보고서
Chrome의 루트 제거 일정 (10월 27일, 태평양 시간)

Python 프로젝트는 10월 20일 공지를 게시했고, 10월 21일 Python 3.15.1, 3.14.9, 3.13.17을 배포했습니다. Chrome과 Firefox는 10월 17일 영향을 받는 중간 인증서를 차단했습니다. 공격 악용은 발표되지 않았습니다. 3.11과 3.12에 대한 결정 및 CPython의 추가 변경 사항은 확인되는 대로 추가하겠습니다.

나는 영향을 받는가? 환경별 빠른 표

영향 여부는 Python 설정의 어느 부분이 CA 목록을 가지고 있는지에 따라 다릅니다. 한 대의 컴퓨터에도 Python 버전별, 설치 방법별, 가상 환경별로 각각 다른 목록이 있을 수 있습니다.

환경	구버전 목록을 가진 대상	해야 할 일
pip를 사용하는 모든 환경	pip 내장 certifi (OS 수정 후에도 남음)	pip를 26.2.2+로 업그레이드
requests 등 독립 certifi를 사용하도록 설정된 프로그램	독립 certifi 패키지	certifi를 2026.10.19+로 업그레이드
uv를 사용하는 환경	uv에 내장된 CA 목록	uv를 0.13.4+로 업그레이드
conda, Mamba, pixi	각 도구 및 환경 내 certifi, ca-certificates 패키지	conda 26.9.4+, pixi 0.82.1+로 업그레이드하고, 환경 내 certifi와 ca-certificates도 업그레이드
python.org macOS 설치 프로그램의 Python	설치 프로그램에 포함된 certifi	공식 게시글에 따라 pip와 certifi 업그레이드; 3.13 이상은 수정된 Python으로 이전
Docker 이미지와 CI	빌드 시점의 pip, certifi, OS 번들	캐시 없이 다시 빌드
Linux 패키지(apt, dnf)로 설치한 pip 또는 certifi	OS ca-certificates (Debian은 pip가 이를 사용하도록 패치)	ca-certificates를 수정된 버전으로 업데이트

urllib3를 직접 사용하는 경우 기본값은 시스템 CA 저장소입니다. 해당 저장소를 업데이트하십시오. 설정에서 certifi나 다른 번들을 명시적으로 사용한다면 그 번들도 업데이트하십시오(urllib3 인증서 검증 가이드).

무슨 일이 있었나요 (공식 발표 기준)

eMudhra 중간 키 사건 (2026년 10월)

보고: 2026년 10월 17일, 한 보안 연구자가 Apple, Google, Microsoft, Mozilla의 루트 프로그램과 eMudhra에 eMudhra 중간 인증서 8개의 개인 키를 복구할 수 있다고 보고했습니다
범위: 중간 인증서 8개. 6개는 TLS(HTTPS)용이며 Chrome, Mozilla, Microsoft, Apple이 신뢰했습니다. 2개는 코드 서명용입니다. 모두 2025년 4월 30일 키 생성 의식에서 만들어졌습니다. TLS 중간 인증서 6개는 루트 emSign ECC Root CA - G3에 연결되며(코드 서명용 2개는 다른 루트 아래에 있음)
원인: Google은 개인 키가 충분하지 않은 무작위성으로 생성되었다고 밝혔습니다. Mozilla는 독립적으로 키를 복구했으며 키 생성에 결함이 있었음을 확인했다고 밝혔습니다. eMudhra는 의식의 한 단계에서 강한 키와 함께 약한 두 번째 키 세트가 만들어졌고, 실제로 사용된 것은 약한 키였다고 밝혔습니다. 전체 근본 원인은 아직 조사 중입니다
키로 가능한 일: Mozilla는 이 키로 키 보유자가 통제하지 않는 사이트에 대한 부정 HTTPS 인증서를 발급할 수 있다고 밝혔습니다. 사용자의 연결을 가로챌 수 있는 공격자는 이를 이용해 웹사이트를 사칭하고, 트래픽을 읽거나 변조할 가능성이 있습니다
eMudhra의 대응: 10월 18일 8개 모두를 폐기했습니다. 7개는 운영에서 사용된 적이 없고, 사용된 1개도 어떤 인증서도 발급하지 않았다고 설명했습니다. 10월 20일 이 루트에 대한 발급을 중단했으며, 10월 22일 글로벌 SSL/TLS 인증서 사업에서 철수한다고 발표했습니다
브라우저: Chrome은 10월 17일 CRLSet을 통해 키를 차단했습니다. Firefox는 같은 날 OneCRL을 통해 차단했고, 10월 20일 Firefox 158.0.1과 ESR 업데이트를 배포했습니다. 10월 20일 Mozilla는 루트에 대한 긴급 제거를 결정하고 NSS 3.131.1에서 제거했습니다. Chrome은 10월 27일(태평양 시간) 이를 제거할 예정입니다
Python 프로젝트: 10월 20일 공지를 게시했고(10월 22일까지 갱신), 최소 certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4, pixi 0.82.1로 업그레이드하고 레이어 캐시를 비활성화한 상태로 컨테이너 이미지를 다시 빌드할 것을 요청했습니다. 10월 21일에는 pip 26.2.2를 포함한 Python 3.15.1, 3.14.9, 3.13.17을 배포했습니다

certifi는 신뢰된 인증기관 목록을 가진 널리 쓰이는 Python 패키지입니다. Mozilla 목록에서 파생되며, requests와 pip는 서버 인증서가 정상인지 판단하는 데 이를 사용합니다. certifi 2026.10.18(10월 18일 UTC 배포)은 모든 emSign 루트를 제거했고, 2026.10.19(10월 20일 UTC 배포)는 영향을 받지 않는 emSign 루트를 복원했습니다. certifi의 자체 권고문은 2026.10.18을 수정 버전으로 나열하지만, GitHub Advisory Database 항목과 Python 프로젝트는 영향을 받지 않는 emSign 루트와의 호환성을 위해 2026.10.19 이상을 권장합니다. 이후 certifi 2026.10.23은 Mozilla를 따라 emSign 루트 두 개를 더 제거했습니다(eMudhra는 이 제거가 이전에 계획된 것이며 이 사건과 무관하다고 밝혔습니다).

얼마나 심각한가요?

Chrome, Firefox

10월 17일 차단. 공개 CT 로그에 없는 인증서도 거부

26.2.2 이전 pip

OS 수정 후에도 항상 내장 certifi를 읽음

requests 및 기타 certifi 기반 클라이언트

2026.10.19 이전의 독립 certifi 사용

0.13.4 이전 uv, Docker 이미지

빌드 시점의 목록 유지

브라우저는 푸시 차단으로 보호되었습니다. Python 도구는 자체 CA 목록이 업데이트되기 전까지 위조 인증서를 신뢰합니다.

브라우저는 두 가지 방식으로 보호됩니다. 차단 목록을 자동으로 받으며, 공개 Certificate Transparency(CT) 로그에 없는 인증서를 거부합니다. Google은 차단 이전에 영향을 받는 중간 인증서에 연결된 TLS 인증서가 CT에 기록된 적이 없다고 밝혔으므로, CT를 강제하는 클라이언트에 위조 인증서가 사용될 수 없었다고 설명합니다.

pip와 requests는 두 메커니즘을 모두 사용하지 않습니다. 자체 보유한 CA 목록만으로 판단하므로, 목록이 오래되었다면 위조 인증서를 정상으로 받아들입니다.

발생할 수 있는 일

네트워크 경로상의 공격자가 PyPI, python.org 및 기타 사이트로의 연결을 가짜 서버로 돌림
pip install이 변조된 패키지를 설치함
requests로 보낸 API 키나 비밀번호가 읽힘

공격자에게 필요한 것과 확인된 사실

공격자는 사용자의 네트워크 경로(같은 Wi-Fi, 침해된 라우터, 기업 프록시 등)에 있어야 합니다
Python 자체에는 코드 실행 결함이 없습니다
10월 24일 기준 악용 사례는 발표되지 않았습니다

방심하지 마십시오. Mozilla는 10월 20일 여러 사람이 독립적으로 키를 복구했고 일부는 이를 공개했다고 밝혔으므로, 위조 인증서를 만드는 것은 어렵지 않습니다. 누군가 경로에 끼어들 수 있는 곳, 예컨대 공용 Wi-Fi, 공유 네트워크, CI 러너 주변 네트워크에서는 구버전 pip를 실행하지 마십시오. 이 부분은 공용 Wi-Fi 위험 가이드에서 다룹니다.

먼저 버전을 확인하십시오

pip 버전 확인

확인하려는 Python으로 실행하십시오(가상 환경을 사용한다면 그 안에서). 버전 26.2.2 이상이면 수정된 것입니다.

python -m pip --version

pip만 단독으로 실행하면 다른 Python의 pip를 가리킬 수 있습니다. 어떤 Python을 확인하는지 알 수 있도록 python -m pip를 사용하십시오.

certifi 버전 확인

requests 등 라이브러리가 사용하는 독립 certifi를 보여줍니다. 버전 2026.10.19 이상이면 수정된 것입니다. 설치되어 있지 않다면 pip가 "not found" 경고를 출력합니다.

python -m pip show certifi

pip 내장 certifi는 별도의 사본입니다. python -m pip debug를 실행하고 "vendored library versions" 아래의 certifi== 줄을 확인하십시오. pip 26.2.2로 업그레이드한 후에는 2026.10.19로 표시됩니다.

uv와 conda 확인

uv --version(0.13.4 이상이면 수정됨), conda --version(26.9.4 이상), pixi --version(0.82.1 이상)을 실행하십시오.

Python이 설치된 모든 위치 목록화

한 대의 컴퓨터에는 OS의 Python, python.org의 Python, Homebrew나 pyenv의 Python, 프로젝트별 가상 환경(예: .venv)이 함께 있는 경우가 많습니다. 가상 환경은 pyvenv.cfg 파일이 있는 디렉터리입니다. 전체 목록을 먼저 작성하면 누락을 줄일 수 있습니다.

안전한 순서로 업그레이드하십시오

순서가 중요합니다. 구버전 pip는 영향을 받는 인증서를 신뢰하므로, 단순히 새 pip를 내려받으면 그 다운로드가 가로채였을 때 가짜 pip가 설치될 수 있습니다. Python 프로젝트는 파일 해시(파일 내용의 지문)를 고정해 pip를 설치한 다음, 그 pip로 나머지를 처리할 것을 권장합니다.

해시를 고정해 pip를 26.2.2로 업그레이드

공식 게시글과 Python 블로그에 pip 26.2.2 파일 URL과 SHA-256 해시가 포함된 명령이 나와 있습니다. 형태는 다음과 같습니다. URL과 해시는 공식 게시글에서 그대로 복사하십시오(여기서는 일부러 옮기지 않습니다).

python -m pip install "pip @ <공식 게시글의 URL>#sha256=<공식 게시글의 해시>"

해시를 고정하면 pip는 내용이 다른 파일의 설치를 거부하므로, 가로채인 다운로드로 가짜 pip를 설치할 수 없습니다. 공식 게시글에 따르면 브라우저는 이미 저장소를 업데이트했으므로 확인용으로 사용할 수 있습니다. 예를 들어 PyPI의 pip 26.2.2 파일 페이지를 열어 표시된 해시가 일치하는지 확인하십시오.

새 pip로 certifi와 uv 업그레이드

pip가 26.2.2가 되면 이를 사용해 certifi를 업그레이드하십시오. pip로 uv를 설치했다면 여기서 함께 업그레이드하십시오.

python -m pip install --upgrade certifi
python -m pip install --upgrade uv

uv를 독립 설치 프로그램으로 설치했다면 uv의 권고문에 따라 0.13.4 이상으로 이전하십시오. 권고문은 uv를 시스템 인증서로 전환하는 경우 OS가 영향을 받는 루트 또는 중간 인증서를 이미 제거했는지 먼저 확인해야 한다고 설명합니다.

모든 가상 환경에서 반복

pip와 certifi는 각 가상 환경 내부에 있습니다. Python 프로젝트는 시스템의 기존 모든 가상 환경에서 pip와 uv를 업그레이드할 것을 요청합니다. 더 이상 쓰지 않는 오래된 환경은 다시 만들거나 삭제하는 편이 빠를 수 있습니다.

3.13~3.15는 수정된 릴리스로 이전하고, 3.11과 3.12에서는 새 venv를 만들 때마다 pip 업그레이드

Python 3.15.1, 3.14.9, 3.13.17은 pip 26.2.2를 포함하므로, python -m venv로 만든 새 환경도 수정된 pip를 사용합니다.

Python 프로젝트에 따르면 호환성 위험 때문에 더 새로운 pip를 포함하는 3.11 또는 3.12 릴리스는 없을 예정입니다. 가상 환경을 만들 때마다 가장 먼저 pip를 업그레이드하십시오. pip 26.2.2는 Python 3.10 이상을 지원합니다. 3.9 이하에서는 수정된 pip를 사용할 수 없으므로 Python 자체를 업그레이드하십시오(3.10도 이미 지원 종료되었습니다).

python.org macOS Python은 해당 인터프리터로 업그레이드

python.org macOS 설치 프로그램의 Python에는 certifi가 포함되어 있습니다. 블로그는 3.13, 3.14, 3.15에 대해 해당 인터프리터를 직접 호출하는 명령을 제공합니다(공식 게시글은 3.15를 예로 듭니다). 예를 들어 /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15로 pip와 certifi를 업그레이드합니다. 자유 스레드 빌드(예: python3.15t)는 별도로 업그레이드하십시오. 설치 프로그램이 제공한 certifi에서 pip install --upgrade certifi가 실패하면, 공식 게시글은 --ignore-installed --no-deps certifi 옵션으로 재설치를 제안합니다.

Docker, CI, 잠금 파일

수정이 가장 자주 누락되는 부분입니다. 노트북만 고쳐서는 이미지와 CI 러너에 영향을 주지 않으며, 이들은 빌드 시점의 구버전 목록을 계속 보유합니다.

캐시 없이 Docker 이미지 다시 빌드

Python 프로젝트는 최신 OS 인증서를 가져오도록 레이어 캐시를 끄고 컨테이너 이미지를 다시 빌드할 것을 요청합니다. 예를 들어 docker build --pull --no-cache로 기본 이미지도 다시 받으십시오. 다시 빌드한 후에는 컨테이너 안에서 python -m pip --version을 실행해 확인하십시오.

10월 21일 Docker 공식 이미지는 3.13 이상 정의를 수정된 Python 릴리스(3.15.1, 3.14.9, 3.13.17)로 업데이트했습니다. 이미지 관리자는 Python이 새 릴리스를 배포하지 않는 한 3.11 및 3.12 태그의 pip를 올리지 않을 것이라고 밝혔습니다. 3.11 또는 3.12 이미지를 사용한다면 Dockerfile에서 해시를 고정해 pip를 26.2.2로 업그레이드하십시오.

requirements 및 잠금 파일의 certifi 고정 버전 올리기

requirements.txt 또는 constraints.txt의 certifi==2025.x.x 같은 고정 항목은 구버전 certifi를 그대로 되돌립니다. uv.lock, poetry.lock, pylock.toml, Pipfile.lock도 마찬가지입니다. certifi를 2026.10.19 이상으로 올리고 잠금 파일을 다시 생성한 뒤 이미지와 CI에 반영하십시오.

certifi와 pip를 의존성 쿨다운에서 제외

새로 게시된 버전을 고정된 기간 동안 기다렸다가 받아들이는 설정(의존성 쿨다운)을 사용한다면, 기간이 끝날 때까지 수정 버전이 적용되지 않습니다. 한 Python 패키징 관리자는 쿨다운 사용자가 업데이트할 때까지 계속 노출된다고 경고했습니다. certifi, pip, uv를 해당 설정에서 제외하십시오.

CI가 사용하는 액션과 도구 업그레이드

PyPI 게시에 사용하는 pypa/gh-action-pypi-publish GitHub Action의 수정 릴리스는 v1.14.3입니다. cibuildwheel은 v4.3.4 이상으로 업그레이드하십시오(v4.3.3에 수정이 포함되었고, v4.3.4는 Python 3.9 등 대상의 pip도 다룹니다). CI 설정이 오래된 버전을 고정하고 있지 않은지 확인하십시오.

다른 CA가 교차 서명한 사본에 주의하십시오

영향을 받는 중간 인증서 일부는 다른 인증기관이 교차 서명한 사본도 가지고 있었습니다. 교차 서명은 같은 중간 키를 다른 루트 아래에서 신뢰하게 만듭니다. CPython 핵심 개발자는 교차 서명에 사용된 루트가 2025년 4월 이전의 certifi 릴리스와, 이를 포함하는 오래된 pip 버전(예: certifi 2024.8.30을 포함한 pip 25.0.1)에 존재한다고 밝혔습니다. 교차 서명 CA에 따르면 이 루트는 Chrome과 Mozilla 저장소에서는 이미 제거되었지만, 10월 18일 기준 Microsoft와 Apple은 여전히 신뢰하고 있었습니다(Mozilla 기록). Debian과 Ubuntu 14.04~20.04(USN-8944-2)도 emSign 루트와 함께 이 교차 서명 루트를 제거했습니다. 교차 서명 CA는 10월 19일 교차 서명된 사본을 폐기했다고 밝혔지만, 브라우저 밖의 대부분의 클라이언트는 폐기 여부를 확인하지 않습니다. 오래된 번들에서 emSign 루트만 삭제하는 것으로는 부족합니다. 교차 서명 루트가 그대로 남기 때문입니다. certifi 2026.10.19 이상으로 이전하십시오(2025년 4월 이후의 certifi 릴리스에는 교차 서명 루트가 없습니다).

OS 인증서 업데이트 (ca-certificates)

Linux에서 ca-certificates 패키지는 시스템 CA 목록을 보유합니다. curl과 OS 패키지로 설치된 Python이 이를 사용합니다.

배포판	공식 공지	수정 버전
Debian 13 (trixie)	DSA-6572-1 (10월 20일)	ca-certificates 20250419+deb13u1
Debian 12 (bookworm)	DLA-4845-1	ca-certificates 20250419~deb12u2
Ubuntu 26.10, 26.04, 24.04, 22.04	USN-8944-1 (10월 20일)	ca-certificates 20260816ubuntu0.(release)
Ubuntu 20.04, 18.04, 16.04, 14.04	USN-8944-2 (10월 20일)	Ubuntu Pro(ESM)를 통해 제공

Debian의 수정은 emSign ECC Root CA - G3와 교차 서명 루트를 제거합니다. Ubuntu의 USN-8944-1은 emSign ECC Root CA - G3를 제거하며, 22.04~~26.04에서는 목록을 Mozilla 번들 2.90 버전으로 갱신합니다. USN-8944-2는 14.04~~20.04에서 두 루트를 모두 제거합니다. Debian 자체 패키지(python3-pip)로 설치된 pip는 내장 certifi 대신 OS 목록을 읽도록 패치되어 있으므로, ca-certificates를 업데이트하면 해결됩니다. Windows와 macOS에서는 OS 업데이트를 설치하십시오.

업데이트 완료 확인 방법

모든 곳에서 세 가지 버전 확인

컴퓨터, 모든 가상 환경, 모든 Docker 이미지, CI에서 pip 26.2.2+, certifi 2026.10.19+, uv 0.13.4+를 확인하십시오. 구버전 사본이 하나라도 남아 있으면 완료되지 않은 것입니다.

certifi 목록에서 영향을 받는 루트가 사라졌는지 확인

python -m certifi는 certifi 번들 파일의 경로를 출력합니다. 그 파일에 "emSign ECC Root CA - G3"라는 이름이 더 이상 나타나지 않으면 목록이 수정된 것입니다.

grep -c "emSign ECC Root CA - G3" "$(python -m certifi)"

출력이 0이면 제거된 것입니다. Debian이나 Ubuntu의 패키지 certifi 파일에는 인증서 이름이 없으므로 0은 아무것도 증명하지 못합니다. 이 경우에는 ca-certificates 버전을 확인하십시오. pip 내장 목록은 pip 26.2.2 이상이면 수정된 상태입니다.

고정 항목과 OS 확인

requirements 파일과 잠금 파일에서 certifi를 검색하고, 2026.10.19보다 오래된 버전이 고정되어 있지 않은지 확인하십시오. Linux에서는 위 표의 수정 버전 이상으로 ca-certificates가 설치되어 있는지 확인하십시오(예: apt policy ca-certificates).

이 사이트의 견해: 브라우저를 보호한다고 나머지가 보호되는 것은 아닙니다

브라우저 사용자는 아무것도 하지 않아도 몇 시간 안에 보호되었습니다. 브라우저가 차단 목록을 자동으로 받고, CT 로그에 없는 인증서를 거부하기 때문입니다. pip, requests, CI 이미지에는 이런 장치가 없습니다. 각각 자체 CA 목록 사본을 가지고 있으며, 소유자가 하나씩 모두 업데이트해야 합니다. 그 사본은 가상 환경과 이미지의 수만큼 있습니다.

다음에 발생할 유사 사건에도 도움이 되는 습관이 하나 있습니다. requirements에 패키지 해시를 유지하십시오(--require-hashes). 해시가 자체 파일에 있으면, 가로채인 다운로드로 내용이 다른 패키지가 바꿔치기될 수 없습니다. 의존성 고정 및 점검은 OSV-Scanner로 의존성 감사하기를, 배포 채널 자체가 공격당한 사례는 LiteLLM 1.107.0 악성코드 사건을 참고하십시오.

웹사이트 운영자를 위한 안내

Chrome은 10월 27일(태평양 시간)부터 emSign ECC Root CA - G3를 신뢰하지 않습니다. Google은 이 루트에 연결된 인증서를 사용하는 운영자에게 Chrome Root Store에서 다른 계층(다른 루트 아래)의 새 TLS 인증서를 즉시 발급받을 것을 요청합니다. eMudhra 인증서를 사용한다면 발급 기관의 안내를 확인하십시오.

타임라인

2025년 4월 30일
eMudhra가 영향을 받은 8개를 포함한 중간 인증서를 키 생성 의식에서 만듭니다.
2026년 10월 17일
보안 연구자가 8개 키를 복구할 수 있다고 보고합니다. Chrome(CRLSet)과 Firefox(OneCRL)가 같은 날 차단합니다.
10월 18일
eMudhra가 중간 인증서 8개를 폐기합니다. certifi 2026.10.18이 모든 emSign 루트를 제거합니다.
10월 19일
교차 서명 CA가 교차 서명된 사본을 폐기합니다.
10월 20일
Mozilla가 루트의 긴급 제거를 결정합니다. certifi 2026.10.19, pip 26.2.2, uv 0.13.4가 배포되고 Python 프로젝트가 공지를 게시합니다. Debian과 Ubuntu가 ca-certificates를 업데이트합니다. Google은 Chrome이 10월 27일 루트를 제거한다고 발표합니다.
10월 21일
Python 3.15.1, 3.14.9, 3.13.17과 conda 26.9.4가 배포됩니다. Docker 공식 이미지가 3.13 이상 정의를 수정된 Python 릴리스로 업데이트합니다.
10월 22일
eMudhra가 글로벌 SSL/TLS 인증서 사업에서 철수한다고 발표합니다.
10월 23일
certifi 2026.10.23이 Mozilla를 따라 emSign 루트 두 개를 더 제거합니다.

출처 (공개 기록)

이 글의 사실은 아래 공개 출처에서 가져왔습니다. 키가 어떻게 복구되었는지나 공격에 사용할 수 있는 내용은 재현하지 않습니다.

Python 프로젝트, "Information for Python users regarding eMudhra / emSign CA certificate security incident"(2026년 10월 20일, 이후 게시글은 10월 24일까지 확인) — discuss.python.org
Python, "Python 3.15.1, 3.14.9 and 3.13.17 are out"(2026년 10월 21일) — blog.python.org
certifi 보안 권고(GHSA-6q48-6c7w-9gw2) — github.com / GitHub Advisory Database github.com
certifi, "Remove emsign"(#437, 2026년 10월 18일) — github.com / certifi 릴리스 기록 pypi.org
pip 변경 기록(26.2.2: certifi 2026.10.19로 업그레이드) — pip.pypa.io
uv 보안 권고(GHSA-hq85-5cpj-mr62) 및 0.13.4 — github.com
conda, "Security updates for conda, Mamba, and Pixi"(2026년 10월 21일) — conda.org
Google, "Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates"(2026년 10월 20일) — blog.google
Mozilla, "Protecting Firefox users following the compromise of eMudhra intermediate certificates"(2026년 10월 20일) — blog.mozilla.org
Mozilla 사건 기록(Bug 2083449: 중간 인증서 8개, 폐기 시각, 루트 제거, 교차 서명 사본) — bugzilla.mozilla.org
eMudhra, "eMudhra Statement on Recent Certificate Security Incident"(10월 20일 최초 게시, 10월 22일 갱신) — emudhra.com
eMudhra, "eMudhra to exit global SSL/TLS certificate business"(2026년 10월 22일) — emudhra.com
eMudhra 철수 관련 보도(The Record, 2026년 10월 22일) — therecord.media
Debian, "DSA-6572-1 ca-certificates"(2026년 10월 20일) — lists.debian.org / "DLA-4845-1 ca-certificates" lists.debian.org
Ubuntu, "USN-8944-1" 및 "USN-8944-2" ca-certificates(2026년 10월 20일) — ubuntu.com / ubuntu.com
Docker 공식 이미지(python) 이슈, "These images ship vulnerable pip"(3.13 이상 수정, 3.11 및 3.12 처리) — github.com
CPython, "Distrust compromised eMudhra intermediate CA keys"(추가 ssl 모듈 방어, 10월 24일 기준 미병합) — github.com
Python 버전 상태 — devguide.python.org

업데이트 기록

2026-10-24: 최초 버전. Python 프로젝트의 10월 20일 공지와 10월 23일까지의 게시글, Python 3.15.1, 3.14.9, 3.13.17 릴리스, certifi, pip, uv 권고, Google, Mozilla, eMudhra의 발표, Debian과 Ubuntu의 ca-certificates 업데이트를 바탕으로 작성했습니다. 3.11 및 3.12 처리와 추가 CPython 변경 사항이 결정되면 이 페이지를 업데이트하겠습니다.

다음으로 읽을 글

의존성 감사: OSV-Scanner로 의존성 감사하기
배포 채널 공격: LiteLLM 1.107.0 악성코드 사건 / Trivy 공급망 침해
취약점이 공개되었을 때: CVE 대응 플레이북
네트워크 경로상의 사칭: 공용 Wi-Fi 위험
용어: 공개 키 암호란 무엇인가? / Let's Encrypt란 무엇인가?

FAQ

Q무슨 일이 있었나요?

2026년 10월 17일, 인도 인증기관 eMudhra의 중간 인증서 8개(TLS용 6개, 코드 서명용 2개)의 개인 키가 2025년 4월 생성 과정의 결함 때문에 거의 즉시 복구될 수 있다는 보고가 있었습니다. Mozilla와 Google에 따르면, 이 키로 오래된 CA 목록을 사용하는 클라이언트에게 정상으로 보이는 임의 웹사이트의 인증서를 만들 수 있습니다. eMudhra는 10월 18일 8개 모두를 폐기했고, 10월 20일 Mozilla는 상위 루트 인증서에 대한 긴급 신뢰 제거를 결정했습니다.

Q이것은 Python 자체의 취약점인가요?

아닙니다. CPython에서 누구나 코드를 실행할 수 있게 하는 결함이 아닙니다. 문제는 Python의 TLS 클라이언트가 신뢰하는 CA 목록(certifi, 그리고 pip에 번들된 certifi 사본)에 해당 루트가 포함되어 있었다는 점입니다. 네트워크 경로상의 공격자가 위조 인증서를 사용하면 pip install 또는 requests 트래픽을 가짜 서버로 보낼 수 있습니다. PyPI에서의 다운로드가 가로채이면 변조된 패키지가 설치될 수 있으므로, Python 프로젝트는 사용자에게 빠른 업데이트를 요청하고 있습니다.

Q운영체제의 인증서를 업데이트하면 pip는 안전한가요?

아닙니다. CPython 핵심 개발자에 따르면, pip는 시스템 신뢰 저장소와 함께 내장된 certifi의 인증서를 항상 로드하며, 이를 끌 수 있는 지원되는 방법은 없습니다. 26.2.2보다 오래된 pip는 OS가 신뢰를 취소한 후에도 손상된 중간 인증서를 계속 신뢰하므로, pip 자체를 업그레이드해야 합니다. 한 가지 예외가 있습니다. Debian의 python3-pip 패키지는 내장 certifi 대신 OS 번들을 읽도록 패치되어 있으므로, ca-certificates를 업데이트하면 해결됩니다.

QPython 3.11 또는 3.12를 사용합니다. 무엇을 해야 하나요?

Python 프로젝트에 따르면 새 pip를 포함하는 3.11 또는 3.12 릴리스는 없을 예정입니다. ensurepip(python -m venv가 설치하는 pip)는 구버전으로 남아 있으므로, 가상 환경을 만들 때마다 pip를 26.2.2 이상으로 업그레이드하십시오. 3.11과 3.12용 Docker 공식 이미지도 여전히 구버전 pip를 제공합니다. 손상된 중간 키를 CPython의 ssl 모듈이 거부하도록 만드는 변경이 준비 중이지만, 10월 24일 기준 병합되지 않았습니다.

Q이 취약점이 악용되었나요?

10월 24일 기준 악용 사례는 발표되지 않았습니다. Google은 차단 이전에 영향을 받는 중간 인증서에 연결된 TLS 인증서가 Certificate Transparency에 기록된 적이 없다고 밝혔습니다. eMudhra는 공개 전에 약한 키가 복구되거나 악용되었다는 증거를 알지 못한다고 밝혔습니다. 그러나 Mozilla는 10월 20일 여러 사람이 독립적으로 키를 복구했고 일부는 이를 공개했다고 밝혔으므로, 업데이트하지 않은 브라우저 외부 클라이언트는 여전히 표적이 될 수 있습니다.

Q업데이트가 끝났는지 어떻게 알 수 있나요?

Python 측면에서는 모든 환경(개인 컴퓨터, 각 가상 환경, 각 Docker 이미지, CI)에 pip 26.2.2 이상, certifi 2026.10.19 이상, uv 0.13.4 이상이 설치되어 있으면 완료된 것입니다. 또한 어떤 requirements 파일이나 잠금 파일도 구버전 certifi를 고정하고 있지 않은지, Linux에서는 ca-certificates가 수정된 버전인지 확인하십시오. 아래 “업데이트 완료 확인 방법” 섹션에 점검 항목이 있습니다.

최신 속보

FAQ