Стежити Інцидент великої інфраструктури публічних ключів спонукав до запуску аварійних заходів безпеки у всіх браузерах, екосистемах мов програмування, сховищах сертифікатів та пакетах програмного забезпечення. Приватні ключі, пов’язані з вісьмома проміжними сертифікатами органу сертифікації eMudhra, були скомпрометовані, що потенційно дозволяє неавторизованим сторонам створювати сертифікати, які можуть здаватися надійними вразливим клієнтам.
Інцидент впливає на шість проміжних TLS, що використовуються для сертифікатів з перевіркою домену, організації та розширеною перевіркою, разом з двома проміжними сертифікатами для підпису коду. Оскільки проміжний сертифікаційний орган може видавати сертифікати нижче довіреного кореня, володіння його приватним ключем створює значно вищий ризик, ніж компрометація звичайного сертифіката вебсайту. Атакуючий може потенційно створити підроблені сертифікати, які успадковують довіру від ураженого ланцюжка.
Проект Go відповів, вказавши CVE-2026-111943, що вирішує випадки, коли програми Go могли продовжувати довіряти ланцюжкам сертифікатів, що містять скомпрометовані проміжні сертифікати. Go 1.26.10 та 1.27.3 додають список заборон у crypto/x509, змушуючи перевірку сертифікатів збоїти, коли один з відомих недовірених проміжних ключів з’являється в ланцюжку.
Команди безпеки, що шукають можливості виявлення CVE-2026-111943, повинні дивитися за рамки звичайної телеметрії експлуатації вразливостей. Цей інцидент стосується основної довіри до сертифікатів, отже, захисники повинні моніторити ланцюжки сертифікатів TLS, несподіваних видавників сертифікатів, збої у валідації сертифікатів, підозрілі зашифровані сесії і програмне забезпечення, що підтримує власний набір сертифікатів, а не спирається на швидко оновлювані механізми відкликання браузера.
AI-Native Detection Intelligence Platform від SOC Prime дозволяє командам безпеки зміцнювати видимість нових загроз шляхом використання постійно оновлюваного вмісту виявлення в різних технологіях SIEM, EDR і Data Lake. Натисніть Досліджувати Виявлення щоб отримати доступ до відповідного вмісту виявлення та логіки полювання для нових поведінок атак.
Фахівці з безпеки також можуть використовувати Prime Architect, щоб перетворити нову інформацію про загрози та індикатори у запити полювання та логіку виявлення, допомагаючи командам виявляти можливості вразливості, пов’язані з CVE-2026-111943, та розслідувати підозрілу діяльність з сертифікатами у своїх середовищах.
Зв’язатися з відділом продажів
Аналіз CVE-2026-111943
Інцидент розпочався 17 жовтня 2026 року, коли дослідник безпеки виявив криптографічну слабкість, що вплинула на вісім проміжних сертифікатів, керованих eMudhra в рамках його інфраструктури сертифікаційного органу emSign. Дослідник продемонстрував володіння відповідними приватними ключами, подавши дійсні підписані засвідчення всіх восьми сертифікатів в програми кореневих браузерів та eMudhra.
Пізніше Mozilla підтвердила компрометацію та, що важливо, повідомила, що її інженери змогли самостійно відновити постраждалі приватні ключі, не отримавши деталей про метод дослідника. Mozilla зробила висновок, що основний процес генерації ключів був помилковим і простим для експлуатації.
Уражені сертифікаційні органи включали:
- EM DV TLS CA – G3B
- EM DV TLS CA – G3C
- EM OV TLS CA – G3B
- EM OV TLS CA – G3C
- EM EV TLS CA – G3B
- EM EV TLS CA – G3C
- EM OV CS CA – G3B
- EM OV CS CA – G3C
Перші шість є проміжними TLS, здатними брати участь у ланцюжках сертифікатів, що використовуються для аутентифікації сайтів. Решта два – проміжні для підпису коду. Сертифікати G3B асоціювалися з eMudhra BV у Нідерландах, в той час як сертифікати G3C асоціювалися з eMudhra Inc. у Сполучених Штатах.
Імплікації безпеки значні. Будь-хто, хто зможе вивести або іншим чином отримати приватний ключ проміжного CA, міг би потенційно видавати сертифікати нижче цього проміжного, не проходячи через процес легітимної видачі сертифікатів. У контексті TLS підроблені сертифікати можуть бути використані для видачі себе за домени, якщо атакуючий також зміг би перехопити або перенаправити з’єднання жертви.
Mozilla зазначила, що такий атакуючий потенційно може видати себе за веб-сайти та читати або змінювати трафік, коли він здатен перехоплювати з’єднання. Це робить проблему особливо актуальною для сценаріїв «порушених середовищ», скомпрометованої мережевої інфраструктури, шкідливих проксі або маніпуляцій DNS та маршрутизації.
Однак наявні докази не демонструють широкомасштабного зловживання підробленими сертифікатами TLS до захисної відповіді. Згідно із знахідками Chrome Root Program, цитованими у The Hacker News, жодної ланцюжка сертифікатів TLS до шести уражених проміжних серверів сайту не з’являлося в журналах Прозорості Сертифікатів до того, як Chrome заблокував ключі. Оскільки Chrome та інші браузери, що вимагають журналістики CT, зазвичай відхиляли б не зареєстрований публічно довірений сертифікат, це значно обмежувало можливості недетектованого публічного злоупотребления TLS через цих клієнтів.
Chrome отримала звіт о 18:05 UTC 17 жовтня і розгорнула блок CRLSet для шести проміжних TLS до 19:45 UTC. Mozilla отримала звіт пізно ввечері і поширила блок OneCRL на стандартні конфігурації Firefox до 22:59 UTC. Таким чином, користувачі Firefox, які отримували Remote Settings, отримали захист без необхідності вручну оновлювати чи перезапускати браузер.
Ситуація з PoC CVE-2026-111943 є незвичною, тому що це не традиційна вразливість пам’яті або віддаленого виконання коду з експлоїт-кодом. Натомість дослідник надав криптографічний доказ контролю над усіма вісьмома приватними ключами, а Mozilla самостійно відтворила відновлення ключів, ефективно демонструючи, що криптографічний збій міг бути експлуатований.
Сам CVE був призначений Проектом Go. Він описує більш вузьку проблему, що стосується валідації сертифікатів у стандартній бібліотеці Go. На більшості платформ Go спирається на системні кореневі сховища сертифікатів. Але системи, де відповідна конфігурація довіри не була швидко оновлена, могли б продовжувати приймати ланцюжки через проміжні, які більше не є надійними.
Щоб закрити це розходження, Проект Go додав явний список заборон у crypto/x509. Оновлена верифікаційна логіка повертає помилку щоразу, коли ланцюг сертифікатів містить один із скомпрометованих проміжних відкритих ключів.
CVE-2026-111943 впливає на версії стандартної бібліотеки Go перед 1.26.10 та гілку Go 1.27 до версії 1.27.3. Додатки, що були побудовані з використанням уражених версій, можуть потребувати перевипуску з виправленим релізом Go, щоб отримати новий захист.
Деталі щодо CVE-2026-111943 особливо важливі для власників додатків, оскільки виправлення в браузерах автоматично не захищають кожну програму, яка виконує валідацію TLS. Багато додатків використовують мовно-специфічні або вбудовані сховища сертифікатів і можуть не споживати системи відкликання браузера, такі як Chrome CRLSet або Mozilla OneCRL.
The Hacker News повідомляє, що ця відмінність спричинила оновлення в різних екосистемах. Go додав явне блокування, Mozilla оновила NSS, сертифікатний пакет certifi для Python видалив уражений корінь, і екосистема webpki-roots для Rust випустила оновлення. RustSec окремо ідентифікує версію 1.0.10 або новіше як таку, що має патч для ураженої пакету веб PKI root.
IOC (індикатори компрометації) для CVE-2026-111943 тому в основному орієнтовані на сертифікати, а не на традиційні малварні індикатори, такі як IP-адреси, домени або хеш файлів. Організації повинні зосередити увагу на восьми уражених проміжних ідентифікаторах сертифікатів і публічних хешах ключів, що використовуються Go та іншими постачальниками, щоб явно блокувати ці ключі. Телеметрія ланцюга сертифікатів, що показує один з цих проміжних, має вважатися недовіреною та має бути досліджена.
Пом’якшення CVE-2026-111943
Найважливіше вирішення для середовищ Go – це оновлення до Go 1.26.10, Go 1.27.3 або пізнішого підтримуваного випуску та перевипуск додатків, що залежать від валідації сертифікатів TLS Go. Просто оновлення інструментарію Go на сервері розробки не змінює вже скомпільовані бінарні файли на стадії; уражені додатки потрібно перевипустити і знову розгорнути з патченою стандартною бібліотекою.
Організації також повинні інвентаризувати додатки, що підтримують незалежні сховища CA або пакети сертифікатів. Браузери, такі як Chrome і Firefox, швидко реагували централізованими механізмами відкликання, але командні утиліти, серверні додатки, контейнери, агенти, вбудовані пристрої та мовні рантайми можуть залежати від інших джерел сертифікатів.
Користувачі Firefox з нормальними конфігураціями отримали блок OneCRL автоматично 17 жовтня. Mozilla також випустила Firefox 158.0.1, Firefox ESR 115.43.1 і Firefox ESR 153.5.1, щоб надати оновлений список блокувань користувачам, чиї політики або мережеві середовища перешкоджали нормальному функціонуванню налаштувань віддаленого управління. Mozilla також випустила NSS 3.131.1 зі змінами у наборі довірених сертифікатів.
Команди безпеки повинні:
- Оновити додатки Go і перевипустити уражені бінарні файли.
- Оновити системні пакети CA та мовні конфігурації довіри.
- Переконатися, що механізми скасування сертифікатів браузера та операційної системи працюють.
- Блокувати або не довіряти вісім скомпрометованих проміжних сертифікатічних ключів.
- Ідентифікувати внутрішні додатки з вбудованими або статично упакованими складами сертифікатів.
- Інспектувати телеметрію TLS для ланцюгів сертифікатів, що містять уражені проміжні.
- Перевипустити легітимні сертифікати, якщо існуючі сервіси залежать від ланцюгів сертифікатів, які зараз є недовіреними.
- Тестувати критичні сервіси після оновлень кореневих сховищ, оскільки видалення кореневого CA також може порушити легітимні сервіси, які раніше використовували такий ланцюг.
Команди повинні також звертати особливу увагу на довготривале програмне забезпечення, контейнери, внутрішні інструменти для розробки та непідтримуване програмне забезпечення. Ці системи можуть продовжувати довіряти старим наборам сертифікатів довго після того, як основні браузери заблокували скомпрометований CA.
Видалення кореневого сертифікату може мати операційні наслідки. Легітимні сертифікати, що використовують той кореневий, можуть припинити валідацію, навіть якщо ці окремі сертифікати ніколи не були скомпрометовані. З цієї причини організації повинні поєднувати швидке видалення довіри з виявленням залежностей і заміною сертифікатів, а не припускати, що видалення з довірчого сховища не вплине на доступність.
Команди SOC можуть зміцнити свою захисну поставу, корелюючи збої валідації сертифікатів, телеметрію перехоплення TLS, незвичайну активність DNS, несподівану поведінку проксі і зміни видавця сертифікатів. Атакуючий зазвичай вимагатиме якогось механізму для направлення або перехоплення трафіку, перш ніж підроблений сертифікат TLS стане корисним, тому аномалії сертифікатів слід розслідувати разом із доказами на мережевому рівні.
FAQ
Що таке CVE-2026-111943 і як це працює?
CVE-2026-111943 – це проблема безпеки, відстежувана Проектом Go в пакеті перевірки сертифікатів crypto/x509 після компрометації восьми проміжних приватних ключів CA eMudhra. Скомпрометовані ключі потенційно можуть бути використані для створення сертифікатів, закріплених через уражені проміжні. Додатки Go, що спираються на сховища сертифікатів, які ще не видалили або не відкликали ці проміжні, могли продовжувати приймати такі ланцюжки. Go вирішила ризик, додавши явний список заборон, що викликає збої у перевірці сертифікатів, коли зустрічається один із відомих скомпрометованих проміжних ключів.
Коли CVE-2026-111943 було вперше виявлено?
Компрометація ключів eMudhra була виявлена 17 жовтня 2026 року. За хронологією інциденту Mozilla, дослідник Уейн виявив криптографічний збій того дня і повідомив про проблему, разом з доказом контролю за приватними ключами, програмам коренів браузерів та eMudhra. Chrome та Mozilla перевірили результати протягом годин і почали блокувати уражені проміжні. CVE-2026-111943 було згодом опубліковано Проектом Go як частина відповіді на залишковий ризик довіри до сертифікатів.
Який вплив CVE-2026-111943 на системи?
Основний ризик полягає у неналежній довірі до ланцюгів сертифікатів, що включають скомпрометовані проміжні ключі CA. Для TLS володіння проміжним приватним ключем CA потенційно могло дозволити видачі підроблених сертифікатів для веб-сайтів, які атакуючий не контролює. Якщо атакуючий може перехопити або перенаправити мережевий трафік і програмне забезпечення жертви все ще довіряє ураженій ланцюжку сертифікатів, це може полегшити видачу за веб-сайти і потенційно дозволити спостереження або зміну зашифрованих комунікацій. Компрометація також включала два проміжних ключі підпису коду, розширюючи занепокоєння за межі автентифікації веб-сайтів на экосистеми довіри програмного забезпечення, що приймають ланцюжки через ці проміжні.
Чи може CVE-2026-111943 все ще вплинути на мене в 2026 році?
Так. Вразливість залишається можливою для програмного забезпечення, яке не отримало оновленої інформації про не довіру до сертифікатів. Стандартні установки Chrome і Firefox отримали швидкий захист, але додатки Go, скомпільовані з вразливими версіями стандартної бібліотеки, додатки, що використовують застарілі незалежні пакети CA, непідтримуване програмне забезпечення, вбудовані системи або середовища, де механізми відкликання сертифікатів вимкнені, можуть продовжувати довіряти скомпрометованим шляхам сертифікатів. Тому організації не повинні припускати, що оновлення лише їх веб-браузерів усуває ризик.
Як я можу захиститися від CVE-2026-111943?
Оновіть до Go 1.26.10, Go 1.27.3 або новіше та перевипустить уражені додатки Go. Оновіть сховища довіри операційної системи та додатків, версії браузерів, мовні пакети сертифікатів та інше програмне забезпечення, що виконує валідацію TLS. Організації також повинні перевірити, що вісім скомпрометованих проміжників більше не знаходяться у довірі, інспектувати телеметрію ланцюгів сертифікатів на їх наявність та ідентифікувати додатки, що містять статичні або вбудовані пакети CA. Якщо існуючі сервіси в даний час залежать від ланцюгів, постраждалих від екстрених дій недовіри, замініть ці сертифікати на ланцюги, закріплені в недоторканих сертифікаційних органах.
