Если у тебя есть VPS, компрометация промежуточных CA eMudhra (CVE-2026-111943) - это случай, где фикс не сводится к одному пакету, который ты обновил и забыл. Приватные ключи восьми промежуточных Certificate Authorities, выпущенных eMudhra, были скомпрометированы, и последствия размазаны по нескольким независимым слоям: Go runtime, Docker Engine, системный ca-certificates store и CLI-клиенты, которые их читают. Каждый вендор выпустил фикс по своему графику, поэтому по-настоящему запропатченная машина - та, где каждый чек ниже даёт чистый результат. Эта статья проходит по клиентской стороне аудита: что именно было скомпрометировано, какая версия нужна каждому инструменту и какие точные команды подтверждают, что твоя машина больше не доверяет затронутым цепочкам.[1][2][3]

Что именно было скомпрометировано

17 октября 2026 исследователь безопасности сообщил, что приватные ключи восьми промежуточных сертификатов CA eMudhra восстанавливаемы - ключи настолько слабые, что их можно воспроизвести из публичных сертификатов меньше чем за секунду.[4][5] eMudhra отозвал все восемь 18 октября с причиной caCompromise, а кроссигнатувщий CA отозвал свои копии 19 октября.[5][6] Поскольку любой, у кого есть такой ключ, в принципе может выпустить сертификат для любого домена, затронутые цепочки пришлось вычистить из доверия везде, где на них полагались. Восемь скомпрометированных промежуточных сертификатов:[2][3]

  • EM DV TLS CA - G3B и EM DV TLS CA - G3C (domain-validated TLS)
  • EM OV TLS CA - G3B и EM OV TLS CA - G3C (organization-validated TLS)
  • EM EV TLS CA - G3B и EM EV TLS CA - G3C (extended-validation TLS)
  • EM OV CS CA - G3B и EM OV CS CA - G3C (code signing)

Промежуточные G3B принадлежат eMudhra BV, G3C - eMudhra Inc. Ключи были сгенерированы в ходе key-generation церемонии в апреле 2025, а затронутые корни включают emSign Root TLS CA - G3, emSign ECC Root CA - G3 и кроссигнатурный путь Comodo AAA Certificate Services.[3][6]

Практическая поверхность поражения - всё, что доверяет этим промежуточным. Браузеры и ОС, которые пушат блок-листы в реальном времени (CRLSets в Chrome, OneCRL в Firefox), обновились быстро и в основном самовосстановились. Но CLI-инструменты и софт, который поставляется со своим собственным CA-бандлом - прежде всего всё, что собрано на Go crypto/x509, - перестают доверять скомпрометированным ключам только после обновления софта,[4] и именно этот разрыв - предмет этой статьи.

Почему это определяется версией твоего тулчейна

Ключевая особенность этого инцидента в том, что Go реализует собственную X.509-верификацию цепочек в стандартной библиотеке, а не полагается целиком на динамические системные библиотеки.[4] Поэтому фикс для Go-софта - это не новый root bundle в /etc/ssl, а новый Go runtime с зашитой в него денлист-таблицей этих конкретных промежуточных. Go-команда добавила ровно это: crypto/x509 теперь отфильтровывает любую цепочку, содержащую subject public key info (SPKI) восьми скомпрометированных сертификатов, и возвращает ошибку из Verify.[1][7]

Это закрывает проблему для всего, что собрано на фикс-версии Go, но означает, что тебе нужно следить за двумя механизмами, которые пересекаются между собой:

  • Версия Go runtime для всего, что скомпилировано на Go (Docker Engine, Terraform, Prometheus, Kubernetes-тулинг и любые Go-бинарники, которые ты собираешь сам) - фикс в Go 1.26.10 и Go 1.27.3.[1][7][8]
  • Системный trust store (/etc/ssl/certs, пакет ca-certificates) для всего, что читает корни ОС - фикс дистрибутивными обновлениями от Ubuntu, Red Hat и других.[9][10][11]

