За одну ночь в интернете произошла серия из четырёх инцидентов безопасности. Что должны проверить криптопользователи?

Автор: Клод, TechFlow

TechFlow: Около 21 октября подряд были раскрыты четыре инцидента кибербезопасности: уязвимость удаленного выполнения кода (RCE) в PHP, серия массовых обновлений безопасности Node.js, взлом закрытого ключа индийского центра сертификации eMudhra и подозрение на кражу клиентских ключей на облачной платформе Railway. Эти события затронули четыре технологических слоя: среда выполнения сайтов, фреймворки приложений, цепочка доверия HTTPS и облачное хранилище ключей. Для пользователей криптовалют приватные ключи кошельков не находятся под прямой угрозой от данных уязвимостей, однако все компоненты, окружающие эти ключи — фронтенд-интерфейсы, сервисы узлов, хостинг API и цепочки браузерной верификации — могут быть использованы для фишинга, перехвата транзакций или кражи учетных данных сторонних сервисов.

В период с 21 по 22 октября произошло плотное раскрытие четырех инцидентов разного характера, но с высокой степенью временного совпадения, охвативших почти весь стек технологий — от базовых сред выполнения языков до облачных платформ развертывания. Для большинства криптопользователей их личные приватные ключи и активы в блокчейне напрямую не экспонируются через эти уязвимости. Однако криптопространство никогда не было изолированным: каждый день пользователи открывают фронтенды DApp, подключаются к RPC-узлам и используют биржевые API, которые целиком работают на этой «традиционной» инфраструктуре.

Эта статья не является сборником из четырех отчетов об уязвимостях. При рассмотрении четырех событий вместе они формируют целостную карту атакующих поверхностей: откуда злоумышленники могут приблизиться к вашим активам и что именно вам необходимо проверить.

Два уязвимости PHP со счетом 9.2 уже эксплуатируются при сканировании, первыми страдают фронтенды DApp

21 октября фонд PHP выпустил четыре безопасные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35, в которых исправлены две критические уязвимости удаленного выполнения кода (RCE) со счетом 9.2. Удаленное выполнение кода означает, что злоумышленник может заставить сервер выполнять произвольные команды без предварительного входа в систему, просто отправляя сетевые запросы.

Корни обеих уязвимостей кроются в самом ядре движка PHP: одна связана с управлением памятью (CVE-2026-109618) — при обработке запросов, точно достигающих лимита памяти PHP, в движке могут оставаться неинициализированные данные, которые последующие запросы воспринимают как легитимные, что приводит к повреждению памяти; другая касается обработки ошибок (CVE-2026-109619) — фатальная ошибка в определенный момент времени заставляет внутреннее состояние указывать на уже освобожденную область памяти, в результате чего следующий запрос, обрабатываемый тем же рабочим процессом, может спровоцировать уязвимость «использование после освобождения» (use-after-free), что позволяет выполнить код.

Согласно информации фонда PHP, первые признаки первой уязвимости были выявлены еще во время внешнего аудита в 2024 году, однако команда безопасности несколько месяцев колебалась в выборе подхода к исправлению. Лишь в августе 2026 года исследователь компании Calif Райан А представил полную цепочку эксплуатации для безусловного удаленного выполнения кода, а компания OpenAI независимо сообщила об идентичной корневой причине, после чего приоритет решения проблемы был повышен до максимального.

Наиболее сложным аспектом стало временное окно. Изначально дата публикации планировалась на 22 октября, но во второй половине дня 20 октября два идентификатора CVE просочились на форумы и в социальные сети вместе с неверной оценкой CVSS в 10.0 баллов. Проект PHP был вынужден перенести релиз на день раньше. Одна из отчетных организаций, Calif, ошибочно посчитала информацию распространенной и временно опубликовала видеоролик с демонстрацией эксплойта; после его удаления реплики продолжили циркулировать в соцсетях. 21 октября в 07:41 UTC поставщик контейнерных образов Chainguard в одностороннем порядке нарушил соглашение о конфиденциальности и досрочно выпустил образ с патчем, что позволило злоумышленникам путем сравнения бинарных файлов восстановить метод эксплуатации. В объявлении фонд PHP отметил, что Cloudflare уже зафиксировал фактический трафик сканирования сразу после выпуска патча.

Версии PHP 8.1 и более ранние официально больше не поддерживаются и не получат данное обновление.

Как это связано с пользователями криптовалют? Фронтенды множества DApp, страницы минта NFT и веб-интерфейсы блокчейн-браузеров до сих пор работают на серверах под управлением PHP. Если такие серверы будут скомпрометированы, злоумышленники смогут изменить адреса контрактов, внедренные в страницы, или внедрить вредоносные скрипты. То, что пользователь видит в браузере как «официальную страницу», фактически превратится в фишинговую ловушку. Сам смарт-контракт в блокчейне останется неизменным, но слой интерфейса между пользователем и контрактом может быть заменен.

