PHP2Shell: две критические уязвимости PHP и что делать

21 октября 2026 года вышли экстренные обновления PHP, закрывающие две критические уязвимости — CVE-2026-109618 и CVE-2026-109619, получившие общее название PHP2Shell. Проблема находится в самом движке PHP, поэтому она касается не конкретной CMS или фреймворка, а серверного окружения, в котором работает сайт.

Для владельцев сайтов на 1С-Битрикс, WordPress, Laravel, Symfony и других PHP-платформах главный вывод простой: нужно проверить версию и происхождение PHP на сервере и убедиться, что исправление действительно установлено.

Содержание

• Что случилось
• Кого касается PHP2Shell
• Насколько это опасно прямо сейчас
• Что делать: пошаговый чек-лист
• Как проверить версию PHP и наличие патча
• Временные меры, если обновиться прямо сейчас нельзя
• Признаки атаки в логах
• Итог

Что случилось

20 октября PHP заранее объявил о внеплановом security-релизе для двух критических уязвимостей. Изначально раскрытие планировалось на 22 октября, но после утечки идентификаторов CVE выпуск перенесли на сутки раньше.

21 октября в 14:00 UTC вышли исправленные версии:

• PHP 8.5.12;
• PHP 8.4.27;
• PHP 8.3.36;
• PHP 8.2.35.

Обе уязвимости получили от PHP оценку CVSS v4.0 9.2. Ходившая до релиза оценка 10.0 была неверной. Уязвимый код присутствует в PHP начиная с версии 5.4.0 (2012 год).

Если сильно упростить техническую часть:

• CVE-2026-109618 связана с некорректным состоянием внутренних структур PHP при нехватке памяти во время разбора запроса. В определённых условиях это может привести к повреждению памяти и удалённому выполнению кода.
• CVE-2026-109619 связана с сохранением устаревшего состояния PHP-воркера между запросами. Среди подтверждённых последствий — раскрытие содержимого памяти процесса, где могут оказаться пароли, токены сессий и API-ключи.

Уязвимости обнаружили исследователи Calif, Wiz Research и OpenAI.

Кого касается PHP2Shell

Проблема находится не в WordPress, 1С-Битрикс, Laravel или Symfony, а непосредственно в PHP. Поэтому потенциально затронуты все веб-развёртывания:

• Apache mod_php;
• PHP-FPM;
• php-cgi;
• FrankenPHP;
• LiteSpeed.

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

Для PHP 7.4, 8.0 и 8.1 команда безопасности PHP опубликовала минимальные исходные бэкпорты исправлений, но новых релизов этих веток нет. Версии 5.4–7.3 давно не поддерживаются и официальных исправлений не получат.

При этом дистрибутивы и LTS-поставщики (Debian, Ubuntu, Red Hat, AlmaLinux, Remi, CloudLinux и другие) могут бэкпортировать патч, сохранив прежний номер версии. Поэтому по одному номеру PHP не всегда можно понять, установлено ли исправление.

Насколько это опасно прямо сейчас

Ситуация серьёзная, но важно не смешивать несколько разных фактов.

Amazon обнаружил попытку эксплуатации на своей honeypot-инфраструктуре ещё 17 октября — за четыре дня до публичного раскрытия — и после релиза сообщил о новых попытках. Cloudflare наблюдал ранний атакующий трафик и развернул WAF-правила для клиентов. Datadog фиксирует широкое ненаправленное сканирование интернета.

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

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

Отдельно: код, который распространяется в интернете под видом «PHP2Shell exploit», сам может оказаться вредоносным. Запускать такие PoC на рабочих машинах и серверах не стоит.

Что делать: пошаговый чек-лист