Машина может быть запропатчена по одной оси и оставаться сломанной по другой. Чек-лист ниже покрывает обе.

Чек 1: системный trust store

Начни со слоя, который читает большинство клиентов независимо от собственной криптографии: OS-бандл. Там, где дистрибутив поставляет фикс ca-certificates, затронутые корни удаляются из store напрямую, так что цепочка сертификатов, которая полагалась на один из них, больше не доверяется.[9][11]

Ubuntu. Security-команда Ubuntu выпустила фикс-версии ca-certificates, которые убирают корни emSign Root TLS CA - G3 и Comodo AAA Certificate Services из доверенного store. Тот же анонс закрывает и библиотеку NSS (libnss3), у которой своя копия store, поэтому обновляй оба пакета одной командой. Проверь, что стоит у тебя, затем обнови, если старая версия:[9]

apt-cache policy ca-certificates
sudo apt update && sudo apt install --only-upgrade ca-certificates 'libnss3*'

Во всех поддерживаемых релизах Ubuntu фикс есть со следующих версий: Jammy (22.04) 20260816ubuntu0.22.04.1, Noble (24.04) 20260816ubuntu0.24.04.1, Resolute (26.04) 20260816ubuntu0.26.04.1 и Stonking (26.10) 20260816ubuntu0.26.10.1.[9]

Red Hat / RHEL. Red Hat отслеживает это как RHSB-2026-012. Их бюллетень прямо говорит, что во все поддерживаемые major-версии RHEL (с 6 по 10) скомпрометированные сертификаты попали в trust store через ca-certificates, и что пакет производный от Mozilla store. Проверь установленную версию, затем обнови, когда выйдет фикс:[10]

rpm -q ca-certificates
sudo dnf update ca-certificates

Debian. Для системного store подтяни обновление ca-certificates через apt той же командой. (Запись в трекере Debian по CVE-2026-111943 разрешает пакеты Golang; обновление store идёт обычным путём.)[7]

Однако одного этого чека мало - именно Go runtime денлист защищает Go-клиентов, и он не зависит от /etc/ssl.

Чек 2: Go runtime на хосте и в твоих бинарниках

Если ты запускаешь или собираешь что-то на Go - а на дев-грейд VPS это обычно так, будь то Docker Engine, деплой-инструмент или сервер приложения - решение о доверии принимается внутри crypto/x509 по денлисту, зашитому в runtime, а не по системному бандлу. Фикс-версии - Go 1.26.10 и Go 1.27.3.[1][7][8] Проверь тулчейн, который реально используешь:

go version
go version /usr/local/bin/some-go-binary

Вторая форма показывает, на какой версии Go собран конкретный бинарник, - это быстрый способ засечь забытый Go-инструмент: если там что-то старее 1.26.10 (или 1.27.3), такой бинарник будет спокойно доверять скомпрометированным промежуточным при следующем HTTPS-вызове. Пересобери или обнови такой бинарник, прежде чем на него полагаться.

Чек 3: Docker Engine и пуллы/пуши реестров

Docker Engine - самая заметная Go-жертва здесь. Релиз 29.9.2 (20 октября 2026) несёт Go 1.26.10 и стал первым Engine, который отклоняет цепочки сертификатов, содержащие любой из восьми скомпрометированных промежуточных.[2][3] До 29.9.2 Engine ещё принимал цепочку, пересекающую затронутые eMudhra-промежуточные, так что атакующий с одним из ключей в принципе мог перехватить docker pull или docker push к затронутому реестру. Именно этот риск закрывает релиз.

Проверь версию Engine:[2][3]

docker version --format '{{.Server.Version}} {{.Server.Os}}/{{.Server.Arch}}'
docker version --format '{{.Client.Version}}'

