PHP2Shell: две дыры в самом PHP и что с ними делать

• Что делать. Обновить PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 (или поставить патч своего дистрибутива) и перезапустить все процессы PHP. Других полноценных способов защиты нет, так говорит сама команда PHP.
• Кого касается. Любой сайт или сервис, где PHP отвечает на веб-запросы: WordPress, Bitrix, Drupal, Joomla, Magento, Laravel, Nextcloud, phpMyAdmin и всё остальное. Неважно, через что запущен PHP: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP или LiteSpeed.
• Если сайт на хостинге. Проверьте в панели версию PHP и спросите поддержку, установлены ли исправления от 21 октября.
• Если PHP 8.1 и старше. Официальных релизов не будет. Нужно переезжать на 8.2+ или брать исправления от дистрибутива. Американское агентство CISA советует до обновления вообще отключить такие системы от интернета.

PHP обрабатывает сайт запрос за запросом. Под каждый запрос он берёт кусок памяти, раскладывает туда данные посетителя, а в конце всё убирает. Обе ошибки живут в этой уборке.

• CVE-2026-109618, «нехватка памяти». Если запросу не хватило памяти, PHP аварийно обрывает работу в тот момент, когда данные разложены только наполовину. Уборка после этого принимает недоделанные данные за настоящие. Злоумышленник подбирает такой запрос, чтобы в этой каше оказались нужные ему значения, и получает выполнение своего кода.
• CVE-2026-109619, «вчерашние данные». Часть служебных данных запроса переживает уборку: память уже освобождена, а ссылка на неё осталась. Следующий запрос на том же процессе успевает воспользоваться этими остатками раньше, чем PHP их обнулит. Через это тоже можно выполнить код или прочитать чужие данные из памяти.

Самое неприятное: в некоторых конфигурациях атака срабатывает до того, как запускается код самого сайта. Команда PHP прямо пишет, что для mod_php есть рабочий эксплойт, где запрос без авторизации срабатывает раньше любого кода приложения. Значит, хорошо написанный сайт, плагины и пароли администратора здесь не спасают. Исследователи Wiz показали, что уязвима даже страница «Hello World», а кроме выполнения кода получили чтение памяти процесса, где лежат пароли, токены и ключи API.

Опаснее всего, по оценке команды PHP, Apache с mod_php. На PHP-FPM одну из цепочек атаки исследователи до конца не довели, но вторую подтвердили и там, поэтому FPM тоже нужно обновлять. Исследователи Calif, по данным Sansec, сообщили о рабочем взломе без авторизации на свежих Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony и WHMCS.

Сам облачный провайдер обычно не уязвим, уязвим ваш PHP у него. Google, например, обновил поддерживаемые среды App Engine standard автоматически, а образы в Cloud Run и GKE нужно пересобрать самим. Это общее правило для Docker: базовый образ с PHP сам не обновится.

Время указано по UTC (по Москве плюс три часа). Где источники расходятся, это отмечено.

1. Август
2. 1 авг.

   Исследователи Calif находят в PHP несколько путей к удалённому выполнению кода (по таймлайну Sansec).

3. 11 авг.

   Calif сообщает о первой ошибке команде PHP и запускает скоординированное раскрытие.

4. 19 авг.

   Независимо от них Wiz Research находит первую уязвимость. Помогали ИИ-модели: Wiz называет Gemini 4 Argon и GPT-5.6 Sol, в процессе участвовал проект OpenAI Patch the Planet.

5. 20–21 авг.

   Wiz подтверждает взлом без авторизации на Drupal, потом на WordPress.

6. 24 авг.

   Wiz отправляет отчёт команде PHP.

7. Сентябрь – октябрь
8. 21 сент.

   По таймлайну Wiz, PHP подтверждает проблему и начинает готовить исправление. Дистрибутивы Linux и поставщики долгой поддержки получают патчи заранее.

9. 17 окт.

   Ловушка Amazon (MadPot) фиксирует первую попытку эксплуатации, за четыре дня до раскрытия. Как атакующий узнал о дыре, неизвестно.

10. 20 октября, утечка
11. 20 окт.

    Команда PHP публикует предупреждение: релиз безопасности выйдет 21 октября в 14:00 UTC, обе уязвимости оценены в 9,2.

12. 20 окт.

    Пользователь Hacker News выкладывает номера CVE, называет оценку 10 из 10 и дату раскрытия 22 октября. Пост потом удаляют, но его успевают разнести X и Mastodon. Оценка и дата из утечки оказались неверными.

13. 20 окт.

    watchTowr подтверждает, что уязвимости настоящие и одну из них удалось воспроизвести. Об утечке пишет Хабр.

14. 21 октября, релиз
15. ≈02:00

    Amazon видит первые эксплойты в открытом доступе и атаки с ними на свои ловушки, примерно за 12 часов до релиза.

16. утро

    CERT-EU и британский NCSC выпускают экстренные предупреждения. В Нидерландах на время уходят в офлайн DigiD, MijnOverheid, сайты парламента, NCSC и Tweakers. В Японии похожие меры принимают хостинги и онлайн-сервисы.

17. 07:43

    Cloudflare сообщает о первых атаках и выкатывает правила WAF для клиентов.

18. ≈14:00

    Выходят PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, публикуются бюллетени на GitHub. CISA выпускает предупреждение и призывает обновляться немедленно. Сторонний репозиторий Remi в этот день обновлений не получает.

