PHP2Shell: уязвимости PHP CVE-2026-109618 и 109619 — что делать

Обновлено: 08.11.2026, по данным php.net, CVE.org, NVD и CISA. Первая версия статьи вышла 21.10.2026, до публикации исправленного выпуска PHP.

Если хостинг в конце октября прислал письмо о срочном обновлении PHP, а в новостях писали про «PHP2Shell», речь шла об одном событии: в самом PHP, а не в CMS или плагинах, нашли две критические уязвимости. 21 октября 2026 года PHP выпустил исправления, 26 октября американское агентство CISA внесло обе уязвимости в каталог реально эксплуатируемых. Ниже собрано то, что официально подтвердили PHP и базы CVE, то, что остаётся неподтверждённым, и порядок действий для владельца сайта: как проверить, обновлён ли сервер, кто должен это делать и что делать с сайтом на PHP 8.1 или более старой версии.

Что произошло: хронология с 20 по 26 октября

20 октября команда безопасности PHP опубликовала на php.net предварительное уведомление: 21 октября в 14:00 UTC (17:00 по Киеву) выйдет выпуск, который закроет две критические уязвимости с оценкой 9,2 по шкале CVSS v4.0. CVSS — общепринятая шкала опасности уязвимостей от 0 до 10, оценки от 9,0 относятся к критическому уровню. Ещё до выпуска детали утекли в сеть, и исследователи назвали событие «PHP2Shell». Это название придумали не в PHP.

21 октября, как и было назначено, PHP выпустил версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35 и опубликовал бюллетень безопасности. В тот же день записи CVE-2026-109618 и CVE-2026-109619 появились в базах CVE.org и NVD, а Ubuntu выпустила исправленные пакеты. Debian выложила обновления для Debian 12 и 13 в репозитории безопасности.

23 октября PHP добавил информационное уведомление о настройке session.upload_progress.enabled (о ней ниже). 26 октября CISA внесла обе уязвимости в каталог эксплуатируемых уязвимостей KEV со сроком устранения для федеральных ведомств США до 29 октября. Попадание в KEV означает, что у CISA есть подтверждение атак с использованием этих уязвимостей.

Что официально подтверждено

Источники раздела — php.net, бюллетени PHP на GitHub, записи CVE.org и NVD, каталог CISA KEV.

• Тип уязвимостей. PHP называет обе уязвимости удалённым выполнением кода без авторизации (RCE, remote code execution): атакующий может запустить на сервере свои команды, не имея учётной записи. CVE-2026-109618 — «RCE через повреждение памяти при нехватке памяти», CVE-2026-109619 — «RCE через устаревшее глобальное состояние». Обе оценены в 9,2 по CVSS v4.0; NVD дополнительно оценила их по CVSS v3.1 в 9,8 и 8,1.
• Кто под угрозой. Все установки PHP, которые обслуживают веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск PHP видит для mod_php: там продемонстрирована атака, при которой запрос без авторизации срабатывает до запуска кода сайта.
• Исправленные версии. 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Все более ранние выпуски этих веток уязвимы, в том числе 8.2.34, 8.3.35, 8.4.26 и 8.5.11 от 24 сентября 2026 года.
• Старые ветки. PHP 8.1 и старше обновлений от проекта PHP не получают: поддержка 8.1 закончилась 31 декабря 2025 года, 8.0 — в ноябре 2023-го. Из-за серьёзности случая команда безопасности PHP в виде исключения выложила на GitHub минимальные исправления исходного кода для 7.4, 8.0 и 8.1. Это не готовые выпуски, они рассчитаны на тех, кто собирает PHP из исходников сам. Дистрибутивы Linux и поставщики расширенной поддержки получили исправления заранее. NVD указывает уязвимые диапазоны с версии 7.3.0 для CVE-2026-109618 и с версии 5.4.0 для CVE-2026-109619.
• Полной защиты без обновления нет. В каждом объявлении о выпуске PHP повторяет: полных обходных мер не существует, обновление — единственный безопасный выбор. Временные настройки снижают риск только для отдельных путей атаки.
• Атаки идут. Это подтверждение CISA (каталог KEV, статус эксплуатации «активная» в записях NVD). Сам PHP о замеченных атаках в бюллетенях не писал.
• Поддержка 8.2 заканчивается 31 декабря 2026 года. PHP напомнил об этом в объявлении о выпуске 8.2.35.

