Критические уязвимости PHP уровня интернета: как устранить слабое место Web3 вне блокчейна?

Оригинальное название: «PHP получил критические уязвимости „интернет-уровня“: как закрыть „офчейн-слабость“ Web3?»
Автор оригинала: команда безопасности SlowMist

Что произошло

21 октября проект PHP выпустил экстренное обновление безопасности, исправляющее две критические уязвимости — CVE-2026-109618 и CVE-2026-109619, которые могут привести к удалённому выполнению кода (RCE) без аутентификации; обе получили оценку 9,2 по шкале CVSS v4.0. Официальные представители PHP прямо заявили, что до установки исправления все установки PHP, предоставляющие веб-сервисы, могут быть подвержены атаке.

20 октября детали уязвимостей просочились до официального раскрытия, а патч ещё не был выпущен. Команде безопасности PHP пришлось перенести экстренный релиз с запланированного 22 октября на 21 октября 14:00 (UTC).

Ещё более тревожно то, что атаки могли начаться раньше раскрытия. Команда Amazon Threat Intelligence сообщила, что ещё 17 октября в своей honeypot-сети MadPot наблюдала попытки эксплуатации php2shell — за четыре дня до публичного раскрытия.

SlowMist также выпустила предупреждение и рекомендации сразу после официального анонса PHP.

Что представляют собой эти две уязвимости

CVE-2026-109618 (повреждение памяти при OOM): когда PHP исчерпывает память, процесс обработки прерывается, и данные на этот момент подготовлены лишь наполовину. При завершающей очистке PHP обращается с этими незавершёнными данными как с полноценными, что приводит к хаосу в памяти.

CVE-2026-109619 (устаревшее глобальное состояние): после завершения обработки запроса память освобождается, но связанное состояние сохраняется. Когда тот же рабочий процесс принимает следующий запрос, он может использовать это устаревшее состояние до нормальной инициализации. Официально подтверждено, что это позволяет атаковать PHP-FPM и добиться удалённого выполнения кода (RCE).

С точки зрения вектора атаки опасность таких уязвимостей в том, что злоумышленнику не нужно предварительно получать учётную запись сайта или обходить бизнес-аутентификацию, права доступа или проверку API-ключей. Достаточно отправить специально сформированный запрос публично доступному PHP-приложению, чтобы выполнить произвольный код с правами процесса веб-сервиса.

Затронутые версии: PHP с 5.4 по 8.5.11. Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. PHP 8.1 и более ранние версии больше не получают регулярную поддержку от разработчиков, поэтому не стоит рассчитывать на получение патчей обычным путём — необходимо мигрировать на поддерживаемые версии.

Почему весь мир напрягся?

Потому что PHP распространён повсеместно. По статистике W3Techs, среди сайтов, у которых можно определить серверный язык, 69,3% используют PHP. WordPress, WooCommerce, Magento — все эти знакомые системы работают на нём.

Реакция разных стран тоже показательна: Национальный центр кибербезопасности Нидерландов превентивно отключал сайты; офис президента Южной Кореи провёл экстренное совещание по кибербезопасности, правительство повысило уровень тревоги.

Кроме того, по сообщениям, почти все официальные сайты Северной Кореи, включая государственные СМИ и правительственные порталы, недоступны более 24 часов; пока неизвестно, связано ли это с данной уязвимостью.

Влияние на Web3

Это проблема не только эксплуатации традиционных сайтов. Для Web3, даже если ончейн-контракты не имеют уязвимостей, множество «офчейн-звеньев», обеспечивающих работу контрактов, — фронтенд-страницы, API, кошельки с хранением у третьей стороны, сервисы подписи, страницы получения аирдропов, операционные бэкенды и сервисы данных — часто построены на PHP (WordPress, WooCommerce, Magento и т.д.). Отсутствие уязвимостей в самом контракте не означает безопасность этих звеньев.

По данным системы анализа угроз MistEye, входящей в SlowMist, из 1488 просканированных доменов, связанных с криптоиндустрией, 793 имеют прямые признаки PHP — примерно 53,3%. Важно подчеркнуть: это лишь говорит об использовании PHP, а не о том, что эти сайты уязвимы или уже взломаны.

1. Платформы: несколько типичных путей риска

Подмена фронтенда и побуждение пользователей к подписанию.

Если сервер DeFi-, кошелькового сайта или страницы аирдропа скомпрометирован, злоумышленник может подменить RPC-адрес, объект авторизации, адрес контракта или подсказки подписи на странице, превратив обычную транзакцию во вредоносную авторизацию, взаимодействие с вредоносным контрактом или фальшивый процесс пополнения. Атакующему не нужно взламывать контракт — достаточно заставить пользователя самому подписать вредоносную авторизацию.

Утечка ключей и учётных данных.

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

Компрометация бэкенда и API.

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

Горизонтальное перемещение в цепочке поставок.

Права PHP-процесса обычно не равны максимальным правам сервера, но если он может прочитать CI/CD-ключи, сокеты среды выполнения контейнеров, учётные данные баз данных или токены облачного доступа, масштаб атаки может расшириться с одного веб-узла до баз данных, систем сборки и даже всего производственного аккаунта.

Платёжные плагины и сторонние сервисы.

Известно, что Binance Pay, Crypto.com Pay, BitPay, CoinGate, CoinPayments и другие криптоплатёжные решения имеют интеграции с WooCommerce; если сервер не пропатчен, он подвергается серьёзному риску. Сторонние сервисы — RPC, обозреватели блоков, платформы аналитики данных — также могут стать точкой входа, если их бэкенд или системы эксплуатации работают на уязвимой среде PHP. Разумеется, RPC-узлы, смарт-контракты, обозреватели блоков и кошельки сами по себе не обязательно зависят от PHP — всё зависит от технологического стека конкретного продукта.