10 уязвимостей Node.js исправлены в одном обновлении: модуль распаковки и кэш ГПСЧ имеют свои ограничения

В тот же день проект Node.js выпустил обновления безопасности для веток 26.x, 24.x и 22.x, в рамках которых исправлено в общей сложности 10 уязвимостей: 4 критических, 3 значительных и 3 низкого уровня риска.

Наибольшее внимание привлечена уязвимость выхода за пределы буфера в модуле распаковки Brotli (CVE-2026-111497), о которой сообщили специалисты Khai Tran и Sylvie Mayer из команды безопасности OpenAI Codex. Это проблема уровня удаленного выполнения кода. Brotli — широко используемый формат сжатия данных, встроенный в Node.js в качестве декодера. При обработке приложением вредоносных данных, сжатых в Brotli, декодер может осуществлять запись в области памяти за пределами выделенных границ. Для эксплуатации данной уязвимости приложение должно явно обрабатывать входящие данные Brotli, поэтому не все сервисы на Node.js проходят через данный путь исполнения кода.

Другая уязвимость, требующая внимания крипто-разработчиков, касается кэширования генераторов псевдослучайных чисел (CVE-2026-106074, средний уровень риска): функции `crypto.randomUUID()` и `randomInt()` в Node.js при создании стартовых снимков состояния (startup snapshot) и однофайловых исполняемых архивов (SEA) упаковывают кэш энтропии вместе с артефактами, что приводит к тому, что каждый процесс, порожденный из одного и того же снимка, выдает одинаковые значения «случайных» чисел. Эксплуатация возможна только если приложение использует startup snapshot или упаковку SEA, а во время работы опирается на указанные функции для генерации критических случайных чисел. Генерация приватных ключей в большинстве криптокошельков задействует низкоуровневые криптографические API, минуя эти две функции, поэтому утверждения о «полной потере случайности всех кошельков» не имеют оснований. Однако если инструментальное приложение распространяется через SEA и вызывает `randomUUID()` для создания токенов сеанса или временных ключей, возникает риск предсказуемости.

Кроме того, исправлены три уязвимости обхода проверки имени хоста в TLS-сертификатах, позволяющие злоумышленникам проходить валидацию сертификатов с помощью IP-адресов, записанных полноширинными цифрами, или ослабленного резолвинга. Для проектов с собственными RPC-узлами, полагающимися на нативную проверку TLS в Node.js, подобные обходы значительно снижают барьер для организации атаки посредника (Man-in-the-Middle).

Значительная часть инфраструктуры криптоиндустрии построена на базе Node.js: бэкенды бирж, фоновые процессы расширений браузеров для кошельков, сервисы индексации ончейн-данных и различные боты в Telegram и Discord. Условия срабатывания десяти уязвимостей различаются, и не каждая непосредственно угрожает безопасности активов, однако данное обновление охватывает поверхность атаки, включающую парсинг сетевых протоколов, распаковку данных, проверку сертификатов и модель разрешений. Разработчикам необходимо последовательно сверить используемые ими версии Node.js и функциональные модули с перечнем исправлений.

Закрытый ключ промежуточного сертификата eMudhra математически вычислен, Chrome и механизм CT уже заблокировали угрозу

17 октября исследователь кибербезопасности сообщил программе корневых сертификатов Chrome, что закрытые ключи восьми дочерних ЦС (подчиненных центров сертификации) индийской сертификационной компании eMudhra могут быть вычислены из-за недостаточной случайности (слабой криптографической энтропии) при их генерации.

Центы сертификации являются ключевым звеном в цепочке доверия HTTPS. Логика замочка в адресной строке браузера выглядит следующим образом: браузер доверяет набору корневых сертификатов, корневые центры выпускают промежуточные сертификаты, а те, в свою очередь, подписывают TLS-сертификаты сайтов. Получив закрытый ключ промежуточного сертификата, злоумышленник сможет подделать сертификат для любого домена, который браузер будет считать легитимным, полностью обесценивая шифрование и аутентификацию в HTTPS-соединениях.

Согласно сообщению группы безопасности Google от 20 октября, Chrome завершил верификацию примерно за 100 минут после получения уведомления и через обновление CRLSet (список отзыва сертификатов) заблокировал отпечатки открытой информации (SPKI-хеш) скомпрометированных промежуточных ЦС. Такой способ блокировки не требует обновления браузера пользователя или перезагрузки системы. Android-устройства получили аналогичное обновление через Google Play Services ориентировочно в 22:00 UTC в понедельник, 20 октября.

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

В качестве дополнительных мер Google также исключил из магазина корневых сертификатов Chrome корневой сертификат emSign ECC Root CA - G3, подписавший данные промежуточные сертификаты. Ожидается, что изменения вступят в силу для всех устройств, использующих магазин корневых сертификатов Chrome, 27 октября. Аналогичные меры уже приняты Firefox, Apple и Microsoft.