Что остаётся неподтверждённым

• Масштаб атак. В первые часы после утечки о первых атаках сообщал технический директор Cloudflare, CERT-EU в бюллетене 2026-018 ожидала массовую эксплуатацию. Факт атак CISA подтвердила, но ни PHP, ни CISA не публиковали данных о числе пострадавших сайтов и применяемых вариантах атак.
• «Уязвимы все версии начиная с PHP 5». Формулировка пришла из соцсетей, на неё ссылалась CERT-EU. Бюллетени PHP перечисляют только ветки 8.2–8.5, исправления кода для старых веток PHP выпустил для 7.4, 8.0 и 8.1. Диапазон NVD для CVE-2026-109619 начинается с 5.4.0, но это оценка NVD, а не заявление PHP.
• Работоспособность публичных «эксплойтов». Код, который в октябре выдавали за инструмент атаки, надёжные источники не проверяли. Ссылок на такой код и описания механики атаки в статье нет: владельцу сайта они не помогут.

Что сделать, если сервер ещё не обновлён

С выхода исправлений прошло почти три недели. Если хостинг или администратор до сих пор не подтвердил обновление, проверьте это сегодня.

Как узнать версию PHP

В WordPress версия видна в разделе «Инструменты → Здоровье сайта», вкладка «Информация», блок «Сервер». На любом другом движке версию показывает панель хостинга (cPanel, Plesk, ISPmanager и аналоги) в разделе выбора версии PHP. Все способы, включая проверку фоновых задач (cron), разобраны в статье PHP 8.1/8.2 без поддержки: что делать владельцу сайта.

Сравните номер с исправленными: 8.2.35, 8.3.36, 8.4.27, 8.5.12 или новее. Если номер меньше, сайт уязвим, за одним исключением — пакеты дистрибутивов Linux (о них ниже). Если у вас 8.1, 8.0 или 7.x, переходите к разделу о старых версиях.

Кто обновляет PHP

На обычном (виртуальном) хостинге обновить PHP на сервере может только хостинг-провайдер, вы можете лишь выбрать ветку в панели. Если провайдер не писал об обновлении, спросите поддержку прямо: установлены ли выпуски 8.2.35, 8.3.36, 8.4.27 и 8.5.12 или исправленные пакеты дистрибутива.

На VPS или выделенном сервере PHP обновляет тот, кто администрирует сервер: ваш системный администратор, подрядчик или вы сами. Если VPS не управляемый, провайдер в систему не заходит и PHP за вас не обновит. После обновления проверьте две вещи:

• После обновления пакетов нужно перезапустить PHP-FPM или веб-сервер: работающие процессы держат в памяти старый код, и без перезапуска сайт остаётся уязвимым. PHP в бюллетене требует перезапускать каждый рабочий процесс. Перезапуск оборвёт запросы, которые обрабатываются в этот момент, и посетители на несколько секунд могут увидеть ошибку 502. Перезапустите и фоновые PHP-процессы, например обработчики очередей.
• В Debian, Ubuntu, RHEL и других дистрибутивах исправления часто переносят в пакет без смены основной версии PHP. Пример из этого случая: в Ubuntu 24.04 исправленный пакет называется php8.3 8.3.6-0ubuntu0.24.04.13, и php -v по-прежнему показывает 8.3.6. Проверять нужно версию пакета и бюллетень безопасности дистрибутива (для Ubuntu — USN-8948-1), а не только цифры PHP.

PHP есть не только у основного сайта. Проверьте тестовые копии, CRM и учётные порталы, образы Docker (их нужно пересобрать на исправленной версии) и панели управления сервером, у которых своя сборка PHP.

Обновление внутри ветки безопасно