Но важно понимать: компрометация сервера не означает автоматическую кражу ончейн-активов. От взлома веб-сервиса до реальной потери средств всё зависит от того, сможет ли злоумышленник получить доступ к чувствительным учётным данным, процессам подписи, административным правам или элементам взаимодействия с пользователем. Изолирован ли горячий кошелёк от веб-уровня, хранятся ли ключи в HSM/KMS, минимизированы ли привилегии — всё это напрямую определяет максимальный размер потерь.

2. Обычные пользователи: нужно ли выводить средства?

Нет.

Причина проста:

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

Просмотр сайтов и подключение кошелька — не то же самое, что утечка приватного ключа. Сама по себе уязвимость не может напрямую взломать кошелёк пользователя или подпись.

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

Если проект официально подтвердил взлом сайта или бэкенда, оценивайте фактическое влияние по объявлению: стоит ли приостановить взаимодействие, проверить подозрительные транзакции, отозвать сомнительные авторизации. Если подтверждена утечка приватного ключа подписи или мнемонической фразы, действуйте как при инциденте с утечкой ключей — одной смены пароля или отключения от сайта недостаточно. Пользователям торговых ботов, инструментов автоматизации или облачных сервисов развёртывания также следует следить за уведомлениями о затронутых версиях или ротации учётных данных.

Как реагировать

1. Платформы и проекты:

Шаг первый: провести инвентаризацию и как можно скорее обновиться

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

Обновитесь до 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 или примените эквивалентные патчи от дистрибутивов, облачных провайдеров или хостинг-провайдеров. Для версий 8.1 и более ранних запросите backport у поставщика или как можно скорее мигрируйте. «Старая среда стабильна» или «приложение редко обновляется» не снижают риск этой уязвимости.

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

Шаг второй: что делать, если обновление пока невозможно

Сначала сократите поверхность атаки, чтобы выиграть время, но это не заменит патч:

Изолируйте PHP-приложения, доступные из интернета, или добавьте сетевую аутентификацию и контроль доступа на входном уровне.

Отключите ненужную загрузку файлов, отклоняйте ненужные запросы multipart/form-data на уровне WAF или веб-сервера.

Некоторые рекомендации также включают: установить memory_limit=-1, отключить session.upload_progress.enabled, а на PHP 8.5 дополнительно отключить fatal_error_backtraces. Эти настройки имеют побочные эффекты для бизнеса и доступности, поэтому сначала протестируйте их и после каждого изменения перезапускайте все PHP-воркеры.

Шаг третий: проверить, не было ли вторжения, и очистить учётные данные

Для затронутых сервисов, которые были доступны из интернета, проведите анализ журналов, мониторинг конечных точек и аномальных сетевых подключений, например, когда PHP-процесс внезапно запускает системные команды. При обнаружении подозрений на вторжение сначала сохраните доказательства, затем действуйте по процедуре реагирования на инциденты.

Исходите из худшего сценария: для серверов, которые не были своевременно пропатчены, ротируйте API-ключи, сессионные ключи, TLS-сертификаты, пароли баз данных, токены облачного доступа, учётные данные CI/CD, RPC/API-ключи, ключи Webhook и сторонние токены, а также проверьте наличие подозрительной активности.

Если в среде устанавливались или запускались версии ПО, подтверждённо заражённые, простое обновление или переустановка не гарантирует устранение риска — необходимо также проверить утечку учётных данных и постоянные бэкдоры, а при необходимости пересоздать чистую среду.

Шаг четвёртый: защитить контур управления активами

Патч PHP не должен быть единственным действием. Важнее обеспечить, чтобы компрометация одной веб-машины не привела к потере средств:

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

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

На время инцидента временно ужесточите операции с высоким риском: вывод средств, изменение белого списка адресов, повышение привилегий администраторов, создание API-ключей, изменение правил риск-контроля; при необходимости включите ручную проверку или отложенное вступление в силу.

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

Проверьте статические ресурсы сайта, JavaScript-пакеты, конфигурацию обратного прокси, правила DNS/CDN и сервисы построения транзакций на предмет внедрения вредоносных скриптов или подмены.

2. Обычные пользователи:

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

Не полагайтесь только на домен и интерфейс: даже знакомый домен dApp может иметь подменённые скрипты страницы, параметры транзакций или RPC-конфигурацию, если сервер скомпрометирован.

Проверяйте каждую деталь перед подписью: адрес получателя, сеть, сумму авторизации, вызываемый контракт и результат симуляции транзакции. Особенно осторожно относитесь к approve и setApprovalForAll, а к авторизации на неограниченную сумму — вдвойне.

Остерегайтесь «компенсаций», «миграций», «повторной верификации»: во время инцидента могут появляться подсказки «войти снова», «повторно верифицировать кошелёк», «мигрировать активы», «получить компенсацию». Не действуйте только на основании всплывающих окон на сайте — перепроверяйте информацию по нескольким официальным каналам проекта.

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

При аномалиях остановитесь: если видите необычный запрос на подпись, неожиданное окно авторизации или странное поведение сайта, сначала приостановитесь и проверьте через официальные каналы.

В заключение

Уязвимости удалённого выполнения кода без аутентификации, подобные PHP2Shell, после прорыва веб-уровня могут превратить традиционное вторжение на сервер в отравление фронтенда, кражу личности, злоупотребление правами подписи, риски для горячих кошельков и даже горизонтальное проникновение по цепочке поставок.

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