1. Найти все системы, где используется PHP: продакшен, тестовые и резервные серверы, Docker-образы, отдельные сервисы.
2. Определить PHP именно веб-окружения. Результат php -v в SSH относится к консольной версии и может не совпадать с PHP, которым обслуживается сайт.
3. Определить источник PHP: пакет Ubuntu/Debian, RHEL/AlmaLinux, сторонний репозиторий, панель хостинга, Docker или собственная сборка.
4. Установить исправление: для официальных веток — 8.2.35, 8.3.36, 8.4.27, 8.5.12 и новее.
5. Для старых веток проверить патч поставщика: дистрибутив может оставить прежний номер версии и добавить исправление в свою ревизию пакета.
6. Перезапустить PHP-воркеры или веб-сервер. Обновить файлы недостаточно, если старые процессы продолжают работать в памяти.
7. Проверить логи начиная как минимум с 17 октября 2026 года.

Официальные Docker-образы PHP 8.1 и более ранних веток исправлений не получат. Такой контейнер нужно пересобрать на поддерживаемой ветке либо взять образ поставщика, который явно бэкпортировал исправление.

Как проверить версию PHP и наличие патча

Первичная проверка из консоли:

php -v

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

На Debian и Ubuntu наличие исправления можно проверить по changelog установленных пакетов:

zgrep CVE-2026-109618 /usr/share/doc/php*-common/changelog.Debian.gz 2>/dev/null

Для систем семейства RHEL (AlmaLinux, Rocky Linux, CentOS Stream):

rpm -q --changelog php-common | grep -F CVE-2026-109618

Ubuntu уже выпустила security notice USN-8948-1 с исправленными пакетами PHP 8.1, 8.3 и 8.5. Перезагрузка сервера обычно не нужна, но Apache и PHP-FPM после обновления нужно перезапустить, чтобы загрузился исправленный код.

На серверах с VMBitrix не стоит полагаться на «типичную версию PHP» — её нужно проверить на конкретном сервере тем же способом.

Временные меры, если обновиться прямо сейчас нельзя

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

Для CVE-2026-109619 можно отключить отслеживание прогресса загрузки (оно включено по умолчанию и работает, даже если сайт не использует сессии):

session.upload_progress.enabled = 0

На PHP 8.5 дополнительно:

fatal_error_backtraces = 0

Для известного сценария CVE-2026-109618 временной мерой служит снятие лимита памяти:

memory_limit = -1

У этой меры серьёзный побочный эффект: PHP больше не ограничивает память одного запроса. Поэтому её стоит применять только вместе с лимитом памяти контейнера или cgroup и мониторингом. Использовать вместо этого RLIMIT_AS и RLIMIT_DATA не рекомендуется.

Также имеет смысл:

• ограничить допустимый размер POST-запросов и число загружаемых файлов;
• блокировать multipart/form-data там, где загрузка файлов не нужна;
• фильтровать аномальные запросы на WAF или reverse proxy.

Такие изменения могут сломать загрузку файлов, импорт данных или оформление заказа в интернет-магазине, поэтому их нужно тестировать. Для PHP-FPM настройки задаются в конфигурации пула, а не в php.ini консольной версии и не из кода приложения; после изменений перезапустите все воркеры.

WAF Cloudflare снижает риск только для трафика, который через него проходит, и сам Cloudflare называет такую защиту временной.

Признаки атаки в логах

Проверять историю стоит начиная минимум с 17 октября 2026 года. На что обратить внимание:

• необычные POST-запросы с очень длинными именами полей;
• ошибки Allowed memory size ... exhausted на ранней стадии обработки запроса (с указанием Unknown on line 0);
• неожиданные падения и частые перезапуски PHP-воркеров, Segmentation fault в логах веб-сервера;
• необычно большие или странные значения PHPSESSID;
• запуск shell-процессов дочерними процессами Apache или PHP-FPM.

Последний пункт — самый прямой признак успешной эксплуатации. Остальные сигналы по отдельности атаку не доказывают: их нужно сопоставлять по времени между access log, error log и журналами процессов.

Итог

PHP2Shell — редкий случай, когда проблема находится ниже уровня CMS или фреймворка. Обновление 1С-Битрикс, WordPress, Laravel-приложения или их модулей уязвимый PHP не исправляет.

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

Команда NJ Soft помогает проверять серверное окружение, обновлять PHP и сопровождать веб-проекты — подробнее в разделе «Поддержка и развитие».