Данные актуальны на 22 октября 2026 года. Ситуация меняется быстро, поэтому перед действиями сверяйтесь с официальными анонсами на php.net.
Коротко
- 21 октября 2026 года вышел внеплановый security-релиз PHP, закрывающий две критические уязвимости удалённого выполнения кода: CVE-2026-109618 и CVE-2026-109619.
- Обе оцениваются в 9.2 по CVSS v4.0. В утёкших сообщениях до анонса фигурировала оценка 10.0, но официальная цифра 9.2.
- Эксплуатация возможна без аутентификации. По данным исследователей, под удар попадают версии начиная с PHP 5.4.0.
- Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
- Ветки старше 8.2 патчей, судя по отчётам, не получают.
- Атаки в дикой природе начались до выхода патча.
Хронология
| Дата | Событие |
|---|---|
| 1 августа | Calif находит несколько путей к RCE |
| 11 августа | Calif сообщает о первой проблеме в PHP, начинается скоординированное раскрытие |
| 24 августа | Wiz Research сообщает об уязвимостях в PHP |
| 20 октября | PHP публикует предварительное уведомление о релизе; информация утекает раньше срока эмбарго, watchTowr подтверждает RCE |
| 21 октября, 07:43 UTC | Cloudflare сообщает о первых атаках на PHP-сайты и выкатывает правила WAF |
| 21 октября, 14:00 UTC | Выходят исправленные версии |
Эмбарго сломалось за сутки до плана. Расчёт «подождём, пока появятся детали» не сработал: окно между утечкой и началом сканирования оказалось нулевым.
Что известно о самих уязвимостях
Подробностей эксплуатации я здесь не привожу. Публично известно следующее:
- Уязвимости находятся в ядре PHP, в нативном слое разбора входящих запросов, то есть срабатывают до выполнения кода приложения. Дополнительные расширения для них не нужны.
- В ряде публикаций упоминается связь с обработкой multipart-загрузок. Подтверждения в официальных источниках я не видел, поэтому относитесь к этому как к рабочей гипотезе.
- Исследователи подтвердили неаутентифицированное RCE в Magento 2.4.9, Drupal, WordPress и ещё десятке PHP-приложений. Это не проблема отдельного CMS: уязвим сам рантайм.
Кто в зоне риска
Практически любой, кто держит PHP снаружи:
- веб-серверы с Apache + mod_php, nginx + PHP-FPM, FrankenPHP и аналогами;
- контейнеры и образы (в том числе базовые образы, которые давно не пересобирались);
- shared-хостинг и панели управления;
- CI/CD-образы и dev-стенды, доступные из интернета;
- устаревшие внутренние сервисы, о которых «все забыли».
Отдельная боль: по оценке Mallory, около 884 000 интернет-доступных PHP-хостов работают на ветках без исправления. Если у вас PHP 7.x, 8.0 или 8.1, патча ждать не стоит. Нужна миграция или компенсирующие меры.
План действий
1. Инвентаризация (сегодня)
Найдите всё, где крутится PHP. Быстрые проверки на хосте:
bash
php -v
php-fpm -v 2>/dev/null
dpkg -l | grep -i php # Debian/Ubuntu
rpm -qa | grep -i php # RHEL-семейство
Для контейнеров проверьте версии в запущенных образах:
bash
docker ps --format '{{.Names}}' | xargs -I{} sh -c 'echo {}; docker exec {} php -v 2>/dev/null | head -1'
Для сетевого поиска используйте то, что уже есть в инфраструктуре: asset-инвентарь, сканеры, баннеры Server и X-Powered-By.
2. Обновление
Цель: 8.5.12, 8.4.27, 8.3.36 или 8.2.35, в зависимости от вашей ветки. Если пакеты ставятся из системного репозитория, проверьте, что там действительно появилась исправленная сборка, а не просто ваша текущая версия. У дистрибутивов патчи нередко бэкпортируются без смены номера версии, поэтому смотрите changelog пакета и ссылки на CVE.
Учитывая серьёзность этих уязвимостей, команда по безопасности PHP предоставила минимальные исходные порты для PHP 7.4, PHP 8.0 и PHP 8.1, для ручной сборки необходимых пакетов.
3. Следите за источниками пакетов
- Репозиторий Remi (частый выбор на RHEL, Alma, Rocky): на момент публикации материалов исправления в нём ещё не было. Проверяйте перед тем, как считать узел закрытым.
- Официальные Docker-образы и образы вашего реестра: пересоберите и передеплойте, а не ограничивайтесь
apt upgradeвнутри живого контейнера. - Дистрибутивные пакеты (Debian, Ubuntu, Alpine): следите за security-трекерами.
4. Пока патча нет: компенсирующие меры
- Включите правила WAF вендора (Cloudflare уже выкатил свои). Это замедляет атаку, но не заменяет обновление.
- По возможности ограничьте доступ к публичным PHP-эндпоинтам, в первую очередь к загрузке файлов и админкам: IP-фильтры, VPN, basic auth на уровне веб-сервера.
- Уменьшите ущерб от возможной компрометации: запуск от непривилегированного пользователя,
open_basedir, запрет выполнения PHP в каталогах загрузок, read-only файловая система контейнера, egress-фильтрация.
5. Поиск следов компрометации
Атаки начались до выхода патча, поэтому «обновился» не равно «чист». Проверьте:
- логи веб-сервера за последние дни на необычные POST-запросы, особенно multipart, с аномальными размерами и заголовками;
- новые и изменённые PHP-файлы в каталогах веб-приложения и загрузок (
find . -name '*.php' -mtime -7); - неожиданные дочерние процессы у php-fpm и веб-сервера (sh, curl, wget, nc);
- исходящие соединения с веб-серверов на неизвестные адреса;
- новые cron-задачи, SSH-ключи и учётные записи.
Если нашли признаки компрометации, обновления недостаточно: изолируйте узел, снимите образ для разбора, ротируйте секреты (ключи приложений, пароли БД, токены).
Что с неподдерживаемыми версиями
Если у вас PHP 7.x или 8.0/8.1, варианты такие:
- Мигрировать на 8.2+ (лучше на 8.4 или 8.5). Это основной путь.
- Если миграция займёт недели, закройте сервис за VPN или WAF и ограничьте поверхность атаки.
- Уточните у поставщика своего дистрибутива или коммерческой поддержки (например, у вендоров extended support), собираются ли для вашей ветки бэкпорты. Не рассчитывайте на это без письменного подтверждения.
Оговорки
- Технические детали уязвимостей на момент написания в открытых источниках скудны. Всё, что выходит за рамки вышеперечисленного, считайте предположением.
- Расходятся оценки по версиям: сначала ожидали патчи для 8.0 и выше, затем в отчётах фигурировала граница 8.2. Ориентируйтесь на официальные релизные заметки.
- Если вы нашли уточнения, расскажите в комментариях: тема развивается быстро.
Источники
- Анонс PHP security team «Upcoming Critical PHP Security Release» (php.net / PHP Foundation), 20 октября 2026
- Релизы php-src: 8.5.12, 8.4.27, 8.3.36, 8.2.35
- Sansec, «PHP2Shell» (хронология, подтверждённая эксплуатация)
- The Hacker News, «PHP2Shell: Two Unpatched Critical PHP RCE Flaws»
- Mallory, «PHP RCE in 8.5 and Earlier» (оценка числа хостов без исправления)
- runZero, «Critical RCE vulnerability in PHP: Find impacted assets»
- Laravel News, «Critical PHP Security Release Coming Tomorrow»