В понедельник, 20 октября 2026 года, произошла утечка информации. Подробности о двух критических уязвимостях в PHP попали в сеть раньше запланированного раскрытия. Команда PHP перенесла патч безопасности на день раньше и выпустила исправления в среду, 21 октября.

У этой суматошной недели теперь есть название: PHP2Shell. Это не баг в плагине для WordPress. Это не баг в теме. Это уязвимость в самом PHP — среде выполнения, на которой всё это держится.

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

Что на самом деле представляет собой PHP2Shell

PHP2Shell — это название, которое исследователи дали двум уязвимостям в ядре PHP:

  • CVE-2026-109618 с оценкой 9.2 из 10 по шкале CVSS v4.0
  • CVE-2026-109619, также с оценкой 9.2

Обе уязвимости позволяют неавторизованному атакующему выполнить произвольный код на уязвимом веб-сервере с помощью специально сформированного HTTP-запроса. Без логина. Без пароля. Без действий со стороны жертвы.

Небольшой глоссарий, так как без него дальше не разобраться:

  •  SRE / Runtime (среда выполнения): программа, которая исполняет ваш код. Ваше приложение — это рецепт, а PHP — кухня. Если кухня сломана, идеальный рецепт не спасёт.
  •  Удалённое выполнение кода (RCE): ситуация, когда атакующий получает возможность выполнять свои команды на вашем сервере от имени пользователя веб-сервера.
  •  Воркер (Worker): долгоживущий процесс PHP, который обрабатывает запросы один за другим. PHP-FPM и Apache mod_php работают именно через воркеры.

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

Уязвимость первая: недописанная анкета

CVE-2026-109618 возникает, когда у PHP заканчивается память прямо посередине процесса подготовки данных запроса.

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

В терминах PHP: обработчик нехватки памяти (out of memory) прерывает инициализацию, когда внутренние данные запроса сформированы лишь частично. На этапе очистки PHP начинает считать эти некорректные данные валидными. Именно этой путаницей в памяти атакующий может сманипулировать для выполнения своего кода.

Cisco Talos описывает эту проблему так: обработка нехватки памяти прерывает PHP в момент частичной инициализации внутренних данных запроса, после чего процедура очистки воспринимает невалидные данные как валидные.

Уязвимость вторая: забытый стикер

CVE-2026-109619 — близкий родственник первой уязвимости, и её ещё проще представить.

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

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

Ни одна из этих уязвимостей не требует наличия багов в вашем коде. Ваш код может быть идеальным, проверенным и содержать все патчи, но при этом работать поверх сломанной среды выполнения.

Почему обновление WordPress не решило проблему

Это то, о чём многие забыли в первой волне заголовков.

PHP лежит в основе WordPress, Drupal, Joomla, приложений на Laravel, а также огромного количества коммерческого софта и панелей управления. Обновляя WordPress, вы обновляете приложение, но не сам PHP. Это два разных слоя, которые обновляются разными людьми и по разному графику.

CISA (Агентство по кибербезопасности США) четко перечислило уязвимые конфигурации: Apache с mod_php, PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. Наиболее высоким риском они называют Apache mod_php, поскольку продемонстрированный эксплойт там срабатывает ещё до выполнения кода сайта.

Поэтому правильный вопрос для проверки — не «обновлена ли моя CMS?», а «обновлён ли мой PHP?». Если вы не можете ответить на второй вопрос, работа ещё не закончена.

Почему найти все установки PHP — самое сложное

Установка патчей кажется простой задачей: накатил исправленную версию и забыл. На практике же PHP отлично умеет прятаться.

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

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

С чего начать на практике:

  1. Составьте список всех ваших серверов, контейнеров и хостинг-аккаунтов.
  2. На каждом из них проверьте именно runtime, а не приложение. На сервере команда  php -v  покажет версию CLI-версии PHP, что уже неплохо для начала, но обязательно проверьте, что именно использует ваш веб-сервер. В системе может быть установлено несколько версий PHP одновременно.
  3. Проверьте свои Docker-образы и пересоберите те из них, где зашит старый PHP, даже если само приложение внутри свежее.
  4. Спросите у своего хостинг-провайдера или платформы, какую версию PHP они используют для вас, если вы не управляете сервером напрямую. Управляемые (managed) WordPress-хостинги пропатчили многих клиентов автоматически. Неуправляемые (unmanaged) сервера сами себя не пропатчат.

Что нужно сделать прямо сегодня

Исправленные версии для поддерживаемых веток:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

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

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

Если вы используете PHP 8.1 или более старые версии, официального патча для вашей ветки нет. Эти версии больше не поддерживаются. Ваши реальные варианты — обновиться до поддерживаемой ветки или, как советует CISA, временно отключить систему на PHP, пока она не будет пропатчена или обновлена. Звучит радикально, но это честный вариант ответа на «у нас нет патча для этой версии».

Web Application Firewall (WAF) может заблокировать часть попыток атак, и его стоит включить, если он у вас есть. Но это не полноценное решение. Команда PHP и CISA единогласны: единственный надежный способ защиты — это патчинг. Правило фаервола может пропустить байпас или новую вариацию атаки, тогда как пропатченный runtime банально невозможно эксплуатировать через эти две уязвимости.

И наконец, следите за аномальным поведением воркеров: например, если PHP-процесс запускает командную оболочку (shell), интерпретатор скриптов или утилиту скачивания файлов. Это ненормальное поведение для веб-сервера. Если вы такое увидели, относитесь к этому как к инциденту безопасности, а не просто как к странности.

При чём тут ИИ?

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

Это важный момент, но не по той причине, о которой кричит хайп. Это не значит, что ИИ теперь находит абсолютно все баги за одну ночь. Это означает, что стоимость поиска сложных багов десятилетней давности резко снизилась. Уязвимость, которая жила в PHP со времён версии 5.4, по словам исследователей, оставалась незамеченной годами отчасти потому, что её эксплуатация выглядела слишком сложной, чтобы с ней возиться. Как только этот барьер сложности рушится, скорость установки патчей становится критически важной.

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

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

Итог

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

Проверьте вашу версию PHP. Проверьте её везде, где PHP может прятаться, а не только на том одном сервере, о котором вы помните. Обновитесь до исправленного релиза. Перезапустите воркеры. И если вы всё ещё используете неподдерживаемую версию, составьте план обновления уже на этой неделе, а не «когда-нибудь потом».

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

А что нашли вы, когда провели проверку? Нашлся ли PHP там, где вы его совсем не ждали?

Источники