Уязвимость php2shell в PHP: что случилось и что сделать владельцу сайта

21 октября 2026 года команда PHP выпустила экстренные обновления: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости — CVE-2026-109618 и CVE-2026-109619, которые в отрасли уже называют php2shell. Обе оценены в 9.2 балла по CVSS v4.0: при неудачном стечении обстоятельств злоумышленник может выполнить свой код на сервере, не входя ни в какую админку. Детали утекли в сеть 20 октября, ещё до выхода исправлений, а первые попытки атак Amazon зафиксировал 17 октября. Сейчас идёт массовое сканирование сайтов.

Ниже — что произошло простыми словами, кого это касается и что сделать по шагам.

Наши клиенты могут не беспокоиться: у всех клиентов студии мы закрыли уязвимость сразу после выхода исправлений. Сайт internet10k.com тоже работает на исправленной версии PHP.

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

Обе ошибки сидят в самом PHP, а не в WordPress, Битриксе или коде вашего сайта.

• CVE-2026-109618. Когда PHP разбирает данные формы, особый запрос может исчерпать лимит памяти в неудачный момент. Внутренняя структура остаётся заполненной наполовину, а при очистке PHP обращается с ней как с нормальной. Важно, что это происходит при разборе запроса — до того, как запустится код сайта. Значит, ни авторизация, ни проверки в самом приложении не помогают.
• CVE-2026-109619. Данные одного запроса могут пережить его конец, и следующий запрос, попавший в тот же рабочий процесс PHP, использует уже освобождённую память. Один из путей связан с механизмом session upload progress, который в PHP включён по умолчанию — даже если сайт вообще не использует сессии.

Эксплуатировать уязвимости непросто: нужно точно подобрать запрос и обойти защиту памяти. Но после утечки деталей и начала сканирования рассчитывать на то, что «до нас не доберутся», не стоит.

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

По данным команды PHP, под угрозой любая установка, которая обслуживает веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Выше всего риск у mod_php. Консольный PHP (CLI) в списке не указан.

• Уязвимы все версии ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12.
• PHP 7.4, 8.0 и 8.1 тоже уязвимы, но официальных релизов для них нет — только исходные патчи для тех, кто собирает PHP сам, и исправления от дистрибутивов и LTS-поставщиков.
• PHP 5.4–7.3 уязвимы и исправлений от команды PHP не получат вовсе.

Если сайт на Tilda, Wix или другом конструкторе, сервер обновляет сама платформа — от вас ничего не требуется. Если сайт на своём хостинге или VPS — WordPress, 1С-Битрикс, самописный, — это ваша зона ответственности или вашего подрядчика.

Что сделать: по шагам

1. Узнайте версию PHP сайта. Её показывает панель хостинга (FastPanel, ISPmanager, cPanel), в разделе настроек сайта. Иногда версия видна в заголовках ответа — проверить можно нашим инструментом «На чём сделан сайт». Если он её показал, это само по себе мелкий недочёт: версию лучше скрывать.
2. Обновите PHP до исправленной версии своей ветки. На своём сервере — пакетами дистрибутива или из панели. На виртуальном хостинге проверьте, что провайдер уже обновил PHP: многие сделали это 21–23 октября, но не все. Если в панели можно выбрать ветку, переключитесь на поддерживаемую.
3. Перезапустите PHP-процессы. Без перезапуска PHP-FPM или Apache работают старые воркеры со старым кодом.
4. Если сайт на PHP 8.1 и ниже, планируйте переезд на актуальную ветку. Старые плагины и самописный код могут потребовать доработки — это проверяют на копии сайта, а не в бою.
5. Проверьте логи с 17 октября. Поводы насторожиться: ошибки Allowed memory size ... exhausted ... in Unknown on line 0 (место «Unknown» значит, что сбой случился при разборе запроса), падения процессов с Segmentation fault, POST-запросы с полем PHP_SESSION_UPLOAD_PROGRESS и очень длинными именами полей, а главное — веб-процесс, запускающий командную оболочку. Сам по себе сбой памяти атаку не доказывает, но серия таких ошибок — повод разобраться.

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

Команда PHP предлагает временные меры. Они снижают риск, но не делают сервер безопасным — обновление остаётся единственным полным решением.

• Против CVE-2026-109618: memory_limit = -1 на уровне администратора (так, чтобы сайт не мог это переопределить) вместе с лимитом размера запроса на веб-сервере и ограничением памяти контейнера. Не используйте вместо этого RLIMIT_AS и RLIMIT_DATA — они как раз провоцируют нужный атакующему сбой.
• Против CVE-2026-109619: session.upload_progress.enabled = 0 в основной конфигурации PHP, а на PHP 8.5 ещё и fatal_error_backtraces = 0. Через ini_set() или .user.ini это не работает — настройки должны применяться до разбора запроса.
• После изменений перезапустите все воркеры PHP.

Отдельно: 23 октября PHP опубликовал предупреждение о ещё одной уязвимости, CVE-2026-115560. Она касается только сайтов, которые на лету меняют обработчик сериализации сессий, и исправится в плановом релизе. Если вы не уверены, как устроен ваш код, то же отключение session upload progress закрывает и её.

Что важно после обновления

Проверьте, что сайт открывается, формы отправляются, оплаты проходят, а обмен с 1С и CRM работает. При переходе между ветками PHP иногда ломаются старые плагины. Дальше — регулярные обновления по графику, а не только в дни громких новостей: эта история не последняя, а исправление закрыло конкретные пути, но не весь класс ошибок.

Если не хочется следить за этим самим, возьмём сайт на техническую поддержку: обновления, мониторинг и реакция на инциденты входят в каждый тариф. Отдельно — поддержка сайтов на WordPress и 1С-Битрикс, а если признаки взлома уже есть — лечение сайта.

Источники: анонсы php.net, разборы Datadog Security Labs и Tenable.

Нужна проверка версии PHP или помощь с обновлением — напишите в Telegram или MAX.