Руководства по безопасности

Компрометация промежуточных CA eMudhra (emSign): что делать пользователям Python с pip, certifi и uv

Ключи восьми промежуточных CA eMudhra были настолько слабыми, что их мог восстановить любой. Проекты Python просят пользователей перейти на pip 26.2.2, certifi 2026.10.19 и uv 0.13.4. Кого это касается, безопасный порядок обновления, Docker, lock-файлы, системные наборы CA и способ проверить, что всё сделано.

Опубликовано 2026-10-24 Обновлено 2026-10-24 Последняя проверка 2026-10-24 20 мин чтения
На этой странице

Для кого это: для всех, кто устанавливает пакеты через pip, uv, conda или pixi, для тех, кто запускает программы, которые делают HTTPS-запросы с помощью библиотек вроде requests, и для тех, кто поддерживает Docker-образы Python или CI.

Статья основана на официальных заявлениях проектов Python (разработчиков CPython и pip), проектов certifi, uv и conda, Mozilla, Google, eMudhra и дистрибутивов Linux. Она не описывает, как атаковать что-либо и как были восстановлены ключи. В соцсетях эту ситуацию называют «экстренной проблемой безопасности Python», но в самом Python не найдено ошибки выполнения кода.

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

24 октября 2026 года (JST)

まだ分かっていないこと

  • Будет ли модуль ssl в CPython отклонять скомпрометированные промежуточные ключи (изменение на рассмотрении и ещё не принято)
  • Как Python 3.11 и 3.12 и их официальные образы Docker будут работать со старым pip (релиз-менеджеры планируют перенести в более ранние версии изменение модуля ssl, которое блокирует скомпрометированные промежуточные сертификаты, вместо обновления pip; по состоянию на 24 октября не принято)
  • Итоговый отчёт eMudhra о первопричине
  • Удаление корневого сертификата из Chrome, запланированное на 27 октября (по тихоокеанскому времени)

Проекты Python опубликовали уведомление 20 октября и выпустили Python 3.15.1, 3.14.9 и 3.13.17 21 октября. Chrome и Firefox заблокировали затронутые промежуточные сертификаты 17 октября. Эксплуатация не объявлена. Мы добавим решения по 3.11 и 3.12 и любые дальнейшие изменения в CPython, когда они будут подтверждены.

Затронуты ли вы? Краткая таблица по окружениям

Затронутость зависит от того, в какой части вашей установки Python хранится список CA. На одном компьютере могут быть отдельные списки для каждой версии Python, для каждого способа установки и для каждого виртуального окружения.

ОкружениеЧто содержит старый списокЧто делать
Любое окружение, где используется pipcertifi, встроенный в pip (сохраняется даже после исправления ОС)Обновите pip до 26.2.2+
Программы, настроенные на отдельный certifi, например requestsОтдельный пакет certifiОбновите certifi до 2026.10.19+
Окружения, использующие uvСписок CA, встроенный в uvОбновите uv до 0.13.4+
conda, Mamba, pixiСами инструменты, а также пакеты certifi и ca-certificatesОбновите conda до 26.9.4+ и pixi до 0.82.1+, а также certifi и ca-certificates в окружении
Python из установщика python.org для macOScertifi, поставляемый с установщикомСледуйте официальному сообщению, чтобы обновить pip и certifi; на 3.13+ перейдите на исправленную версию Python
Образы Docker и CIВерсии pip, certifi и системного набора, существовавшие на момент сборкиПересоберите без кеша
pip или certifi, установленные из пакетов Linux (apt, dnf)Системный ca-certificates (Debian патчит pip для его использования)Обновите ca-certificates до исправленной версии

При прямом использовании urllib3 по умолчанию применяется системное хранилище CA. Обновите его; если ваша конфигурация явно использует certifi или другой набор, обновите и его (руководство urllib3 по проверке сертификатов).

Что произошло (по официальным заявлениям)