И сервер (демон dockerd), и CLI должны быть 29.9.2 или новее. Операции image pull / image push падают на TLS-верификации, если цепочка реестра опирается на один из затронутых промежуточных, - это ожидаемое защитное поведение, а не баг,[2] так что чистый пулл из нормального реестра - ровно то, что нужно. (Это клиентская/реестровая сторона; поведение демона на pull и push под 29.9.2 подробно описано в change log Engine и release notes Docker.[2][12])

Чек 4: curl и CLI HTTP-клиенты

curl - клиент, который читает системный бандл, так что управляется Чеком 1, - но тестировать его стоит отдельно, потому что curl часто молча гоняют в автоматизации и health-check’ах. Важны две вещи поверх обновления store:

  • Собственный CA bundle curl. Проекты, которые поставляют свой собственный CA-файл, выпустили обновлённые бандлы (обновление curl CA bundle датировано 20 октября 2026).[4] Если твоя сборка или оверрайд в стиле HOMEBREW_CURL_CA_BUNDLE указывает на зафиксированный cert.pem, который всё ещё содержит старые корни, обновление store на хосте не поможет.
  • Живой end-to-end тест. Сообщество поддерживает тестовые эндпоинты, которые отдают leaf-сертификат, привязанный к каждому скомпрометированному промежуточному. Наведение curl на один из них должно дать ошибку сертификата, если клиент больше не доверяет цепочке:[4]
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/

Ошибка верификации сертификата здесь означает, что твой curl и store корректно отклоняют скомпрометированную цепочку. Этот эндпоинт - проверка от сообщества, а не вендорский источник, так что относись к результату как к быстрому сигналу, а не определению фикса, - реальные ворота это версионные чеки выше.

Чек 5: git over HTTPS

Git по HTTPS использует TLS-доверие транспорта, которое в Linux означает системный store (снова Чек 1) - Git сам не поставляет свой CA-бандл. Так что конкретные действия такие:

  1. Обнови ca-certificates (Чек 1), чтобы GIT_SSL_VERIFY проверял по store, который больше не доверяет затронутым корням.
  2. Если ты полагаешься на какой-то промежуточный бокс или прокси, который терминирует TLS цепочкой, пересекавшей eMudhra-промежуточный, замени эту цепочку, а не отключай верификацию.

Особый случай macOS заслуживает предупреждения: командные инструменты Apple, включая поставляемые с ней git и curl, верифицируют по /etc/ssl/cert.pem, не сверяясь с блок-листами отзыва Apple, и сообщения сообщества указывают, что инструменты разработчика, поставляемые с macOS, доверяли скомпрометированным сертификатам даже после того, как системная ревокация вступила в силу.[4] Если ты админишь build-машины на macOS, не предполагай, что store обновился, - протестируй эндпоинт из Чека 4 явно.

Порядок, который реально закрывает дыру

Поскольку фикс разнесён между runtime денлистом и системным store, машина запропатчена только тогда, когда истинно всё из следующего:

  1. ca-certificates - фикс-версия твоего дистрибутива, чтобы не-Go клиенты перестали доверять затронутым корням.
  2. Твой Go-тулчейн - 1.26.10 / 1.27.3 или новее, чтобы Go-собранные тулы отклоняли скомпрометированные промежуточные на уровне runtime.
  3. Docker Engine server и CLI - 29.9.2 или новее, чтобы пуллы и пуши реестров применяли отклонение.
  4. Собственный bundle curl (там, где он переопределён) - бандл от 20 октября 2026 или новее.
  5. Живой тест против скомпрометированной цепочки выдаёт ошибку сертификата, а не успешное подключение.

Прогони версионные чеки, примени обновления, перепрогони их и проверь, что тестовый эндпоинт теперь падает. Только тогда машина на клиентской стороне этого инцидента действительно чиста - обновление одного слоя, пока другой всё ещё доверяет скомпрометированным ключам, оставляет ровно тот разрыв, ради которого эта CVE и существует.