Переход с 8.3.35 на 8.3.36 и переход с 8.2 на 8.3 — разные по риску операции. По правилам выпуска PHP версии вида x.y.z → x.y.z+1 содержат только исправления ошибок и сохраняют обратную совместимость. В ветках 8.2 и 8.3 выпуски от 21 октября содержат ровно одно изменение — исправление двух уязвимостей. Код, который работал на 8.3.35, заработает и на 8.3.36.

Смена ветки (8.2 → 8.3) — другое дело. В каждой новой ветке есть раздел «несовместимые изменения» и список устаревших функций, старые плагины и модули на ней могут сломаться. Смену ветки проверяют на копии сайта, а исправление безопасности внутри ветки ставят сразу. Бэкап перед обновлением сделайте в любом случае.

Сайт на PHP 8.1 и более старых версиях

Официальных выпусков для 8.1 и более ранних веток нет и не будет: по политике PHP ветка с истёкшим сроком поддержки исправлений не получает. Исправления исходного кода для 7.4, 8.0 и 8.1 на GitHub пригодятся только администратору, который собирает PHP сам.

Для остальных путь один — пакеты дистрибутива или поставщика расширенной поддержки. Ubuntu 22.04 получила исправленный пакет php8.1, для Ubuntu 20.04, 18.04 и 16.04 исправления вышли в платной программе ESM (PHP 7.4, 7.2 и 7.0). Если сайт на VPS со старой системой, спросите администратора, вышло ли исправление для вашего пакета PHP. На обычном хостинге задайте тот же вопрос провайдеру.

Если исправленного пакета для вашей версии нет, варианты такие:

1. Перевести сайт на поддерживаемую ветку, лучше на 8.3 или новее: поддержка 8.2 заканчивается 31 декабря 2026 года. Порядок перехода описан в статье о конце поддержки PHP 8.2.
2. Пока переход не завершён, убрать сайт из открытого интернета или закрыть его фильтром (см. временные меры ниже).
3. Сайт, который не приносит денег и не нужен, выключить до перехода.

Оставлять сайт на PHP 8.1 без исправления теперь, когда атаки подтверждены, мы не советуем. У веток без поддержки впереди будут и следующие уязвимости.

Временные меры по данным PHP

Ни одна из мер ниже не заменяет обновление: по формулировке PHP, они снижают риск для отдельных путей атаки, но не делают установку безопасной. Список взят из бюллетеня PHP от 21 октября. До выпуска официальных рекомендаций не было, и в первой версии статьи настройка session.upload_progress.enabled шла как неофициальная.

Настройки из бюллетеня PHP

Для CVE-2026-109618 PHP советует задать memory_limit=-1 так, чтобы приложение не могло переопределить значение (через php_admin_value в пуле PHP-FPM или конфигурации Apache), и проверить, что ни одна настройка пула, каталога или сайта не возвращает конечный лимит. Вторая мера — ограничить размер запроса: post_max_size = 8M для сайтов без загрузки файлов, post_max_size = 32M, если загрузка нужна; upload_max_filesize должен быть меньше post_max_size. Лимиты на размер и состав запроса PHP рекомендует дополнительно задать на уровне веб-сервера или прокси.

Для CVE-2026-109619 PHP советует выключить session.upload_progress.enabled и перезапустить все рабочие процессы. На PHP 8.5 дополнительно — fatal_error_backtraces=0, тоже с перезапуском. Ещё PHP просит убрать из настроек сайта недействительные и устаревшие параметры, которые выдают предупреждения при запуске, и исправить ошибки в коде, которые атакующий может вызвать запросом. Скрывать предупреждения через error_reporting, display_errors или @ бесполезно.

Отключение session.upload_progress.enabled

По руководству php.net, session.upload_progress.enabled включает отслеживание хода загрузки файлов через сессию и по умолчанию включена (значение 1). Настройка нужна только индикаторам загрузки, которые отдельным запросом спрашивают у сервера прогресс из сессии PHP. Такие встречаются редко: обычная полоса загрузки, которую считает браузер, от настройки не зависит. Сама загрузка файлов после отключения работает как прежде. Английская версия руководства и независимо от этих уязвимостей советует отключать настройку там, где индикаторы прогресса не используются.

