PHP обнаружил «интернет-уровневую» уязвимость высокого риска: как устранить «внешнецепочечную слабость» Web3?

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

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

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

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

Ещё тревожнее то, что атаки могли начаться до раскрытия. Группа разведки угроз Amazon сообщила, что 17 октября зафиксировала попытки эксплуатации php2shell в своей сети хонепотов MadPot — за четыре дня до публичного объявления.

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

Что это за две уязвимости?

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

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

С точки зрения цепочки атаки опасность таких уязвимостей в том, что злоумышленникам не требуется предварительно получить учётную запись сайта, преодолеть логин, проверку прав или 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. Платформы и команды проектов:

Шаг 1. Инвентаризация активов и немедленное обновление

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

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

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

Шаг 2. Что делать, если обновление невозможно сейчас

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

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

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

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

Шаг 3. Проверка на компрометацию и замена учётных данных

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

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

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

Шаг 4. Защита плоскости управления активами

Обновление PHP — не единственное действие. Главное — обеспечить, чтобы «скомпрометированный веб-сервер не повлёк за собой крах финансовой системы»:

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Оригинальная ссылка