Что нарушение цепочки доверия сертификатов означает для пользователей криптовалют? Наиболее очевидный сценарий — фишинг: злоумышленник создает сайт-клон с полным совпадением доменного имени с реальной биржей или DApp, браузер отображает привычный значок HTTPS-замка, а пользователь без малейшего подозрения вводит логины или подписывает транзакции. Механизм CT Chrome и оперативная реакция предотвратили реализацию подобных атак в данном инциденте, однако устойчивость защиты зависит от обновления браузера и операционной системы. На устройствах с устаревшими системами, не поддерживающими обязательную проверку CT, в течение окна уязвимости действительно сохранялась угроза.

Подозрительный доступ к переменным окружения клиентов Railway: ключи API остаются самым слабым звеном

21 октября платформа облачного развертывания Railway опубликовала сообщение об инциденте безопасности: на платформе была обнаружена аномальная активность. Предварительное расследование показало, что ненадлежащие третьи лица могли получить доступ к системе хранения переменных окружения клиентов, а шифрованный контент некоторых переменных возможно был расшифрован и прочитан. Переменные окружения обычно содержат конфиденциальные данные: ключи API, учетные данные баз данных, сведения об аутентификации для частных реестров контейнеров.

В своем заявлении представители Railway отметили, что полагают этот инцидент частью недавней волны атак на платформенные компании, нацеленных на провайдеров услуг AI-инференса. Компания уже уведомила поставщиков верхнего уровня об обязательном отзыве всех ключей. Одновременно платформа приостановила все процессы сборки и развертывания для проведения внутреннего расследования и обязала всех пользователей немедленно сменить (ротировать) переменные окружения, хранящиеся в Railway.

Согласно обновлению страницы статуса на 15:29 UTC 22 октября, развертывание рабочих пространств Pro и Enterprise возобновилось, однако наблюдается замедление скорости. Функции сборки на тарифных планах Hobby, Free и Trial пока не возвращены.

Портрет пользователей Railway включает значительную долю независимых разработчиков и небольших команд, многие из которых разворачивают на платформе приложения криптоиндустрии: торговые боты, сервисы мониторинга блокчейна, Telegram-боты для уведомлений. В переменных окружения таких приложений часто хранятся ключи API бирж, приватные ключи горячих кошельков для подписи транзакций и токены аутентификации RPC-узлов. Если эти учетные данные были скомпрометированы, злоумышленники могут напрямую инициировать ордера через биржевой API, переводить активы либо использовать токен RPC для отправки вредоносных транзакций.

Формулировка в объявлении Railway гласит «возможный доступ» и «ряд пользователей», полное подтверждение утечки ключей всех клиентов отсутствует. Однако с точки зрения управления рисками любому пользователю, ранее хранившему конфиденциальные учетные данные в переменных окружения на Railway, следует незамедлительно провести ротацию ключей без ожидания целевых уведомлений от платформы.

Здесь важно разделить две вещи: ключи API и пароли баз данных, хранящиеся на облачных платформах, и ончейн-приватные ключи криптокошельков принадлежат к разным уровням безопасности. Ротация биржевого API-ключа или смена пароля БД приводят к немедленной аннуляции старых учетных данных после завершения операции. Однако если кто-то помещает сам приватный ключ кошелька в переменные окружения Railway (подобная практика встречается, особенно в сценариях автоматизированной торговли), то процедура ротации потребует создания нового кошелька и перевода активов: старый адрес, связанный с компрометированным приватным ключом, навсегда останется уязвимым, так как связь между ончейн-адресом и приватным ключом необратима.

Четыре слоя поверхности атаки и единый чек-лист

Рассмотрение всех четырех инцидентов в совокупности охватывает ровно четыре различных уровня, от которых зависят крипто-приложения.

Уязвимости в PHP и Node.js угрожают среде выполнения. Если фронтенды криптопроектов, бэкенд-API или сервисы узлов работают на непопатченных версиях, злоумышленники могут получить контроль над сервером, модифицировать контент для пользователей или украсть данные из памяти сервера. Возможности самих пользователей ограничены, но они могут отслеживать официальные объявления о безопасности проектов, чтобы убедиться в применении обновлений к их инфраструктуре.

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

Инцидент на Railway затрагивает облачное хранение учетных данных. Любые разработчики и команды, размещающие ключи API, пароли баз данных или приватные ключи в переменных окружения на сторонних облачных платформах, должны переоценить свои практики управления секретами. Хранение приватных ключей в открытом виде или с использованием обратимого шифрования на внешних облаках равносильно передаче контроля над безопасностью ончейн-активов непрозрачной операционной среде, которой вы не управляете.

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

Совпадение во времени вспышки четырех инцидентов случайно. Наложение обнаруженных поверхностей атаки — нет.