Источники

  1. Golang - issue 82345, “crypto/x509: mitigation for security concerns with a specific Certificate Authority” (CVE-2026-111943; денлист добавлен в crypto/x509; фикс в Go 1.26.10 и 1.27.3; бэкпорты #82348 для 1.26 и #82349 для 1.27). https://go.dev/issue/82345 - checked 2026-11-02
  2. Docker Engine - release notes версии 29, секция 29.9.2 (20.10.2026; обновление Go runtime до 1.26.10 отклоняет цепочки с восемью отозванными eMudhra-промежуточными; image pull и push падают на TLS-верификации для затронутых цепочек; перечисляет все восемь промежуточных и разделение G3B/G3C по вендорам). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-02
  3. moby/moby - release v29.9.2 (20.10.2026; тот же security-текст: Go 1.26.10, восемь eMudhra-промежуточных заблокированы, ссылки обновления packaging). https://github.com/moby/moby/releases/tag/docker-v29.9.2 - checked 2026-11-02
  4. Talos Intelligence - “Compromised eMudhra intermediate certificates” (вторичный анализ компрометации и клиентской поверхности фикса; тайминг curl/CA-bundle; тестовые эндпоинты сообщества; оговорка про macOS developer tools; НЕ первичный источник факта по самой CVE). https://blog.talosintelligence.com/compromised-intermediate-certificates - checked 2026-11-02
  5. Mozilla Bugzilla - bug 2083449, “eMudhra: Private key compromise of Intermediate Certificates” (доклад исследователя 17.10.2026; eMudhra отозвал восемь сертификатов с причиной caCompromise 18.10.2026; таймлайн ревокации CRLSets). https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 - checked 2026-11-02
  6. AWS Security Bulletin 2026-150 - “CVE-2026-111943: eMudhra intermediate CA key recovery in AWS trust bundles” (восемь промежуточных ключей восстановимы из-за маленьких целочисленных скаляров; шесть TLS и два code-signing промежуточных; выпускающий CA отозвал 18 октября, кроссигнатувщий - 19 октября; перечислены затронутые корни). https://aws.amazon.com/security/security-bulletins/2026-150-aws/ - checked 2026-11-02
  7. Debian Security Tracker - CVE-2026-111943 (golang-1.26 fixed в 1.26.10-1, golang-1.27 fixed в 1.27.3-1; golang-1.19/1.24 в trixie нерешённое no-dsa minor). https://security-tracker.debian.org/tracker/CVE-2026-111943 - checked 2026-11-02
  8. Ubuntu - security tracker CVE-2026-111943 (статусы пакета golang по Noble/Jammy/Resolute; перекрёстные ссылки на go.dev issue 82345). https://ubuntu.com/security/CVE-2026-111943 - checked 2026-11-02
  9. Ubuntu blog - “eMudhra CA compromise fixes available” (ca-certificates удалил корни emSign Root TLS CA - G3 и Comodo AAA Certificate Services из доверенного store; тот же анонс закрывает libnss3, у которого свой store; фикс-версии по релизам: Jammy 20260816ubuntu0.22.04.1, Noble 20260816ubuntu0.24.04.1, Resolute 20260816ubuntu0.26.04.1, Stonking 20260816ubuntu0.26.10.1; команды обновления). https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available - checked 2026-11-02
  10. Red Hat - RHSB-2026-012, “Certificate compromise - eMudhra (CVE-2026-111943)” (пакет ca-certificates производный от Mozilla store; RHEL 6-10 несли скомпрометированные сертификаты; проверка rpm -q ca-certificates; обновление, когда выйдет фикс). https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 - checked 2026-11-02
  11. Google Cloud - GKE security bulletin по CVE-2026-111943 (идёт через Ubuntu-ноды ca-certificates и патчи Go runtime; внешний TLS от containerd и control-plane полагается на системные или Go root store; внутренний mTLS не затронут). https://docs.cloud.google.com/kubernetes-engine/security-bulletins - checked 2026-11-02
  12. Docker Engine - release notes версии 29, секция 29.9.1 (daemon-side фиксы containerd и линия релиза, на которую ссылается 29.9.2). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-02