PHP2Shell: дыры в PHP начали эксплуатировать в реальных атаках

Что произошло, почему это важно и что взять в работу.

Патч вышел 21 октября, но эксплойт уже работает — серверам на PHP с открытым портом нужен срочный апдейт, а не плановый.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Патч вышел 21 октября. Через шесть дней подтвердили: дыры в PHP уже несут практическую пользу атакующим. Эксплуатация двух критических уязвимостей PHP2Shell (CVE-2026-109618 и CVE-2026-109619) воспроизведена на реальной машине — не в теории, не «по мотивам публичных PoC». Удалённое выполнение команд без авторизации, то есть чужой shell-процесс на вашем сервере.

Если ваш сайт или внутренний сервис крутится на PHP и его порт смотрит наружу, у вас есть выбор из двух сценариев. Обновить на этой неделе. Или объяснять клиентам, почему в логах чужой `id`.

Что именно подтвердили

Адель Карими, руководитель направления обнаружения угроз и реагирования на инциденты в Perplexity, держит серверы-ловушки. Одна из таких машин — типичный рабочий конфиг: Apache mod_php, PHP 8.4.26. На неё и пришла атака. Атакующий вытащил около 800 КиБ данных из памяти процесса, выцепил оттуда адрес нужной функции и подготовил следующий этап. После отправки последнего байта запроса сервер выполнил команду оболочки примерно через 1,6 мс.

Миллисекунды — важная деталь. Эксплойт не требует часов перебора и не сыпется на таймаутах. Он отрабатывает как штатный запрос.

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

Результат независимо подтвердил Маркус Хатчинс из Expel, который отслеживал сообщения об успешной эксплуатации PHP2Shell. До этого момента картина была мутной: попытки атак фиксировали Cloudflare, Hadrian, watchTowr, Previdian и Patchstack, но доказать, что кому-то удалось добиться выполнения кода, никто не мог.

Что было до: четыре дня тишины и «эксплойты не работают»

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

Специалисты Amazon Threat Intelligence зафиксировали первые попытки атак 17 октября. За четыре дня до выхода патчей. То есть окно уязвимости не открылось в день релиза — оно уже было открыто, пока инженеры собирали обновление.

Эта хронология ломает привычный ритуал «дождусь планового окна обновлений». Плановое окно уже прошло. Атакующие в него не смотрели.

Масштаб: почему это не история про чужой сервер

PHP — фундамент веба. По оценке, приведённой в источнике, на нём работает примерно 70 % сайтов. VirusTotal насчитал более 5,1 млн хостов с PHP в открытом доступе, и около 3,8 млн из них имеют как минимум один порт, доступный для атаки. Три миллиона восемьсот тысяч — это не «где-то там».

Для SMB это означает неприятную вещь. Ваш интернет-магазин на старой CMS, самописная админка, которую делал подрядчик в 2019-м и с тех пор никто не трогал, тестовый стенд с боевыми доступами, забытый API для партнёров — всё это один класс риска. Уязвимость живёт на уровне рантайма, а не в конкретном плагине. Значит, «у нас не WordPress» не защищает.

Что взять в работу на этой неделе

Ниже последовательность, а не пожелания. Порядок имеет значение.

• Инвентаризация за час, не за месяц. Выпишите все хосты с PHP: прод, стейджи, внутренние сервисы, клиентские проекты на вашем хостинге. Отдельно отметьте те, у которых порт доступен из интернета.
• Обновление PHP — приоритет P0. Не «в следующем спринте». Проверьте, какая версия стоит фактически, а не какая указана в договоре с провайдером. Конфиг в тесте — PHP 8.4.26; ориентируйтесь на актуальные релизы ветки, где закрыты обе CVE.
• Проверьте внешнюю поверхность сами. Сканер портов покажет, что реально торчит наружу. Часто выясняется, что «внутренний» сервис прекрасно отвечает из интернета.
• Смените секреты на всём, что было доступно извне до патча. Ключи к базе, API-токены, пароли сервисных учёток. Если выполнялась команда оболочки, считать периметр чистым нельзя.
• Прочитайте логи за 17–26 октября. Ищите аномальные POST-запросы и следы запуска процессов веб-сервером. Наличие попыток — повод для разбора, а не для паники.
• Временные меры — только как затычка. Правила WAF и ограничение доступа по IP снижают шансы, но не отменяют обновление. Это пластырь на артерию.

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

Где подвох

Главный риск не технический. Он управленческий. Между «мы отправили задачу хостеру» и «на сервере новый рантайм» лежит пропасть, в которой живут тикеты без ответа и подрядчики без SLA. Второй риск — legacy. Часть старых приложений просто не заведётся на свежем PHP, и это выяснится в момент обновления, а не до него. Значит, тестовый прогон обязателен, но он не должен превращаться в повод отложить патч на месяц.

Третий риск — привычка верить заявлениям о нерабочих эксплойтах. В этом сюжете такая вера стоила четырёх дней форы атакующим.

Вердикт

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

Плановое обновление здесь не работает. Нужен внеплановый апдейт с проверкой внешних портов и ротацией секретов. Если у вас нет человека, который сделает это сегодня, — это и есть главная проблема, а не CVE-2026-109618.

PHP используется примерно на 70 % сайтов в интернете.

Ставка высокая ровно настолько, насколько ваш бизнес зависит от сайта. У большинства SMB — на всю выручку.