Клиенты Ethereum устранили уязвимость, которая могла перенаправить награды ETH
Обновления Teku и Besu подчеркивают важность безопасности внешней инфраструктуры
Клиенты консенсуса Ethereum Teku и исполнения Besu выпустили обновления безопасности в конце октября 2026 года для устранения уязвимости, связанной с компрометированными ключами центров сертификации индийской компании eMudhra. Эта уязвимость могла позволить злоумышленникам, перехватившим определённые HTTPS-соединения, выдавать себя за внешние сервисы, используемые валидаторами, и перенаправлять блок-вознаграждения или получать чувствительные подписи. Исследователи обнаружили, что восемь промежуточных центров сертификации eMudhra сгенерировали закрытые ключи с недостаточной случайностью, что сделало эти ключи восстанавливаемыми непосредственно из публичных сертификатов. Поскольку среды выполнения Java, используемые обоими клиентами, по умолчанию не проверяют отзыв сертификатов, некоторые Docker-образы и установки продолжали доверять затронутым цепочкам даже после того, как браузеры и основные операционные системы заблокировали их. Конфигурации Teku по умолчанию для мейннета, избегавшие HTTPS-эндпоинтов, не были затронуты, и разработчики не сообщили о подтверждённых случаях эксплуатации.
Патчи удаляют доверие к затронутым корневым сертификатам из обновленных образов Docker, в то время как операторы, использующие автономные бинарные файлы, должны отдельно обновить свои локальные хранилища доверенных сертификатов Java. Этот инцидент подчеркивает, как внешние зависимости от инфраструктуры могут создавать узкие, но высокоimpact-риски для операций стейкинга, даже когда основной протокол остается безопасным. Быстрая реакция 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-эндпоинты, удаленные бейкон-ноды, внешние сабмиттеры, блок-билдеры или реле, могла принять поддельный сертификат, если базовая среда выполнения Java по-прежнему доверяла скомпрометированной цепочке. Сетевое взаимодействие типа «точка-точка», используемое клиентами Ethereum, осталось не затронутым, поскольку оно не зависит от этих центров сертификации. Сочетание восстанавливаемых ключей и непрекращающейся проверки Java создало окно, в течение которого атакующий «человек посередине», находящийся на сетевом пути, мог представить клиентскому программному обеспечению правдоподобную идентичность. Команды клиентов ответили, удалив соответствующие корневые сертификаты из своих Docker-образов, а не ожидая исключительно обновлений базовой Java, обеспечив тем самым операторам, получающим свежие образы, укрепленное хранилище доверия. Этот многоуровневый подход — отзыв на уровне ЦС, блокировки на платформе и обновления образов клиентов — ограничил практическую поверхность атаки для большинства стейкинг-конфигураций.
Как поддельные сертификаты могут изменить поведение при предложении блоков и получателей комиссий
Рекомендация по безопасности Teku описала конкретные сценарии атак, которые становятся возможными, когда злоумышленник может представить поддельный сертификат, принимаемый клиентом. Один из сценариев предполагает подмену удаленной beacon-ноды, которую валидатор использует для координации. Если соединение перехвачено, а поддельный сертификат принят, валидатор может получить манипулированную информацию о блоке, который он готовит к предложению. В этом случае клиент может сформировать и подписать блок, адрес получателя комиссий которого указывает на аккаунт, контролируемый злоумышленником, а не на назначенную адресную точку оператора. Комиссии за транзакции и любые приоритетные чаевые, включенные в блок, затем будут направлены злоумышленнику. В рекомендации также рассматривались внешние сервисы подписи, которые хранят ключи валидатора отдельно и возвращают подписи по запросу. Злоумышленник, способный подменить такой подписывающий сервис, может получить подписи, используемые для чувствительных операций, включая изменения, влияющие на направление вознаграждений. Teku отнесла случай с внешним подписывающим сервисом к числу более серьезных конфигураций, хотя взаимная аутентификация TLS в некоторых настройках ограничивает последствия отказом в обслуживании, а не компрометацией подписей.
Дополнительные типы подключений, которые могут быть подвержены уязвимости, включают клиенты исполнения, строителей блоков, реле и сервисы, предоставляющие данные конфигурации валидаторов. Во всех случаях основной риск один и тот же: клиентское программное обеспечение воспринимает поддельный сертификат как легитимный и, соответственно, принимает данные или инструкции, изменяющие содержимое предлагаемого блока или обработку ключей. Уязвимость не предоставляет прямого доступа к ключу подписи валидатора при нормальной работе; вместо этого она подрывает целостность внешних сервисов, к которым обращается валидатор. Поскольку вознаграждения и комиссии Ethereum выплачиваются в соответствии с адресами, встроенными в предлагаемый блок, успешная манипуляция на этапе предложения может перенаправить стоимость без необходимости перемещения уже заработанных средств. Эксплуатация этих путей не была зафиксирована, и стандартные установки Teku на мейннете, не содержащие HTTPS-URL в своей конфигурации, не попадают в группу затронутых. Тем не менее, подробные сценарии ясно показывают, почему команды клиентов сочли необходимым немедленно обновить Docker-образы, несмотря на то, что сам протокол и уровни peer-to-peer остались нетронутыми.
Teku 26.10.3 удаляет скомпрометированные корневые сертификаты из хранилищ доверия Docker
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 при использовании Java-основанных клиентов Ethereum.
Стандартные конфигурации мейннета избегали основной поверхности атаки
Рекомендация Teku четко указывает, что стандартная нода мейннета, в конфигурации которой отсутствуют HTTPS-URL, не затронута и не требует никаких действий. Большинство валидаторов, запущенных локально с совмещенными консенсусным и исполнительным клиентами, без удаленного подписания или удаленных beacon-эндпоинтов, попадают в эту категорию. Пир-ту-пир-обнаружение и протоколы gossip, используемые Ethereum, не зависят от центров сертификации eMudhra, что дополнительно защищает стандартные настройки. Риск сосредоточен среди операторов, которые намеренно ввели внешние HTTPS-зависимости для удобства эксплуатации, географического распределения ключей подписи или интеграции со сторонними сервисами по созданию блоков. Это различие важно для оценки общего воздействия на сеть. Поскольку большинство валидаторов мейннета работают в конфигурациях, которые никогда не обращались к уязвимым цепочкам сертификатов, теоретическая поверхность атаки оставалась ограниченной даже до применения исправлений.
Решение команд клиентов опубликовать обновленные образы, несмотря ни на что, защищает подмножество операторов, использующих удаленные сервисы, и гарантирует, что будущие загрузки образов будут начинаться с защищенной базовой конфигурации. Конфигурации тестнета, загружающие начальное состояние по HTTPS, были отмечены как потенциально уязвимые, что демонстрирует применение одной и той же логики сертификатов за пределами мейннета. Операторы любой сети, полагающиеся на HTTPS-загрузку или удаленные конечные точки, должны рассматривать релизы октября 2026 года как обязательные для своих сред. Четкое разделение между стандартной и нестандартной конфигурациями позволило сделать рекомендацию одновременно точной и успокаивающей для большинства валидаторов.
Внешние подписывающие устройства и удаленные ноды маяка представляли наибольшие рисковые пути
Среди сценариев, перечисленных Teku, услуги внешней подписи обладали повышенной степенью серьезности. Эти службы хранят закрытые ключи валидатора в оффлайн-режиме или на специализированном оборудовании и отвечают на запросы на подпись через сетевое соединение. Если злоумышленник сможет выдать себя за подписывающую сторону, представив поддельный сертификат, клиент валидатора может принять подписи, авторизующие операции, которые оператор никогда не планировал выполнять, включая изменения настроек получателя комиссий или инициацию выхода. Конфигурации, требующие взаимной аутентификации TLS, снижают воздействие до отказа в обслуживании, поскольку злоумышленник не может завершить аутентифицированный handshake. В отсутствие взаимной аутентификации риск получения пригодных для использования подписей выше. Удаленные ноды маяка представляют связанную, но отличную проблему.
Валидатор, передающий определенные координационные обязанности удалённой точке 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 staking практический урок заключается в том, что операционная безопасность распространяется далее управления ключами и версиями клиентов и включает поведение проверки сертификатов каждого сетевого компонента. Операторы, использующие удалённую подпись, распределённые beacon-ноды или сторонние реле, вводят дополнительные границы доверия, которые необходимо отслеживать. Успешное сдерживание этой конкретной уязвимости благодаря отзыву ЦС, блокировкам на платформах и обновлениям образов клиентов показывает, что многоуровневая защита может работать, если каждый уровень реагирует оперативно. Сохранение разнообразия клиентов остаётся ценным, поскольку различные реализации могут по-разному быстро выявлять или смягчать внешние зависимости, снижая вероятность того, что сбой одного сертификата повлияет на весь набор валидаторов одновременно.
Недавние проблемы в инфраструктуре валидаторов подчеркивают необходимость постоянной бдительности
Сертификаты октября 2026 года были выпущены на фоне повышенного внимания к вопросам безопасности, связанным с валидаторами. Ранее опубликованные данные, касающиеся инфраструктуры сервисов стейкинга и обработки получателей комиссий, уже спровоцировали массовый добровольный выход и усиленный мониторинг потоков вознаграждений. Отдельно разработчики устранили проблему с маршрутизацией депозитов в проекте правил для предстоящего апгрейда Glamsterdam, которая могла привести к неправильному назначению стейкинг-депозитов при определенных коллизиях публичных ключей; это исправление было включено в спецификации консенсуса после дополнительного рассмотрения. Эти одновременные события демонстрируют, что экономика валидаторов и операционная безопасность остаются активными областями внимания, даже несмотря на то, что основной протокол продолжает развиваться.
Ошибки в сертификате имели различное происхождение: они возникли из-за внешнего ЦС, а не из-за ошибки в спецификации Ethereum или консенсуса клиента, однако затронули ту же экономическую сферу: получателей комиссий и вознаграждений, заработанных предлагателями. Быстрая реакция клиентов соответствует более широкой тенденции рассматривать любой реалистичный путь перенаправления вознаграждений как приоритетную задачу. Операторы, которые поддерживают диверсифицированные клиентские настройки, отслеживают адреса получателей комиссий в цепочке и поддерживают в актуальном состоянии как консенсусное, так и исполнительное программное обеспечение, лучше подготовлены к поглощению таких внешних шоков. Отсутствие потерь в случае eMudhra подтверждает, что своевременное применение исправлений и дисциплина в настройке остаются эффективными мерами защиты.
Что должны сделать операторы нод ethereum после выпусков в октябре
Валидаторы и операторы нод должны подтвердить, что используют Teku 26.10.3 или более позднюю версию и Besu 26.10.2 или более позднюю версию при использовании Docker, или эквивалентную исправленную среду выполнения Java при использовании бинарных файлов. Конфигурации следует проверить на наличие HTTPS-эндпоинтов; если такие эндпоинты необходимы, взаимный TLS или привязка сертификата обеспечивают дополнительную защиту. Операторы, использующие Java 26, должны перейти на поддерживаемую версию. Мониторинг предложенных блоков на неожиданные адреса получателей комиссий остается низкозатратным методом обнаружения даже после обновления хранилища доверенных сертификатов. Поскольку базовые ключи были доступны для восстановления в течение длительного периода до обнаружения, однократный аудит исторических подключений и журналов принятия сертификатов может обеспечить дополнительную уверенность, хотя эксплуатация не была зафиксирована.
Эти шаги носят постепенный, а не трансформационный характер для большинства операторов. Большинство валидаторов мейннета никогда не взаимодействовали с уязвимыми цепочками сертификатов и поэтому воспринимают инцидент как напоминание о необходимости поддержания актуальности образов контейнеров и сред выполнения Java. Для тех, кто зависит от внешних сервисов, патчи закрывают конкретный и ранее недооцениваемый путь. Поддержание осведомленности о рекомендациях по сертификатам и средам выполнения верхнего уровня снизит вероятность того, что подобные внешние сбои создадут аналогичные уязвимости в будущем. Скоординированные действия команд Teku и Besu обеспечивают как немедленное исправление, так и модель для реагирования на следующий внешний криптографический инцидент, связанный с программным обеспечением клиентов ethereum.
ЧаВо
Что именно было не так с сертификатами eMudhra?
Восемь промежуточных центров сертификации, управляемых eMudhra, имели закрытые ключи, сгенерированные с недостаточной случайностью во время церемонии генерации ключей в 2025 году. Эти ключи можно было восстановить из публичных сертификатов, что позволяло любому, кто их получил, выдавать фальшивые сертификаты, которые программы по-прежнему доверяли бы этим центрам. Шесть промежуточных центров использовались для TLS, а два — для подписи кода. eMudhra отозвала их после обнаружения 17 октября 2026 года, и основные платформы впоследствии заблокировали соответствующие материалы.
Потеряли ли какие-либо валидаторы награды в ETH из-за этого недостатка?
Подтвержденных эксплуатаций или потерь вознаграждений не сообщалось. Рекомендации для клиентов и соответствующие материалы указывают, что атаки не наблюдались. Сочетание необходимых условий — незапatchenая среда выполнения Java плюс активное HTTPS-соединение с уязвимым внешним сервисом — ограничивало реальную поверхность атаки, а быстрое выпуск исправленных Docker-образов дополнительно снизил уровень экспозиции.
Затронуты ли по умолчанию ноды ethereum мейннета?
Стандартные конфигурации мейннета Teku, не содержащие HTTPS-URL, не затронуты и не требуют действий. Тот же принцип применяется к аналогичным настройкам Besu. Уязвимость ограничивается операторами, которые намеренно настраивают удаленные HTTPS-эндпоинты для beacon-нод, внешних подписчиков, билдеров или аналогичных сервисов.
Почему среды выполнения Java остались уязвимыми после отзыва сертификатов?
Java по умолчанию не проверяет статус отзыва сертификатов. Даже после отзыва и блокировки промежуточных сертификатов браузерами и операционными системами, любая установка Java, содержащая соответствующие корневые сертификаты в своем хранилище доверия, продолжала принимать сертификаты, цепочки которых вели к ним. Клиентские Docker-образы, поставлявшиеся со старыми средами выполнения, поэтому требовали явного удаления корневых сертификатов.
Что должны делать операторы, использующие образы Docker?
Загрузите и запустите Teku версии 26.10.3 или более поздней и Besu версии 26.10.2 или более поздней. Эти образы больше не доверяют скомпрометированным корневым сертификатам. Обновление только хост-системы не обновляет среду выполнения внутри существующего контейнера; требуется новый образ.
А как насчёт операторов, запускающих клиенты в виде отдельных исполняемых файлов?
Эти операторы должны обновить или переkonфигурировать установку Java на хосте, чтобы включить исправления OpenJDK и удалить затронутые корни. Java 26 имеет ограниченную поддержку и не получит исправленную сборку; рекомендуется перейти на Java 25. Само обновление клиентского программного обеспечения не изменяет хранилище доверенных сертификатов хоста.
Отказ от ответственности: Данная общая информация о рынке, возможно, из сторонних, коммерческих или спонсорских источников, предоставлена исключительно в справочных и образовательных целях и не является финансовой или инвестиционной консультацией, предложением, запросом или гарантией. Мы отказываемся от ответственности за ее точность, полноту, надежность и любые возникшие потери. Инвестиции/торговля сопряжены с риском; прошлые результаты не гарантируют будущих. Пользователи должны проводить собственное исследование, принимать взвешенные решения и нести полную ответственность. Для получения дополнительной информации обратитесь к Условиям использования и Раскрытию рисков KuCoin.
Отказ от ответственности: Эта страница была переведена для вашего удобства с использованием технологии искусственного интеллекта. Для получения наиболее точной информации обратитесь к оригинальной английской версии.