Где менять. Режим настройки — INI_PERDIR, то есть формально её принимают php.ini, .htaccess (если PHP работает модулем Apache), httpd.conf и .user.ini. Но PHP в бюллетене требует задавать её там, где значение применяется до разбора запроса: в php.ini, пуле PHP-FPM или конфигурации сервера. На ini_set() и на .user.ini при PHP-FPM полагаться нельзя. В php.ini строка такая:

session.upload_progress.enabled = Off

В httpd.conf (PHP модулем Apache):

php_admin_flag session.upload_progress.enabled off

php_admin_flag, в отличие от php_flag, нельзя переопределить через .htaccess. В пуле PHP-FPM на VPS — php_admin_flag[session.upload_progress.enabled] = off, после этого перезапустите PHP-FPM.

На обычном хостинге настройку меняют в панели (раздел параметров PHP), если провайдер её туда вынес. Если такого пункта нет, попросите поддержку хостинга поменять настройку на уровне сервера: файл .user.ini в корне сайта для этой меры PHP считает ненадёжным. Затем проверьте результат: в выводе phpinfo() (его покажет администратор или поддержка) у session.upload_progress.enabled должно стоять Off.

Оставить ли настройку выключенной после обновления. 23 октября PHP опубликовал информационное уведомление: до следующего планового выпуска PHP предлагает держать session.upload_progress.enabled=0, чтобы закрыть ещё один маловероятный путь атаки (CVE-2026-115560). Проблема возникает только при необычном сочетании настроек и кода приложения, поэтому PHP закрывает её в обычном цикле выпусков. Если вы выключили настройку в октябре, оставьте её выключенной; если индикаторы прогресса загрузки вам не нужны, выключить её имеет смысл и на обновлённом сервере.

WAF

WAF (Web Application Firewall) — фильтр запросов перед сайтом. Cloudflare выпустил правила для известных вариантов атаки, они доступны и на бесплатном тарифе; сам Cloudflare называет их временной мерой. Фильтр защищает только трафик, который через него идёт: если адрес сервера известен, атакующий обойдёт WAF и пойдёт на сервер напрямую. WAF имеет смысл только вместе с правилом «сервер принимает запросы лишь от WAF», и даже тогда правила ловят только известные варианты атаки.

Изоляция

CERT-EU советовала там, где обновить сразу нельзя, убрать доступные из интернета приложения из публичной сети до установки исправлений. Для бизнеса это значит: внутренние системы, админки, CRM и учётные порталы на PHP закрыть за VPN или ограничить доступ по IP-адресам офиса. Публичный сайт так не спрячешь, для него остаются WAF или временное отключение.

Признаки взлома сайта

Исправления вышли 21 октября, атаки подтверждены. Если сервер обновили с задержкой в несколько дней, проверьте его на такие признаки:

• на сервере появились незнакомые PHP-файлы, особенно в папках загрузок;
• в админке появились пользователи, которых никто не создавал;
• хостинг сообщает о резком росте нагрузки, рассылке спама или блокирует аккаунт;
• поиск или браузер показывают предупреждение об опасном сайте, посетителей перенаправляет на чужие страницы;
• в планировщике задач (cron) появились неизвестные задачи;
• для администратора сервера: процессы PHP-FPM или веб-сервера запускают командную оболочку, curl или wget.

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

Чем поможет RIVERIT

Клиентам на техподдержке отвечаем в течение часа, инциденты чиним и вне рабочего времени, если это входит в тариф. Для VPS и выделенных серверов предлагаем администрирование: firewall, изоляцию сайтов друг от друга, анализ логов, а при атаках подключаем защиту от DDoS. Если признаки взлома уже есть, берёмся за восстановление сайта. Тем, кому нужен сервер вместе с обслуживанием, предлагаем защищённый хостинг на серверах в Европе с ежедневными бэкапами в отдельное хранилище.