19. после релиза

    Глава Cloudflare Мэттью Принс пишет о десятках тысяч попыток атак за 45 минут после анонса, сотнях тысяч за два часа и, позже, миллионах.

20. вечер

    В России о проблеме пишут iXBT, vc.ru и другие издания. По оценке, которую приводит iXBT со ссылкой на РБК, под угрозой могут быть десятки тысяч ресурсов Рунета. Методика оценки не раскрыта.

21. 22 октября
22. 22 окт.

    Rapid7: в сети несколько публичных эксплойтов, но каждый работает только на своём сочетании системы, версии PHP и веб-сервера. Надёжного универсального пока нет.

23. 22 окт.

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

24. 22 окт.

    «Рег.ру» временно ограничивает загрузку файлов через панель управления (пользователи видят ошибку 403). Поддержка объясняет это защитой клиентских сайтов, пишут «Коммерсантъ» и iXBT.

1. Узнать, какая у вас версия

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

php -v
php-fpm8.4 -v        # или php-fpm -v, номер зависит от системы
apachectl -M | grep php   # есть ли mod_php

Надёжнее всего посмотреть версию глазами самого сайта: временно положить файл с <?php echo PHP_VERSION;, открыть его и сразу удалить. Учтите, что дистрибутивы вроде RHEL и Ubuntu часто переносят исправление в старую версию, не меняя её номер. Поэтому, если PHP стоит из пакетов системы, сверяйтесь с бюллетенем безопасности своего дистрибутива, а не только с номером. В Debian 13, например, исправленный пакет называется 8.4.27-1~deb13u1.

2. Обновить и перезапустить

• Свой сервер. Поставить обновление из репозитория дистрибутива или собрать исправленную версию с php.net, затем перезапустить PHP-FPM и Apache. Без перезапуска старые процессы продолжат работать с уязвимым кодом.
• Docker и Kubernetes. Пересобрать образы на свежем базовом образе PHP и перевыкатить. Старые образы в реестре остаются уязвимыми.
• Хостинг и конструкторы. Написать в поддержку и попросить подтвердить, что PHP обновлён. Если хостинг предлагает выбрать версию PHP в панели, выбрать ветку 8.2 или новее.
• PHP 8.1 и старше. Это повод наконец переехать. Пока переезд не готов, держите такой сайт за VPN или выключенным, как советует CISA.

3. Если обновиться прямо сейчас нельзя

• Выключить прогресс загрузки сессий. session.upload_progress.enabled=0 в php.ini или в настройках пула FPM, затем перезапустить все процессы. Через ini_set() или .user.ini не сработает, это слишком поздно.
• На PHP 8.5 поставить fatal_error_backtraces=0 и перезапустить процессы.
• Ограничить размер запросов. post_max_size = 8M, если сайт не принимает файлы, или 32M, если принимает, и upload_max_filesize меньше этого. Те же лимиты стоит выставить на веб-сервере или прокси. Если сайт не принимает формы с файлами, можно вообще не пускать multipart-запросы до PHP.
• Память. Команда PHP предлагает задать memory_limit=-1 на уровне сервера, чтобы приложение не могло его поменять, а ограничение памяти перенести в контейнер. Это спорная мера: без контейнерного лимита один запрос может съесть всю память сервера.
• WAF. Cloudflare и Google Cloud Armor выпустили правила против этих атак. CISA пишет, что WAF может дать частичную защиту до обновления.

4. Проверить, не было ли взлома

CISA советует смотреть, не запускают ли процессы PHP командную оболочку и не скачивают ли инструменты. Сюда же относятся новые незнакомые файлы .php в папках загрузок, новые администраторы в CMS и незнакомые задачи в cron. Отсутствие записей в логах ничего не доказывает. Раз через уязвимость можно читать память, разумно после обновления сменить пароли к базам и ключи API, которые лежат в настройках сайта. Это наш вывод, а не официальная рекомендация.

• Насколько всё плохо, мнения расходятся. Amazon и Cloudflare видят массовые попытки атак, счёт шёл на миллионы. Sansec и Rapid7 отвечают, что надёжного универсального эксплойта пока нет и на PHP с настройками по умолчанию публичные эксплойты не срабатывают. Обе стороны правы одновременно: сканируют всех, а получается пока не у всех. Ждать, пока эксплойт станет надёжным, всё равно не стоит.
• Утечка испортила план. Скоординированное раскрытие задумано так, чтобы исправление и описание вышли одновременно. Из-за поста на Hacker News у администраторов оказалось меньше суток, а атакующие начали раньше релиза.
• ИИ нашёл, ИИ атакует. Обе уязвимости нашли команды, которые работали вместе с ИИ-моделями Google и OpenAI. На Хабре и в X это обсуждают как знак новой эпохи: модели находят такие ошибки быстрее людей, и отрасли придётся выпускать патчи чаще.
• Хабр. В комментариях делятся быстрыми мерами: выключить прогресс загрузки сессий, закрыть multipart на прокси, вплоть до блокировки всех POST-запросов. Есть и скептики, которые считают шум преувеличенным, и привычные шутки про PHP. Пакеты для Debian 13 появились в первый день, сторонний репозиторий deb.sury.org выкладывал их постепенно.

Источники: бюллетень и релизы PHP · GHSA по CVE-2026-109618 · GHSA по CVE-2026-109619 · CISA · Wiz Research · Sansec · Rapid7 · Google Cloud · Infosecurity: утечка · Infosecurity: атаки до раскрытия · ThreatLandscape · Patchstack · Хабр · iXBT · iXBT о «Рег.ру» · vc.ru