21 октября 2026 года вышли PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Они закрывают две уязвимости с оценкой 9,2 из 10 по CVSS 4.0, каждая из которых позволяет выполнить чужой код на сервере без логина и пароля. Обновление — единственное полноценное решение. Всё остальное лишь снижает риск.
Что случилось
В ядре интерпретатора PHP нашли две критические уязвимости:
CVE-2026-109618 — порча памяти при нехватке памяти. Когда PHP упирается в лимит
memory_limit, он аварийно прерывает запрос. В некоторых точках обработки память уже выделена, но не заполнена до конца, а процедура завершения принимает эти недостроенные данные за корректные. Исчерпать память снаружи несложно: достаточно особым образом собранного multipart-запроса.CVE-2026-109619 — устаревшее состояние между запросами. Часть внутреннего состояния PHP — ошибки, сессии, объекты, данные расширений — переживает освобождение памяти своего запроса и достаётся следующему запросу того же рабочего процесса. Обращение к уже освобождённой памяти при подготовленной раскладке кучи приводит к выполнению кода.
В англоязычных разборах и в правилах защиты эту пару называют PHP2Shell — под этим именем её упоминают Cloudflare, Sansec и watchTowr.
Обе уязвимости дают удалённое выполнение произвольного кода (RCE) с правами веб-процесса. Пользователь сайта, форма и авторизация для этого не нужны. Дальше — доступ к данным, нарушение работы системы и, что часто остаётся незамеченным, использование вашего сервера в чужих атаках.
Кого это касается
Уязвимы все версии PHP ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12. То есть подавляющая часть сайтов, приложений и популярных CMS на PHP: WordPress, Drupal, OpenCart, Joomla, Magento, MediaWiki, phpBB, WHMCS, 1С-Битрикс, а также фреймворки вроде Laravel и Symfony.
Важный момент, который часто понимают неправильно: уязвим сам интерпретатор PHP, а не приложение. Обновление WordPress, Битрикса или Laravel проблему не решает — закрывать нужно PHP на сервере.
Что у вас | Затронуто | Кто исправляет |
|---|---|---|
Облачный Битрикс24 | Нет | Вендор, от вас ничего не требуется |
Коробочный Битрикс24, 1С-Битрикс: Управление сайтом | Да | Администратор сервера |
Сайт на WordPress, Joomla, Drupal, OpenCart, Laravel и других PHP-системах | Да | Администратор или разработчик |
Виртуальный хостинг с общей панелью | Да | Хостинг-провайдер, уточните сроки |
Отдельный сервер или VPS с PHP | Да | Ваш администратор |
Отдельно про способ запуска PHP. Рабочий эксплойт продемонстрирован для Apache с mod_php на настройках по умолчанию — это максимальный риск, и именно так до сих пор устроены многие серверы с 1С-Битрикс. PHP-FPM, FrankenPHP и LiteSpeed уязвимы по анализу исходного кода, хотя полный эксплойт для них публично не показан.
Атакуют ли уже
Да. Эксплойт показан в действии на веб-серверах с WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal и WHMCS.
Cloudflare выпустил правила защиты в управляемом наборе WAF ещё до публичного раскрытия и фиксирует попытки эксплуатации с первых часов.
watchTowr видит обращения к уязвимым путям в своей сети ловушек с 21 октября.
Sansec ожидает массовой эксплуатации: по опубликованному патчу восстановить путь атаки проще, чем найти её самостоятельно.
НКЦКИ при ФСБ России 22 октября предписал устранить уязвимости на объектах критической информационной инфраструктуры, а если быстро установить исправления не получается — рассмотреть ограничение внешнего доступа вплоть до отключения серверов.
Сканируют всех без разбора, а не выбранные цели. Запаса времени на «плановый регламент в следующем квартале» уже нет.
Что нужно сделать
1. Обновите PHP. Исправления вышли в сборках 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Дефекты нельзя закрыть средствами прикладного кода — только обновлением интерпретатора на сервере. Перед обновлением сделайте резервную копию, а если есть тестовая копия сайта — прогоните обновление сначала на ней.
2. Перезапустите сервисы. PHP-FPM, веб-сервер, обработчики очередей, Apache с mod_php. Без перезапуска старый код остаётся в памяти рабочих процессов, и обновление ничего не даёт. Если перед PHP стоит nginx, перезапускать его бесполезно — PHP живёт в Apache или в php-fpm.
3. Проверьте версию. Команды php -v и php-fpm-<ВЕРСИЯ> -v. И обязательно посмотрите, какую версию видит сам сайт: у веб-сервера может быть свой конфигурационный файл, отличный от консольного. В 1С-Битрикс это видно в «Проверке системы», в панели хостинга — в системной информации.
4. Проверьте систему на признаки взлома. После обновления убедитесь в отсутствии посторонних файлов, изучите журналы событий веб-сервера и, при необходимости, смените пароли, ключи и токены. Уязвимость работала без авторизации, поэтому «у нас никто не смог бы войти» здесь не аргумент.
Если обновиться прямо сейчас нельзя
Разработчики PHP опубликовали параметры конфигурации, которые снижают риски отдельных сценариев эксплуатации. Это выигрыш времени, а не решение:
memory_limit = -1, заданный административно для всех пулов и приложений. Основная мера против первой уязвимости, но неполная: если память не сможет выделить уже операционная система, риск остаётся.Отключение
session.upload_progress.enabledзакрывает только один из путей атаки. Кстати, 23 октября проект выпустил отдельное предупреждение: в этой же функции есть ещё одна неисправленная проблема, экстренного патча не будет, рекомендовано держать её выключенной до следующего планового релиза.WAF отсекает часть попыток. У Cloudflare правило для этих уязвимостей есть в управляемом наборе — на платных тарифах проверьте, что набор работает в режиме блокировки. Но атака идёт обычным HTTP-запросом и по форме не отличается от легитимного трафика, так что фаервол и антивирус здесь не защита.
Разработчики PHP прямо пишут: общей конфигурационной защиты не существует. Эти настройки закрывают отдельные векторы, но не саму уязвимость.
Нюанс с номерами версий
Не ищите на сервере ровно эти номера. Debian, Ubuntu, «Альт» и другие дистрибутивы переносят исправления в свои сборки, не меняя версию целиком: в системе может остаться, например, 8.2.28, но с уже закрытой уязвимостью. Ориентируйтесь не на номер, а на то, установлено ли обновление безопасности для пакета PHP.
Если PHP ставится из репозитория дистрибутива или из панели хостинга, пакет с исправлением появляется не сразу — обычно в течение суток после релиза. Ветки 7.4, 8.0 и 8.1 проект не поддерживает: готовых сборок для них нет, есть только минимальные патчи в исходном коде. Для таких серверов правильный путь — переход на поддерживаемую версию, а до переезда — ограничение внешнего доступа.
И последнее
Обновить PHP на одном сервере — задача на полчаса. Обновить его на десятке серверов, не уронив сайты, очереди и интеграции, проверив каждый и убедившись, что следов взлома нет, — задача другого масштаба. Если своей команды не хватает или непонятно, с чего начать, — напишите нам, разберёмся и сделаем. Иногда дешевле позвать, чем неделю выяснять, почему после обновления не работает половина сайта.