Инцидент с промежуточными ключами eMudhra (октябрь 2026)
Сообщение
17 октября 2026 года исследователь безопасности сообщил программам корневых сертификатов Apple, Google, Microsoft и Mozilla, а также eMudhra, что закрытые ключи восьми промежуточных сертификатов eMudhra можно восстановить
Охват
Восемь промежуточных сертификатов. Шесть предназначены для TLS (HTTPS) и были доверенными в Chrome, Mozilla, Microsoft и Apple; два — для подписи кода. Все они созданы в ходе церемонии генерации ключей 30 апреля 2025 года. Шесть TLS-промежуточных сертификатов построены через корень emSign ECC Root CA - G3 (два для подписи кода находятся под другим корнем)
Причина
Google заявляет, что закрытые ключи были сгенерированы с недостаточной случайностью. Mozilla сообщает, что восстановила ключи самостоятельно и подтвердила, что генерация ключей была ошибочной. eMudhra заявляет, что один из шагов церемонии создал второй, слабый набор ключей наряду с сильными, и использовались именно слабые ключи. Полная первопричина всё ещё расследуется
Что позволяют ключи
Mozilla заявляет, что ключи могли использоваться для выпуска поддельных HTTPS-сертификатов для сайтов, которые владелец не контролирует. Злоумышленник, способный перехватить соединение пользователя, мог бы выдать себя за сайты и потенциально прочитать или изменить трафик
Ответ eMudhra
Все восемь отозваны 18 октября. По её словам, семь никогда не использовались в продакшене, а тот, что использовался, не выпустил ни одного сертификата. Выпуск по этому корню остановлен 20 октября, а 22 октября объявлено, что компания уходит с глобального рынка сертификатов SSL/TLS
Браузеры
Chrome заблокировал ключи через CRLSet 17 октября. Firefox заблокировал их в тот же день через OneCRL и выпустил Firefox 158.0.1 и обновления ESR 20 октября. 20 октября Mozilla приняла решение об экстренном удалении корня и исключила его из NSS 3.131.1. Chrome удалит его 27 октября (по тихоокеанскому времени)
Проекты Python
Они опубликовали уведомление 20 октября (обновлено до 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, а также пересобрать образы контейнеров с отключённым кешем слоёв. 21 октября они выпустили Python 3.15.1, 3.14.9 и 3.13.17 со встроенным pip 26.2.2

certifi — широко используемый пакет Python, который содержит список доверенных центров сертификации. Он создан на основе списка Mozilla, а requests и pip используют его, чтобы проверить подлинность сертификата сервера. certifi 2026.10.18 (опубликован 18 октября, UTC) удалил все корни emSign, а 2026.10.19 (опубликован 20 октября, UTC) вернул незатронутые корни emSign. Собственное уведомление certifi отмечает 2026.10.18 как исправленную версию, но запись в GitHub Advisory Database и проекты Python рекомендуют 2026.10.19 или новее для совместимости с незатронутыми корнями emSign. certifi 2026.10.23 затем удалил ещё два корня emSign, следуя Mozilla (eMudhra заявляет, что это удаление было запланировано раньше и не связано с инцидентом).

Насколько это серьёзно?

Chrome, Firefox

Заблокированы 17 октября. Также отклоняют сертификаты, отсутствующие в публичных журналах CT

pip до 26.2.2

Всегда читает встроенный certifi, даже после исправления ОС

requests и другие клиенты на основе certifi

Используют отдельный certifi старше 2026.10.19

uv до 0.13.4, образы Docker

Сохраняют список, собранный на момент сборки

Браузеры защищены автоматическими блокировками. Инструменты Python доверяют поддельным сертификатам, пока не обновятся их собственные списки CA.

Браузеры защищены двумя механизмами: они автоматически получают блокировки сертификатов и отклоняют сертификаты, которых нет в публичных журналах Certificate Transparency (CT). Google сообщает, что до блокировки в журналы CT не было записано ни одного TLS-сертификата, построенного через затронутые промежуточные сертификаты, поэтому поддельный сертификат не мог быть использован против клиентов, которые проверяют CT.

pip и requests не используют ни один из этих механизмов. Они судят только по списку CA, который хранят, поэтому, если этот список устарел, они принимают поддельный сертификат за подлинный.

Что может произойти

  • Злоумышленник на сетевом пути перенаправляет соединения с PyPI, python.org и других сайтов на поддельный сервер
  • pip install устанавливает подменённый пакет
  • Ключи API или пароли, отправляемые через requests, могут быть прочитаны

Что нужно злоумышленнику и что нам известно

  • Злоумышленник должен находиться на вашем сетевом пути (та же Wi-Fi-сеть, скомпрометированный маршрутизатор, корпоративный прокси и т. д.)
  • В самом Python нет ошибки выполнения кода
  • По состоянию на 24 октября эксплуатация не была объявлена

Не расслабляйтесь. Mozilla сообщила 20 октября, что несколько человек независимо восстановили ключи и некоторые публично об этом написали, поэтому создать поддельный сертификат нетрудно. Не запускайте старый pip там, где кто-то может оказаться на вашем пути, например в общественной Wi-Fi, общих сетях или в сети вокруг CI-раннера. Наше руководство по рискам публичного Wi-Fi рассматривает эту сторону вопроса.

Сначала проверьте версии

1

Проверьте версию pip

Выполните команду с тем Python, который хотите проверить (внутри виртуального окружения, если вы его используете). Версия 26.2.2 или новее исправлена.

python -m pip --version

Если запустить просто pip, может открыться pip другого Python. Используйте python -m pip, чтобы точно знать, какой Python вы проверяете.

2

Проверьте версию certifi

Команда показывает отдельный certifi, который используют requests и похожие библиотеки. Версия 2026.10.19 или новее исправлена. Если certifi не установлен, pip выведет предупреждение «not found».

python -m pip show certifi

certifi, встроенный в pip, — это отдельная копия. Выполните python -m pip debug и найдите строку certifi== в разделе «vendored library versions». После обновления до pip 26.2.2 там будет 2026.10.19.

3

Проверьте uv и conda

Выполните uv --version (исправлена версия 0.13.4+), conda --version (26.9.4+) и pixi --version (0.82.1+).

4

Составьте список всех мест установки Python

На одном компьютере часто есть системный Python, Python с python.org, Python из Homebrew или pyenv и виртуальные окружения отдельных проектов (например, .venv). Виртуальное окружение — это любой каталог с файлом pyvenv.cfg. Если сначала записать полный список, будет гораздо труднее что-то пропустить.

Обновление в безопасном порядке

Порядок важен. Старый pip доверяет затронутым сертификатам, поэтому, если он просто загрузит новый pip, а эта загрузка будет перехвачена, может установиться поддельный pip. Проекты Python рекомендуют устанавливать pip с закреплённым хешем файла (отпечатком содержимого) и затем использовать этот pip для всего остального.

1

Обновите pip до 26.2.2 с закреплённым хешем

В официальном сообщении и в блоге Python приведена команда с URL файла pip 26.2.2 и его хешем SHA-256. Её структура такова. Скопируйте URL и хеш точно из официального сообщения (мы намеренно не воспроизводим их здесь).

python -m pip install "pip @ <URL из официального сообщения>#sha256=<хеш из официального сообщения>"

С закреплённым хешем pip отказывается устанавливать файл, содержимое которого отличается, поэтому перехваченная загрузка не сможет установить поддельный pip. В официальном сообщении указано, что браузеры уже должны были обновить свои хранилища и могут использоваться для проверки. Например, откройте страницу файлов pip 26.2.2 на PyPI и убедитесь, что показанный там хеш совпадает.

2

Используйте новый pip, чтобы обновить certifi и uv

Когда у вас pip 26.2.2, с его помощью обновите certifi. Если вы устанавливали uv через pip, обновите его здесь же.

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

Если вы устанавливали uv через его автономный установщик, следуйте уведомлению uv и перейдите на 0.13.4 или новее. В уведомлении сказано, что если вы переключаете uv на системные сертификаты, нужно убедиться, что ОС уже удалила затронутый корень или промежуточные сертификаты.

3

Повторите во всех виртуальных окружениях

pip и certifi находятся внутри каждого виртуального окружения. Проекты Python просят пользователей обновить pip и uv во всех существующих виртуальных окружениях системы. Для старых окружений, которыми вы больше не пользуетесь, быстрее может быть пересоздать их или удалить.

4

Переведите 3.13–3.15 на исправленные релизы; на 3.11 и 3.12 обновляйте pip в каждом новом venv

Python 3.15.1, 3.14.9 и 3.13.17 содержат pip 26.2.2, поэтому новые окружения, созданные через python -m venv, тоже получают исправленный pip.

Проекты Python сообщают, что выпуска 3.11 или 3.12 с более новым pip не будет из-за риска несовместимости. Обновляйте pip первым делом каждый раз, когда создаёте виртуальное окружение. pip 26.2.2 поддерживает Python 3.10 и новее. На 3.9 и более старых версиях исправленный pip недоступен, поэтому обновите сам Python (срок поддержки 3.10 также закончился).

5

Для Python macOS с python.org обновляйте через этот интерпретатор

Python из установщика python.org для macOS включает certifi. В блоге приведены команды для 3.13, 3.14 и 3.15 (в официальном сообщении 3.15 приведён как пример), которые напрямую вызывают этот интерпретатор, например /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15, чтобы обновить pip и certifi. Сборку без GIL (например, python3.15t) обновляйте отдельно. Если pip install --upgrade certifi завершается ошибкой на certifi, поставляемом установщиком, официальное сообщение предлагает переустановить его командой --ignore-installed --no-deps certifi.

Docker, CI и lock-файлы

Именно здесь исправления чаще всего пропускают. Исправление ноутбука ничего не меняет для образов и CI-раннеров, которые хранят старый список, собранный на момент сборки.

1

Пересоберите образы Docker без кеша

Проекты Python просят пересобрать образы контейнеров с отключённым кешем слоёв, чтобы получить актуальные системные сертификаты. Также заново загрузите базовый образ, например командой docker build --pull --no-cache. После пересборки выполните python -m pip --version внутри контейнера, чтобы проверить версию.

21 октября официальные образы Docker обновили определения для 3.13 и новее, перейдя на исправленные релизы Python (3.15.1, 3.14.9 и 3.13.17). Мейнтейнеры образов сообщают, что не будут повышать pip в тегах 3.11 и 3.12, пока Python не выпустит новые релизы. Если вы используете образы 3.11 или 3.12, обновите pip до 26.2.2 в своём Dockerfile с закреплённым хешем.

2

Поднимите закрепления certifi в requirements и lock-файлах

Закрепление вроде certifi==2025.x.x в requirements.txt или constraints.txt возвращает старый certifi. То же относится к uv.lock, poetry.lock, pylock.toml и Pipfile.lock. Поднимите certifi до 2026.10.19 или новее, пересоздайте lock-файл и разверните его в образах и CI.

3

Исключите certifi и pip из карантинов зависимостей

Если вы используете настройку, которая ждёт фиксированный период перед принятием новых версий (карантин зависимостей), исправление не появится до окончания этого периода. Один из сопровождающих пакетов Python предупредил, что пользователи карантина остаются уязвимыми, пока не обновятся. Исключите certifi, pip и uv из этой настройки.

4

Обновите действия и инструменты, которые использует ваш CI

Действие GitHub pypa/gh-action-pypi-publish, которое используется для публикации на PyPI, имеет исправленный релиз v1.14.3. Для cibuildwheel обновите до v4.3.4 или новее (в v4.3.3 появилось исправление; v4.3.4 также охватывает pip на Python 3.9 и других целевых платформах). Проверьте, что конфигурация CI не закрепляет старые версии.

Обратите внимание на копии, перекрёстно подписанные другим CA

У некоторых затронутых промежуточных сертификатов были также копии, перекрёстно подписанные другим центром сертификации. Перекрёстная подпись позволяет доверять одному и тому же промежуточному ключу под другим корнем. Разработчик ядра CPython сообщает, что корень, использованный для перекрёстной подписи, есть в релизах certifi до апреля 2025 года и в старых версиях pip, которые их включают (например, pip 25.0.1 с certifi 2024.8.30). По данным CA, выполнившего перекрёстную подпись, этот корень уже был удалён из хранилищ Chrome и Mozilla, но по состоянию на 18 октября всё ещё оставался доверенным для Microsoft и Apple (запись Mozilla). Debian и Ubuntu 14.04–20.04 (USN-8944-2) также удалили этот корень перекрёстной подписи вместе с корнем emSign. CA, выполнивший перекрёстную подпись, заявляет, что отозвал перекрёстно подписанные копии 19 октября, но большинство клиентов вне браузера отзыв не проверяют. Удаление только корня emSign из старого набора недостаточно, потому что корень перекрёстной подписи останется. Перейдите на certifi 2026.10.19 или новее (в релизах certifi, выпущенных после апреля 2025 года, корня перекрёстной подписи нет).

Обновление системных сертификатов ОС (ca-certificates)

В Linux пакет ca-certificates содержит системный список CA. curl и Python, установленные из пакетов ОС, используют его.

ДистрибутивОфициальное уведомлениеИсправленная версия
Debian 13 (trixie)DSA-6572-1 (20 октября)ca-certificates 20250419+deb13u1
Debian 12 (bookworm)DLA-4845-1ca-certificates 20250419~deb12u2
Ubuntu 26.10, 26.04, 24.04, 22.04USN-8944-1 (20 октября)ca-certificates 20260816ubuntu0.(release)
Ubuntu 20.04, 18.04, 16.04, 14.04USN-8944-2 (20 октября)Предоставляется через Ubuntu Pro (ESM)

Исправление Debian удаляет emSign ECC Root CA - G3 и корень перекрёстной подписи. USN-8944-1 в Ubuntu удаляет emSign ECC Root CA - G3 и на 22.04–26.04 обновляет список до версии 2.90 набора Mozilla; USN-8944-2 удаляет оба корня на 14.04–20.04. pip, установленный из собственного пакета Debian (python3-pip), изменён так, что читает системный список, а не встроенный certifi, поэтому обновление ca-certificates исправляет проблему. В Windows и macOS установите обновления ОС.

Как подтвердить, что всё сделано

1

Проверьте три версии везде

На вашем компьютере, в каждом виртуальном окружении, в каждом образе Docker и в CI убедитесь, что pip 26.2.2+, certifi 2026.10.19+ и uv 0.13.4+. Если остался хотя бы один старый экземпляр, работа не завершена.

2

Убедитесь, что затронутого корня нет в списке certifi

python -m certifi выводит путь к файлу набора certifi. Если в нём больше не встречается имя «emSign ECC Root CA - G3», список исправлен.

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

Результат 0 означает, что корня нет. У certifi, установленного из пакетов Debian или Ubuntu, в файле нет имён сертификатов, поэтому 0 ничего не доказывает; проверьте вместо этого версию ca-certificates. Список в pip исправлен, когда pip имеет версию 26.2.2 или новее.

3

Проверьте закрепления и ОС

Найдите certifi в файлах требований и lock-файлах и убедитесь, что ни одна версия старше 2026.10.19 не закреплена. В Linux убедитесь, что ca-certificates имеет версию не ниже исправленной из таблицы выше, например командой apt policy ca-certificates.

Мнение этого сайта: защита браузеров не защищает всё остальное

Пользователи браузеров были защищены в течение нескольких часов без каких-либо действий, потому что браузеры получают блокировки автоматически и отклоняют сертификаты, которых нет в журналах CT. У pip, requests и образов CI нет ни того, ни другого. Каждый хранит собственную копию списка CA, и владельцу приходится обновлять каждую копию по отдельности. Копий столько же, сколько виртуальных окружений и образов.

Против следующего подобного инцидента также помогает одна привычка: храните хеши пакетов в требованиях (--require-hashes). Если хеши хранятся в ваших собственных файлах, перехваченная загрузка не сможет подменить пакет с другим содержимым. См. аудит зависимостей с OSV-Scanner о закреплении и проверке зависимостей и инцидент с вредоносным ПО LiteLLM 1.107.0 — пример того, как атаковали сам канал распространения.

Для владельцев веб-сайтов

Chrome перестанет доверять emSign ECC Root CA - G3 27 октября (по тихоокеанскому времени). Google просит владельцев сайтов, сертификаты которых построены через этот корень, немедленно получить новый TLS-сертификат из другой иерархии (с другим корнем) в Chrome Root Store. Если вы используете сертификат eMudhra, проверьте рекомендации издателя.

Хронология

  1. 30 апреля 2025 г.

    eMudhra создаёт промежуточные сертификаты, в том числе восемь затронутых, в ходе церемонии генерации ключей.
  2. 17 октября 2026 г.

    Исследователь безопасности сообщает, что восемь ключей можно восстановить. Chrome (CRLSet) и Firefox (OneCRL) блокируют их в тот же день.
  3. 18 октября

    eMudhra отзывает восемь промежуточных сертификатов. certifi 2026.10.18 удаляет все корни emSign.
  4. 19 октября

    CA, выполнивший перекрёстную подпись, отзывает свои перекрёстно подписанные копии.
  5. 20 октября

    Mozilla принимает решение об экстренном удалении корня. Выходят certifi 2026.10.19, pip 26.2.2 и uv 0.13.4, проекты Python публикуют уведомление. Debian и Ubuntu обновляют ca-certificates. Google объявляет, что Chrome удалит корень 27 октября.
  6. 21 октября

    Выходят Python 3.15.1, 3.14.9 и 3.13.17 и conda 26.9.4. Официальные образы Docker переходят на исправленные релизы Python в определениях для 3.13 и новее.
  7. 22 октября

    eMudhra объявляет, что уходит с глобального рынка сертификатов SSL/TLS.
  8. 23 октября

    certifi 2026.10.23 удаляет ещё два корня emSign, следуя Mozilla.

Источники (открытые данные)

Факты в этой статье взяты из следующих открытых источников. Мы не воспроизводим способ восстановления ключей и ничего, что можно использовать для атаки.

  • Проекты Python, «Information for Python users regarding eMudhra / emSign CA certificate security incident» (20 октября 2026 г.; более поздние сообщения проверены до 24 октября) — discuss.python.org
  • Python, «Python 3.15.1, 3.14.9 and 3.13.17 are out» (21 октября 2026 г.) — blog.python.org
  • Уведомление безопасности certifi (GHSA-6q48-6c7w-9gw2) — github.com / GitHub Advisory Database github.com
  • certifi, «Remove emsign» (#437, 18 октября 2026 г.) — 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» (21 октября 2026 г.) — conda.org
  • Google, «Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates» (20 октября 2026 г.) — blog.google
  • Mozilla, «Protecting Firefox users following the compromise of eMudhra intermediate certificates» (20 октября 2026 г.) — blog.mozilla.org
  • Запись Mozilla об инциденте (Bug 2083449: восемь промежуточных сертификатов, время отзыва, удаление корня, перекрёстно подписанные копии) — bugzilla.mozilla.org
  • eMudhra, «eMudhra Statement on Recent Certificate Security Incident» (впервые опубликовано 20 октября, обновлено 22 октября) — emudhra.com
  • eMudhra, «eMudhra to exit global SSL/TLS certificate business» (22 октября 2026 г.) — emudhra.com
  • Публикация об уходе eMudhra (The Record, 22 октября 2026 г.) — therecord.media
  • Debian, «DSA-6572-1 ca-certificates» (20 октября 2026 г.) — lists.debian.org / «DLA-4845-1 ca-certificates» lists.debian.org
  • Ubuntu, «USN-8944-1» и «USN-8944-2» ca-certificates (20 октября 2026 г.) — 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, не принято по состоянию на 24 октября) — github.com
  • Статус версий Python — devguide.python.org

История обновлений

2026-10-24: первая версия на основе уведомления проектов Python от 20 октября и сообщений до 23 октября, релизов Python 3.15.1, 3.14.9 и 3.13.17, уведомлений о certifi, pip и uv, заявлений Google, Mozilla и eMudhra, а также обновлений ca-certificates от Debian и Ubuntu. Мы обновим эту страницу, когда будут решены вопросы по 3.11 и 3.12 и любые дальнейшие изменения в CPython.

Читайте далее

Последние срочные сообщения

FAQ

QЧто произошло?
A

17 октября 2026 года стало известно, что закрытые ключи восьми промежуточных сертификатов индийского центра сертификации eMudhra (шесть для TLS, два для подписи кода) можно было восстановить почти мгновенно из-за ошибки в их генерации в апреле 2025 года. По данным Mozilla и Google, эти ключи позволяют любому создать сертификаты для любого сайта, которые выглядят подлинными для клиентов с устаревшим списком CA. eMudhra отозвала все восемь 18 октября, а 20 октября Mozilla приняла решение об экстренном исключении доверия к родительскому корневому сертификату.

QЭто уязвимость самого Python?
A

Нет. Это не ошибка, которая позволяет выполнить код в CPython. Проблема в том, что списки CA, которым доверяют TLS-клиенты Python (certifi и копия certifi, встроенная в pip), содержали затронутый корневой сертификат. Злоумышленник на сетевом пути, использующий поддельный сертификат, может перенаправить трафик pip install или requests на поддельный сервер. Если загрузка с PyPI будет перехвачена, может быть установлен подменённый пакет, поэтому проекты Python просят пользователей быстро обновиться.

QЕсли я обновлю сертификаты операционной системы, pip будет в безопасности?
A

Нет. По словам разработчика ядра CPython, pip всегда загружает сертификаты из своего встроенного certifi в дополнение к системному хранилищу доверенных сертификатов, и поддерживаемого способа отключить это нет. Любой pip старше 26.2.2 продолжает доверять скомпрометированным промежуточным сертификатам даже после того, как ОС перестала им доверять, поэтому сам pip нужно обновить. Одно исключение: пакет python3-pip в Debian изменён так, что читает системный набор, а не встроенный certifi, поэтому обновление ca-certificates исправляет проблему.

QЯ использую Python 3.11 или 3.12. Что делать?
A

Проекты Python сообщают, что выпуска 3.11 или 3.12 с более новым pip не будет. ensurepip (pip, который устанавливает python -m venv) остаётся старым, поэтому обновляйте pip до 26.2.2 или новее каждый раз, когда создаёте виртуальное окружение. Официальные образы Docker для 3.11 и 3.12 тоже содержат старый pip. Изменение, которое заставит модуль ssl в CPython отклонять скомпрометированные промежуточные ключи, готовится, но по состоянию на 24 октября оно не было принято.

QЭксплуатировалась ли эта уязвимость?
A

По состоянию на 24 октября эксплуатация не была объявлена. Google сообщает, что до блокировки в журналы Certificate Transparency не было записано ни одного TLS-сертификата, построенного через затронутые промежуточные сертификаты. eMudhra заявляет, что ей неизвестны данные о том, что слабые ключи были восстановлены или использованы до раскрытия. Однако Mozilla сообщила 20 октября, что несколько человек независимо восстановили ключи и некоторые публично об этом написали, поэтому необновлённые клиенты вне браузера всё ещё могут стать целью.

QКак понять, что всё сделано?
A

Со стороны Python всё готово, когда каждое окружение (ваш компьютер, каждое виртуальное окружение, каждый образ Docker, CI) имеет pip 26.2.2 или новее, certifi 2026.10.19 или новее и uv 0.13.4 или новее. Также проверьте, что ни один файл требований или lock-файл не закрепляет старую версию certifi, а в Linux ca-certificates имеет исправленную версию. Раздел «Как подтвердить, что всё сделано» ниже перечисляет проверки.