PHP2Shell перешёл от сканирования к реальным взломам, и обновление CMS от него не защищает
Атаки на серверы PHP через критические уязвимости PHP2Shell перешли от массового сканирования к подтверждённому выполнению команд. Исследовательские ловушки зарегистрировали 35 успешных запусков командной оболочки на трёх серверах, а специалисты восстановили цепочку эксплуатации по сетевым пакетам, журналам Apache и событиям операционной системы. Одновременно растёт число попыток атак, появляются более совершенные эксплойты, а разработчики PHP предупредили о третьей уязвимости, для которой пока нет исправления.
Речь идёт о CVE-2026-109618 и CVE-2026-109619, получивших оценку 9,2 балла по CVSS 4.0. Обе проблемы находятся непосредственно в интерпретаторе PHP и при определённых условиях позволяют выполнять произвольный код без авторизации. Первая связана с повреждением внутренних структур при нехватке памяти, вторая с ошибкой типа Use-After-Free, когда программа повторно обращается к уже освобождённой памяти. В наиболее опасной конфигурации Apache mod_php эксплуатация возможна ещё до запуска кода веб-приложения, поэтому обновление WordPress, Drupal или других систем управления сайтом не устраняет угрозу.
Наиболее убедительные доказательства успешных атак опубликовал специалист Perplexity Адель Карими. Его ловушки, работавшие под управлением Apache mod_php и PHP 8.4.26, зафиксировали 35 запусков /bin/sh, непосредственно порождённых рабочими процессами Apache. Три события связаны с адресом 15.204.59.70, ещё 32 с адресом 162.35.99.94. Атаки затронули три специально подготовленных сервера.
Атакующие применяли последовательность из четырёх этапов. Сначала специально сформированные HTTP-запросы создавали нагрузку на память PHP. Затем сервер раскрывал фрагменты собственной памяти через увеличенное значение PHPSESSID. Полученные сведения позволяли определить адреса внутренних структур и подготовить заключительный запрос для запуска команды. В одном из эпизодов исследователи восстановили утечку примерно 800 Кбайт данных, а запуск оболочки произошёл приблизительно через 1,6 миллисекунды после получения последней части атакующего запроса.
Подробные записи позволили связать каждый успешный запрос с конкретным процессом операционной системы. Речь уже не об ошибке сервера, подозрительном ответе HTTP или предположении о наличии рабочего эксплойта. Исследователь Expel Маркус Хатчинс назвал материалы Карими наиболее убедительным подтверждением реальной эксплуатации PHP2Shell из опубликованных к тому моменту.
Однако 35 запусков оболочки не означают взлом 35 организаций. Все подтверждённые события произошли на исследовательских ловушках с одним рабочим процессом Apache, что облегчает воспроизведение атаки. Полученные результаты не позволяют оценить надёжность эксплуатации на загруженных производственных серверах с несколькими рабочими процессами и другими конфигурациями PHP. В исследовании также не зафиксирована успешная доставка дополнительного вредоносного ПО.
Масштаб подозрительного трафика значительно больше числа доказанных успешных атак. К утру 26 октября ловушки Delft Threat Intelligence Lab зарегистрировали свыше 50 тысяч запросов, связанных с PHP2Shell, более чем с 600 IP-адресов из 70 стран. За самый активный час наблюдений поступило свыше 5100 запросов. По оценке исследователей, 171 источник перешёл от простого поиска уязвимых серверов к передаче программного кода или загрузчиков вредоносных файлов.
Первые попытки эксплуатации появились ещё до выхода исправлений. Amazon Threat Intelligence обнаружила атакующую активность 17 октября, за четыре дня до официального раскрытия уязвимостей. Запросы поступали через инфраструктуру анонимизации. Специалисты не установили, откуда атакующие узнали о проблемах и могли ли ранние попытки привести к успешному проникновению. После публикации исправлений интенсивность сканирования резко выросла.
Важным изменением стало появление эксплойтов, способных обходить ASLR. Механизм случайным образом меняет расположение данных и исполняемого кода в памяти, затрудняя эксплуатацию ошибок управления памятью. Исследователи VulnCheck создали эксплойт, который использует утечку адресов для последующего выполнения команд даже при включённой ASLR и отключённом выводе ошибок PHP. К 23 октября инструмент поддерживал несколько выпусков PHP 8.4 и 8.5 на архитектурах AMD64 и ARM64, включая типовые установки WordPress в Docker. Рабочий инструмент распространяется среди клиентов компании, а не публикуется свободно.
Параллельно появилось множество общедоступных демонстрационных эксплойтов. Значительная часть опубликованных программ либо воспроизводит только аварийное завершение PHP, либо требует специфических лабораторных настроек. По этой причине массовое сканирование пока не переросло в доказанную массовую компрометацию производственных серверов. Но появление средств обхода ASLR показывает, что первоначальные ограничения атак постепенно преодолеваются.
Некоторые ранние заявления об успешных взломах пришлось пересмотреть. Sophos первоначально сообщила о компрометации клиентской инфраструктуры, однако последующий анализ выявил сканирование и заблокированные попытки эксплуатации. Аналогичную поправку внесла Palo Alto Networks. Подразделение Unit 42 отозвало выводы о связи проникновения в европейское государственное учреждение с PHP2Shell, поскольку установить конкретный способ первоначального доступа не удалось.
Тем временем Arctic Wolf обнаружила попытки доставки вредоносных программ, связанных с ботнетом Potassium. Семейство происходит от Mirai и предназначено для захвата устройств с последующим использованием в распределённых атаках. Исследователи обнаружили запросы, которые пытались определить системного пользователя, выполнить проверочные команды и загрузить дополнительные файлы. Связанная инфраструктура содержала два образца Potassium, но подтвердить их успешную установку через PHP2Shell пока не удалось.
Ещё более тревожный сценарий описала CYFIRMA. Компания предупредила о предположительно связанной с КНДР кампании, участники которой отобрали 216 серверов для дальнейших атак. По оценке исследователей, операторы используют 21 скомпрометированный узел для медленного распределённого сканирования. Среди потенциальных целей находятся государственные учреждения, банки, логистические компании, авиационная инфраструктура, промышленные предприятия и платформы электронных платежей в США, Азии, Европе и странах Ближнего Востока.
CYFIRMA предполагает связь кампании с экосистемой Lazarus, но оценивает уверенность в атрибуции как умеренную. Аргументами служат корейский язык переписки, особенности работы операторов и сходство с прежними кампаниями. Независимых доказательств участия конкретного северокорейского подразделения нет. Список 216 адресов рассматривается как предполагаемый набор целей, а не перечень уже взломанных организаций. Массовая компрометация в рамках указанной кампании не подтверждена.
Оценки числа незащищённых серверов также требуют осторожности. OX Security через 24 часа после выхода исправлений обнаружила 99,3% установок PHP без новых версий среди почти 1,975 миллиона экземпляров, для которых удалось провести измерение. Исправленные версии показывали только 14 151 экземпляр. Однако исследование опиралось на сведения Shodan, включая HTTP-заголовки, и не учитывало серверы, скрывающие версию. Кроме того, некоторые поставщики Linux переносят исправления в старые версии пакетов без изменения основного номера PHP. Показатель 99,3% характеризует первые сутки после выпуска патчей и не отражает автоматически ситуацию на 27 октября.
Qualys получила сопоставимую по масштабу, но принципиально другую статистику. В обезличенных сведениях более чем 10 тысяч клиентов компания обнаружила 167 миллионов установок пакетов PHP. Из 156 миллионов установок с известной версией около 71% относились к неподдерживаемым веткам PHP 5.4–8.1, а 73% находились на доступных из интернета активах. Речь идёт об установленных пакетах в клиентской выборке Qualys, а не о доказанной доле уязвимых веб-сайтов во всём интернете.
Дополнительную проблему создала CVE-2026-115560, о которой команда PHP предупредила 23 октября. Уязвимость также допускает удалённое выполнение кода, но требует редкого сочетания настроек и логики приложения. Программа должна использовать обработчик сериализации сессий php_binary или php_serialize, затем переключать его на php через ini_set() перед session_start(), сохраняя включённым механизм отслеживания прогресса загрузки файлов. Октябрьские исправления CVE-2026-109618 и CVE-2026-109619 новую проблему не закрывают. До выхода отдельного патча разработчики советуют отключить параметр session.upload_progress.enabled.
Основные исправления PHP2Shell доступны с 21 октября в версиях PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Для некоторых устаревших веток предусмотрены ограниченные исправления исходного кода и пакеты поставщиков с расширенной поддержкой. Разработчики признают, что временные изменения конфигурации не устраняют обе основные уязвимости полностью. Единственным полноценным решением остаётся установка исправленного PHP.
Для поиска атак Corelight опубликовала правила обнаружения для Zeek и Suricata. OpenAI выпустила PHP2Shell Checker для проверки потенциально уязвимых версий, а Searchlight Cyber представила активный сканер, способный проверять отдельные признаки уязвимого поведения. Последний инструмент следует применять осторожно, поскольку попытки вызвать нехватку памяти могут нарушить работу веб-сервера.
Российские производители средств защиты также подготовили механизмы обнаружения. «Лаборатория Касперского» представила правила для KUMA, рекомендации по поиску подозрительных событий и возможности обнаружения средствами MDR. Positive Technologies опубликовала сигнатуры Suricata, а BI.ZONE описала поиск активности PHP2Shell через EDR и SOC.
Администраторам рекомендуется проверить не только номер установленного PHP, но и фактически работающие процессы веб-сервера. На одном сервере могут одновременно находиться несколько веток PHP, а обновление пакетов без перезапуска Apache или PHP-FPM способно оставить старые уязвимые процессы в памяти. При расследовании следует анализировать HTTP-запросы, ошибки нехватки памяти, аварийные завершения PHP, неожиданные дочерние процессы Apache и исходящие соединения как минимум с 17 октября.
Активную проверку PHP2Shell следует проводить только на собственной инфраструктуре или с разрешения владельца. Некоторые методы проверки намеренно вызывают нехватку памяти и аварийное завершение PHP, что может нарушить доступность сайта.
Уязвимости PHP2Shell стали известны разработчикам не внезапно. Первые признаки проблемы с обработкой нехватки памяти обнаружили ещё в 2024 году во время устранения замечаний независимого аудита Quarkslab. Работу над исправлением неоднократно откладывали из-за сложности изменений, возможных нарушений совместимости и недостатка ресурсов команды PHP. Реальную опасность удалённого выполнения кода удалось подтвердить только после новых исследований в августе 2026 года, в которых участвовали Calif, OpenAI и Wiz.
Сейчас доказаны успешные атаки на исследовательские серверы и многочисленные попытки эксплуатации в интернете, но публично подтверждённой массовой компрометации организаций через PHP2Shell пока нет. При этом наличие рабочих эксплойтов, способных обходить ASLR, и большое число устаревших установок оставляют злоумышленникам широкие возможности. Даже после установки обновлений компаниям придётся проверять журналы и искать следы возможного проникновения, поскольку исправленный интерпретатор не удаляет вредоносные файлы и не отзывает секреты, которые могли попасть к атакующим раньше.