Ethereum Clients усунули вразливість, яка могла перенаправити нагороди ETH
Оновлення Teku та Besu підкреслюють важливість безпеки зовнішньої інфраструктури
Клієнти консенсусу Ethereum Teku та виконавчий клієнт Besu випустили оновлення безпеки наприкінці жовтня 2026 року, щоб усунути вразливість, пов’язану з компрометованими ключами центру сертифікації індійської компанії eMudhra. Ця вразливість могла дозволити атакуючим, які перехоплювали певні HTTPS-з’єднання, виконувати імітацію зовнішніх сервісів, що використовуються валідаторами, та перенаправляти блокові винагороди або отримувати чутливі підписи. Дослідники виявили, що вісім проміжних центрів сертифікації eMudhra мали приватні ключі, згенеровані з недостатньою випадковістю, що робило ці ключі відновлюваними безпосередньо з публічних сертифікатів. Оскільки середовища виконання Java, що використовуються обоєма клієнтами, за замовчуванням не перевіряють скасування сертифікатів, деякі Docker-образи та встановлення продовжували довіряти ураженим ланцюжкам навіть після того, як браузери та основні операційні системи заблокували їх. Конфігурації за замовчуванням мейннету Teku, які уникав HTTPS-ендпоїнтів, не були вплинутими, а розробники не повідомили про підтверджене зловживання.
Патчі видаляють довіру до залучених коренів із оновлених образів Docker, тоді як оператори, що використовують автономні бінарні файли, повинні окремо вирішити питання своїх локальних сховищ довіри Java. Цей випадок підкреслює, як зовнішні залежності від інфраструктури можуть створювати вузькі, але високопотужні ризики для операцій стейкінгу, навіть коли основний протокол залишається безпечним. Швидка реакція Teku та Besu демонструє, що різноманітність клієнтів Ethereum та проактивні практики безпеки можуть мінімізувати загрози, пов’язані з сертифікатами, перш ніж вони вплинуть на винагороди валідаторів у масштабах, за умови, що оператори застосовують доступні оновлення та перевіряють конфігурації своїх зовнішніх підключень.
Слабка випадковість у проміжних ключах eMudhra призвела до відновлення приватних даних
Дослідники виявили проблему 17 жовтня 2026 року, коли визначили, що приватні ключі восьми проміжних центрів сертифікації eMudhra були згенеровані з надто малою ентропією. Ці ключі були ефективно відновлювані з публічних сертифікатів — ця умова існувала з моменту їх створення на церемонії генерації ключів у квітні 2025 року. Шість проміжних сертифікатів підтримували TLS-з’єднання, а два були пов’язані з підписом коду. Коли приватні дані стали відомими, зловмисник міг видавати шахрайські сертифікати, які програмне забезпечення, що все ще довіряло впливовим центрам сертифікації, приймало як дійсні. eMudhra відкликав проміжні сертифікати 18 жовтня. Основні платформи швидко відреагували: браузери та операційні системи почали блокувати сертифікати між 17 і 20 жовтня, а Microsoft випустив додаткові оновлення Windows та Edge 26–27 жовтня, які видалили пов’язані кореневі сертифікати зі своїх списків довіри. Криптографічна невдача сама по собі не була проблемою протоколу ethereum, але мала значення, бо Teku та Besu використовують перевірку сертифікатів Java для будь-яких HTTPS-з’єднань, які роблять їхні ноди. За замовчуванням Java пропускає перевірку відкликань, що залишало певні встановлення вразливими довше, ніж середовища браузерів. Цей інцидент ілюструє, як одна операційна помилка центру сертифікації може поширитися на спеціалізовану інфраструктуру, що залежить від стандартних TLS-сховищ довіри.
Відновлення ключів не вимагало складного криптоаналізу; недостатня випадковість зробила виведення простим після перевірки публічних сертифікатів. Попередження Microsoft від 26 жовтня підтвердило, що ці ключі можна використовувати для створення сертифікатів, які виглядають як із довірених авторитетів, що потенційно дозволяє імітувати веб-сайти чи сервіси. Для операторів Ethereum практичним наслідком було те, що будь-яка конфігурація валідатора, що використовує HTTPS-ендпоінти, віддалені beacon-ноди, зовнішні підписувачі, блок-будівники чи релей, могла приймати підроблений сертифікат, якщо базова Java-середовище все ще довіряла скомпрометованому ланцюжку. Peer-to-peer-мережа, яку використовують клієнти Ethereum, залишилася незатронутою, оскільки вона не залежить від цих центрів сертифікації. Комбінація відновлюваних ключів і неприпиненого Java-валідаційного механізму створила вікно, в якому атакуючий «посередник» на шляху мережі міг представити клієнтському програмному забезпеченню правдоподібну ідентичність. Команди клієнтів відреагували, вилучивши відповідні кореневі сертифікати зі своїх Docker-образів, а не чекаючи лише оновлень базової Java, щоб забезпечити, що оператори, які завантажують нові образи, отримують захищене сховище довіри. Ця багатошарова відповідь — відкликання на рівні ЦС, блокування на платформному рівні та оновлення клієнтських образів — обмежила практичну поверхню атаки для більшості стейк-конфігурацій.
Як підроблені сертифікати можуть вплинути на поведінку пропозицій блоків і отримувачів комісій
Безпечний бюлетень Teku описав конкретні шляхи атак, які стають можливими, коли атакувальник може представити підроблений сертифікат, який клієнт приймає. Один із сценаріїв передбачає підробку віддаленої beacon-ноди, яку валідатор використовує для координації. Якщо з’єднання перехоплено, а підроблений сертифікат прийнято, валідатор може отримати маніпульовану інформацію щодо блоку, який він готується запропонувати. У цьому випадку клієнт може створити та підписати блок, адреса отримувача комісій якого вказує на акаунт, що контролюється атакувальником, а не на призначену адресу оператора. Комісії за транзакції та будь-які пріоритетні винагороди, включені в блок, потім надходитимуть атакувальнику. У бюлетені також зазначено, що зовнішні сервіси підпису, які зберігають ключі валідатора окремо та повертають підписи за запитом, можуть бути піддані атакам. Атакувальник, який зможе підробити такого підписувача, зможе отримати підписи, використовувані для чутливих операцій, включаючи зміни, що впливають на те, куди спрямовуються винагороди. Teku вважав випадок із зовнішнім підписувачем одним із більш серйозних конфігурацій, хоча взаємна TLS-аутентифікація в деяких налаштуваннях обмежувала б вплив лише до відмови у послузі, а не до компрометації підпису.
Додаткові вразливі типи підключення включають клієнти виконання, будівники блоків, релей та сервіси, які надають дані конфігурації валідаторів. У кожному випадку основний ризик той самий: клієнтське програмне забезпечення вважає підроблений сертифікат дійсним і, отже, приймає дані або інструкції, які змінюють вміст запропонованого блоку або обробку ключів. Уразливість не надає прямого доступу до підписного ключа валідатора при нормальному функціонуванні; замість цього вона підриває цілісність зовнішніх сервісів, до яких звертається валідатор. Оскільки нагороди та комісії Ethereum виплачуються згідно з адресами, вбудованими у запропонований блок, успішна маніпуляція під час пропозиції може перенаправити вартість без необхідності переміщення вже зароблених коштів. Не було повідомлено про жодну експлуатацію цих шляхів, і за замовчуванням встановлені мейннет-версії Teku, які не містять HTTPS-URL-адрес у своїй конфігурації, залишаються поза вразливим набором. Однак детальні сценарії чітко пояснюють, чому команди клієнтів вважали цю проблему настільки серйозною, що вимагали негайного оновлення Docker-образів, навіть хоча сам протокол та шари peer-to-peer залишилися незмінними.
Teku 26.10.3 видаляє скомпрометовані корені з Docker Trust Stores
Teku випустила версію 26.10.3 27 жовтня 2026 року, щоб вирішити проблеми, пов’язані з eMudhra. У примітках до випуску зазначено, що Docker-образи більше не довіряють кореневим сертифікатам emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 або AAA Certificate Services. Ці кореневі сертифікати були видалені OpenJDK після компрометації проміжних авторитетів; базові образи Eclipse Temurin, які використовував Teku, на момент випуску клієнта ще не містили відповідного виправлення. Випустивши оновлені образи, команда Teku забезпечила, що оператори, які завантажують нові теги, отримують середовище виконання Java, чий сховище довіри не містить скомпрометованих даних. У повідомленні, що супроводжує випуск, підкреслюється, що стандартна нода мейннета без налаштованих HTTPS-URL-адрес не потребує жодних дій. Ризик обмежений конфігураціями, які навмисно під’єднуються до віддалених HTTPS-ендпоінтів для координації бейкону, зовнішнього підпису, будівельників або подібних служб.
Оператори, які використовують старі образи Docker, включаючи ті, що позначені до 26.10.2, продовжують використовувати середовище виконання, яке довіряє вплинутим кореневим сертифікатам. Оновлення Java-середовища на хості не оновлює автоматично середовище виконання всередині існуючого контейнера, тому необхідно завантажити новий образ. Teku також зазначила, що Java 26 досягла кінця життєвого циклу і не отримає виправленої збірки; операторам, які ще використовують цю версію, рекомендується перейти на поточну версію з довгостроковою підтримкою — Java 25 — та використовувати відповідні теги образів -jdk25. Тому випуск поєднує видалення кореневих сертифікатів із рекомендаціями щодо управління версіями середовища виконання. Оскільки зміна стосується лише сховищ довіри образів Docker, поведінка консенсусу та обробка ключів валідатора залишаються незмінними. Оновлення подається як рекомендована заходи безпеки, а не як термінове оновлення консенсусу, що відображає обмежений діапазон вплинутих конфігурацій.
Besu 26.10.2 застосовує паралельні налаштування довіри до сертифікатів
Besu, клієнт рівня виконання, що підтримується тією ж ширшою екосистемою, випустив версію 26.10.2 26 жовтня 2026 року, реалізувавши ті самі видалення коренів у своїх Docker-образах. Паралельний час випуску та ідентичні цілі сертифікатів свідчать про спільну свідомість інциденту з eMudhra в стеку Ethereum-клієнтів на основі Java. Клієнти виконання взаємодіють з консенсус-клієнтами та зовнішніми службами для побудови пейлоадів та включення транзакцій; будь-які шляхи HTTPS-зв’язку, які вони підтримують, підлягають тим самим правилам перевірки сертифікатів, що впливають на Teku. Видаливши довіру до скомпрометованих авторитетів зі своїх образів, Besu закриває відповідну поверхню атаки для операторів, які використовують його Docker-розповсюдження.
Як і у випадку з Teku, оновлення Besu не виправляє автоматично окремі бінарні встановлення, які використовують окремо керований середовище Java. Оператори з цієї категорії повинні самостійно перевірити та оновити свої локальні сховища довіри або версії Java. Подвійні випуски клієнтів демонструють, що як консенсусна, так і виконавча частини стеку програмного забезпечення ethereum-ноди визнали спільну залежність від обробки сертифікатів Java. Оскільки багато продакшн-валідаторів запускають як консенсусний клієнт, наприклад Teku, так і виконавчий клієнт, наприклад Besu, одночасні оновлення зменшують ймовірність того, що залишкова довіра до скомпрометованих коренів зберігатиметься на будь-якій стороні пари нод. Відсутність повідомлень про експлуатацію до випусків свідчить про те, що практичний вікно було обмеженим, проте координовані виправлення все ще є розумним підсиленням проти відомої криптографічної невдачі, що знаходиться поза самим протоколом ethereum.
Стандартна відсутність перевірки скасування в Java продовжує витягування вразливості
Центральною технічною деталлю є те, що перевірка сертифікатів Java за замовчуванням не перевіряє статус відкликання. Навіть після того, як eMudhra відкликав проміжні сертифікати, а основні платформи заблокували їх, будь-який середовище виконання Java, яке все ще містило відповідні кореневі або проміжні сертифікати у своєму сховищі довіри, продовжувало приймати сертифікати, що утворюють ланцюг до цих авторитетів. OpenJDK випустив виправлення, які спочатку заблокували скомпрометовані проміжні сертифікати, а потім видалили чотири пов’язаних кореневих сертифікати. Однак образи Docker, що містили старі версії Temurin або OpenJDK, не отримували цих виправлень автоматично. Ця розбіжність між відкликанням на рівні платформи та поведінкою вбудованих середовищ виконання Java і є тим, що зумовило необхідність оновлення клієнтських образів.
Для операторів Ethereum наслідки є операційними, а не теоретичними. Валідатор, конфігурація якого містить HTTPS-ендпоінти для зовнішніх служб, успадковує рішення про довіру Java-середовища, яке використовується. Якщо це середовище не було оновлено або замінено на виправлену версію, клієнт залишається здатним приймати підроблений сертифікат. Взаємний TLS або прив’язані сертифікати можуть зменшити ризик у добре спроектованих конфігураціях, але багато виробничих конфігурацій залежать від стандартної перевірки сховища довіри. Випуски Teku та Besu тому слугують практичним нагадуванням про те, що контейнеризоване програмне забезпечення ноди має власне сховище сертифікатів, незалежне від хост-системи. Оператори, які сприймають Docker-образи як непрозорі чорні скриньки, можуть не звертати уваги на цей нюанс, доки зовнішній інцидент не змусить оновити їх. Цей випадок також підкреслює важливість моніторингу оголошень про безпеку Java від постачальників під час використання Ethereum-клієнтів на основі Java.
Стандартні конфігурації мейннету уникнули основної поверхні атаки
Рекомендації Teku чітко вказують, що нода мейннету за замовчуванням, у конфігурації якої немає HTTPS-URL, не піддається впливу і не вимагає дій. Більшість валідаторів, які запускають локальні, розташовані разом клієнти консенсусу та виконання, без віддаленого підписування чи віддалених beacon-ендпоінтів, входять до цієї категорії. Протоколи peer-to-peer виявлення та gossip, які використовуються Ethereum, не залежать від сертифікаційних центрів eMudhra, що додатково захищає стандартні налаштування. Ризик зосереджений серед операторів, які свідомо ввели зовнішні HTTPS-залежності для зручності функціонування, географічного розподілу ключів підпису або інтеграції з сторонніми сервісами побудови блоків. Ця розбіжність важлива для оцінки загального впливу на мережу. Оскільки більшість валідаторів мейннету працюють у конфігураціях, які ніколи не зверталися до вразливих ланцюгів сертифікатів, теоретична поверхня атаки залишалася обмеженою навіть до застосування патчів.
Рішення команд клієнтів все ж таки впровадити оновлені зображення захищає підмножину операторів, які використовують віддалені сервіси, і забезпечує, що майбутні завантаження зображень починаються з захищеної базової конфігурації. Конфігурації тестнету, які завантажують початковий стан через HTTPS, були позначені як потенційно вразливі, що ілюструє, що та сама логіка сертифікатів застосовується поза мейннетом. Оператори будь-якої мережі, які залежать від HTTPS-запуску або віддалених точок доступу, повинні вважати випуски жовтня 2026 року обов’язковими для своїх середовищ. Чітке розділення між стандартними та нестандартними конфігураціями дозволило зробити попередження одночасно точним і впевненим для більшості валідаторів.
Зовнішні підписувачі та віддалені ноди beacon представляли найвищі ризикові шляхи
Серед сценаріїв, перерахованих Teku, зовнішні сервіси підпису мали підвищену серйозність. Ці сервіси зберігають приватні ключі валідатора оффлайн або у спеціалізованому обладнанні та відповідають на запити на підпис через мережеве з’єднання. Якщо зловмисник може видаєти себе за підписувача, представивши підроблений сертифікат, клієнт валідатора може прийняти підписи, які авторизують операції, які оператор ніколи не планував, включаючи ті, що змінюють налаштування отримувача комісій або ініціюють вихід. Конфігурації, які вимагають взаємної аутентифікації TLS, зменшують вплив до відмови у наданні послуг, оскільки зловмисник не може завершити аутентифікований рукостискання. Де взаємна аутентифікація відсутня, ризик отримання придатних підписів вищий. Віддалені beacon-ноди викликають пов’язану, але відмінну проблему.
Валідатор, який делегує певні координаційні обов’язки віддаленому beacon-ендпоінту, довіряє цьому ендпоінту інформацією про обов’язки, вміст блоків та стан мережі. Успішна імітація може впливати на блок, який валідатор у кінцевому підсумку пропонує, включаючи адресу отримувача комісій, вбудовану в цей блок. Будівельники та реле блоків додають ще інші HTTPS-поверхні, через які можуть бути введено маніпульовані дані. У кожному випадку атакувач спочатку повинен зайняти мережеву позицію, що дозволяє перехоплювати трафік, а потім представити сертифікат, який приймає незапatchений Java-середовище. Комбінація вимог звужує набір реальних противників, проте потенційний дохід — перенаправлення комісій від успішного пропонування — оправдує заходи по захисту. Оператори, які підтримують зовнішні підписувачі або віддалену інфраструктуру, повинні пріоритизувати оновлення клієнтів та перевірку механізмів автентифікації на цих з’єднаннях.
Оператори, які використовують самостійні бінарні файли, мають окремі зобов’язання щодо оновлення Java
Користувачі Docker можуть виправити ситуацію, завантаживши нові образи Teku 26.10.3 або Besu 26.10.2. Оператори, які встановлюють клієнти як окремі бінарні файли або пакети, залежать від середовища виконання Java, наявного на хост-системі. Для таких встановлень самі релізи клієнтів не змінюють довірений сховище хоста. Тому оператори повинні переконатися, що встановлена версія Java містить виправлення OpenJDK, які видаляють скомпрометовані кореневі сертифікати, або вручну налаштувати сховище сертифікатів. Teku особливо попередив, що Java 26 має закінчення підтримки і не отримає виправленої збірки; для продовження підтримки та оновлень безпеки необхідно перейти на Java 25. Таке розходження між контейнеризованими та bare-metal розгортаннями є поширеним у інфраструктурі ethereum і створює практичний пункт для перевірки операторами нод.
Інвентаризація версій Java, підтвердження вмісту trust-store та перевірка, що жодні HTTPS-ендпоінти не вказують на ненадійні сервіси, становлять мінімальну гігієну після застосування патчів. Оскільки базова криптографічна несправність відбулася поза ethereum, ті ж самі обов’язки оновлення Java стосуються будь-яких інших інструментів на основі Java, які може використовувати оператор. Тому рекомендації клієнтів слугують як конкретним виправленням для Teku та Besu, так і загальним закликом до аудиту обробки сертифікатів у всьому стеку оператора. Невиправлення середовища Java залишає теоретичні шляхи атаки відкритими навіть після оновлення самого клієнтського програмного забезпечення.
Не відбулося підтвердженої експлуатації до впровадження виправлень
Як консультація Teku, так і сучасні звіти стверджують, що експлуатація вразливості не була спостерігана. Відсутність відомих інцидентів узгоджується з вузьким набором умов, необхідних для успішної атаки: незапatchений середовище виконання Java, HTTPS-з’єднання з зовнішнім сервісом та атакуючий, здатний перехопити саме це з’єднання, представляючи підроблений сертифікат. Більшість валідаторів ніколи не задовольняли одночасно перші дві умови. Короткий інтервал між публічним розголошенням відновлених ключів 17 жовтня та випуском образів клієнта додатково скоротив практичний вікно.
Відсутність зафіксованих атак не зменшує цінність патчів. Уразливості, пов’язані з сертифікатами, можуть залишатися неактивними до тих пір, поки не з’явиться випадковий противник. Вилучивши скомпрометовані кореневі сертифікати з довірених сховищ Docker, команди клієнтів усунули прийняття підроблених сертифікатів для операторів, які оновлюються. Цей випадок також надав живе демонстрування того, як зовнішні криптографічні невдачі можуть перетинатися з інфраструктурою стейкінгу Ethereum, змушуючи операторів перевірити свої власні графи залежностей. Майбутні інциденти, пов’язані з центрами сертифікації або середовищами виконання мов, ймовірно, спричинять подібні реакції на рівні клієнтів, що підсилює модель швидкого та цілеспрямованого усунення.
Як ризики безпеки сертифікатів поширюються на мережі блокчейн
Інцидент з eMudhra не є унікальним для ethereum; будь-яке програмне забезпечення, яке залежить від стандартних схем довіри TLS, успадковує рівень безпеки центрів сертифікації, яким воно довіряє. Клієнти блокчейну, які вбудовують мовні середовища виконання, такі як Java, Go або інші, повинні стежити за оновленнями сертифікатів з того ж рівнем уваги, з яким вони стежать за змінами консенсусу. Той факт, що за замовчуванням Java не перевіряє скасування сертифікатів, посилив вплив і змусив команди клієнтів впроваджувати власні модифікації схем довіри. Інші екосистеми, які пакують довгоживучі середовища виконання всередині контейнерів, стикаються з аналогічними ризиками.
Для спільноти Ethereum стейкінгу практичний урок полягає в тому, що операційна безпека поширюється далі за керування ключами та версіями клієнтів і включає поведінку перевірки сертифікатів кожного мережевого компонента. Оператори, які використовують віддалене підписання, розподілені beacon-ноди або сторонні релейні сервіси, вводять додаткові межі довіри, які потрібно моніторити. Успішне виявлення цього конкретного вразливого місця за допомогою відкликання ЦС, блокування платформ та оновлень образів клієнтів показує, що шарована захистна система може працювати, якщо кожен шар реагує оперативно. Продовження різноманітності клієнтів залишається цінним, оскільки різні реалізації можуть виявляти або зменшувати зовнішні залежності з різною швидкістю, зменшуючи ймовірність того, що одна невдача сертифіката вплине на весь набір валідаторів одночасно.
Останні занепокоєння щодо інфраструктури валідаторів підкреслюють необхідність постійної уваги
Сертифікати жовтня 2026 року були випущені на тлі іншої уваги до безпеки, пов’язаної з валідаторами. Раніше розголошення, що стосувалися інфраструктури стейкінг-сервісів та обробки отримувачів комісій, вже спричинили масштабні добровільні виходи та посилене моніторинг виплат нагород. Окремо розробники виправили проблему з маршрутизацією депозитів у проекті правил для майбутнього оновлення Glamsterdam, яка могла призводити до неправильного призначення стейкінг-депозитів за певних колізій публічних ключів; цей виправлення було об’єднано з конкретикаціями консенсусу після додаткового огляду. Ці одночасні події ілюструють, що економіка валідаторів та операційна безпека залишаються активними областями уваги, навіть коли основний протокол продовжує розвиватися.
Дефект сертифіката мав інше походження: він виник через зовнішній ЦС, а не через помилку в специфікації або консенсусі ethereum, проте він торкнувся тієї ж економічної поверхні: отримувача комісій і нагород, зароблених пропозерами. Швидка реакція клієнтів тому відповідає загальному патерну, коли будь-який реалістичний шлях перенаправлення нагород розглядається як високопріоритетний. Оператори, які підтримують різноманітні конфігурації клієнтів, моніторять адреси отримувачів комісій у ланцюжку та підтримують у актуальному стані як консенсусний, так і виконавчий програмний код, краще підготовлені до поглинання таких зовнішніх шоків. Відсутність втрат у випадку eMudhra підтверджує, що своєчасне застосування виправлень і дисципліна конфігурування залишаються ефективними засобами захисту.
Що повинні зробити оператори нод ethereum після випусків у жовтні
Валідатори та оператори нод повинні підтвердити, що використовують Teku 26.10.3 або новішу версію та Besu 26.10.2 або новішу версію при використанні Docker, або відповідний виправлений Java-рантайм при використанні бінарних файлів. Конфігурації слід перевірити на наявність HTTPS-ендпоінтів; якщо такі ендпоінти необхідні, взаємний TLS або прив’язка сертифіката забезпечують додатковий захист. Оператори, які ще використовують Java 26, повинні перейти на підтримувану версію. Моніторинг запропонованих блоків на наявність неочікуваних адрес отримувачів комісій залишається низьковитратним методом виявлення навіть після оновлення trust-store. Оскільки базові ключі були відновлювані протягом тривалого періоду до виявлення, одноразовий аудит історичних з’єднань та журналів прийняття сертифікатів може надати додаткову впевненість, хоча жодних випадків експлуатації не було повідомлено.
Ці кроки є поступовими, а не трансформаційними для більшості операторів. Більшість валідаторів мейннету ніколи не зверталися до вразливих ланцюгів сертифікатів, тому інцидент відчувся лише як нагадування про необхідність підтримувати образи контейнерів та Java-середовища в актуальному стані. Для тих, хто залежить від зовнішніх служб, виправлення закривають конкретний, раніше недооцінений шлях. Підтримка свідомості щодо оголошень про сертифікати та середовища вищого рівня зменшить ймовірність того, що подібні зовнішні відмови створять подібні вікна у майбутньому. Скоординовані дії команд Teku та Besu забезпечують як негайне виправлення, так і модель для реагування на наступний зовнішній криптографічний інцидент, що перетинається з програмним забезпеченням клієнтів ethereum.
ЧАСТІ ПИТАННЯ
Що саме було не так з сертифікатами eMudhra?
Вісім проміжних центрів сертифікації, що діють через eMudhra, мали приватні ключі, згенеровані з недостатньою випадковістю під час церемонії ключів у 2025 році. Ці ключі можна було відновити з публічних сертифікатів, що дозволяло будь-кому, хто їх отримав, видавати шахрайські сертифікати, які програмне забезпечення все ще вважало б довіреними цими авторитетами. Шість проміжних сертифікатів використовувалися для TLS, а два — для підпису коду. eMudhra відкликав їх після виявлення 17 жовтня 2026 року, і основні платформи пізніше заблокували відповідний матеріал.
Чи втратили якісь валідатори нагороди ETH через цей недолік?
Не повідомлялося про підтверджені експлуатації або втрату нагород. Рекомендації для клієнтів та сучасні матеріали стверджують, що атак не спостерігалося. Комбінація необхідних умов — незапatchений середовище Java плюс активне HTTPS-з’єднання з вразливим зовнішнім сервісом — обмежила реальний поверх атаки, а швидке видання виправлених Docker-образів дало додаткове зменшення вразливості.
Чи постраждали вузли мейннету Ethereum за замовчуванням?
За замовчуванням конфігурації мейннет Teku, які не містять HTTPS-URL, не стосуються і не вимагають дій. Той самий принцип застосовується до порівнянних налаштувань Besu. Вразливість обмежена операторами, які свідомо налаштовують віддалені HTTPS-ендпоінти для біконод, зовнішніх підписувачів, будівників або подібних сервісів.
Чому Java-середовища виконання залишилися вразливими після відкликання сертифікатів?
Java за замовчуванням не перевіряє статус відкликання сертифікатів. Навіть після відкликання та блокування проміжних сертифікатів браузерами та операційними системами, будь-яка установка Java, яка все ще містила відповідні кореневі сертифікати у своєму сховищі довіри, продовжувала приймати сертифікати, що утворювали ланцюжок з них. Клієнтські Docker-образи, що містили старіші середовища виконання, тому потребували явного видалення кореневих сертифікатів.
Що повинні робити оператори, які використовують образи Docker?
Завантажте та запустіть Teku версії 26.10.3 або новішої та Besu версії 26.10.2 або новішої. Ці образи більше не довіряють скомпрометованим кореневим сертифікатам. Оновлення лише хост-системи не оновлює середовище виконання в існуючому контейнері; потрібен новий образ.
Як щодо операторів, які запускають клієнти як автономні бінарні файли?
Ці оператори повинні оновити або переналаштувати встановлення Java на хості, щоб включити виправлення OpenJDK та видалити уразливі корені. Java 26 має закінчення підтримки і не отримає виправленої збірки; рекомендується міграція на Java 25. Оновлення клієнтського програмного забезпечення самі по собі не змінюють довірений сховище хоста.
Відмова від відповідальності: Ця загальна інформація про ринок, можливо, з третіх сторін, комерційних або спонсорованих джерел, надається виключно для довідкових та освітніх цілей і не є фінансовою або інвестиційною порадою, пропозицією, запрошенням або гарантією. Ми відмовляємося від відповідальності за його точність, повноту, надійність та будь-які зумовлені ним збитки. Інвестування/торгівля супроводжуються ризиком; минулі результати не гарантують майбутніх. Користувачі повинні проводити дослідження, обережно оцінювати ризики та брати повну відповідальність. Для отримання додаткової інформації будь ласка, ознайомтеся з Умовами використання та Заявою про ризики KuCoin.
Відмова від відповідальності: Для вашої зручності цю сторінку було перекладено за допомогою технології ШІ. Для отримання найточнішої інформації дивіться оригінальну англійську версію.