Критические уязвимости в PHP (PHP2Shell)

21 октября 2026 года команда PHP выпустила внеплановые релизы 8.5.12, 8.4.27, 8.3.36 и 8.2.35 в 17:00 по московскому времени, как было объявлено накануне. Изначально публикацию планировали на 22 октября. До этой даты вендоры дистрибутивов, получившие патчи заранее, обязались не раскрывать сведения об уязвимостях. Но 20 октября детали утекли в сеть, и релиз вышел на день раньше.

Обновления закрывают две критические уязвимости: CVE-2026-109618 и CVE-2026-109619. В международной базе обе уязвимости получили 9,2 балла по шкале CVSS и статус «Критический». В тот же день они попали в Банк данных угроз ФСТЭК России.

Неофициальное название этих уязвимостей — PHP2Shell. Обе приводят к удалённому выполнению кода на сервере без аутентификации (RCE, Remote Code Execution). Проблема кроется в самом интерпретаторе, поэтому обновлять CMS или фреймворки бесполезно — нужно патчить PHP.

Что такое PHP2Shell и чем опасны уязвимости CVE-2026-109618 и CVE-2026-109619

PHP2Shell — общее название двух независимых ошибок в ядре интерпретатора PHP. Обе связаны с управлением памятью. В бюллетенях команды PHP среди прочих указан класс ошибки управления динамической памятью (Use-After-Free, CWE-416), но механика у уязвимостей разная.

• CVE-2026-109618 срабатывает при нехватке памяти. Обработка этой ошибки прерывает PHP в момент, когда внутренние данные запроса заполнены лишь частично. При очистке интерпретатор принимает такие данные за корректные.
• CVE-2026-109619 — использование памяти после освобождения. Внутреннее состояние запроса сохраняется после того, как PHP освободил память под ним. Следующий запрос в том же воркере обращается к этому состоянию раньше, чем оно сбрасывается.

В обоих случаях злоумышленник подменяет данные, с которыми работает интерпретатор, и через порчу памяти добивается выполнения своего кода с правами веб-воркера.

Уязвимость находится на уровне самого PHP. Безопасность кода конкретного проекта здесь роли не играет — взломать можно даже сайт из одного файла с echo "Hello World". Обновление CMS, фреймворков и плагинов бесполезно. Защититься поможет только установка патча для интерпретатора.

Обе уязвимости PHP получили 9,2 балла по CVSS 4.0. Для CVE-2026-109619 разработчики PHP дополнительно подтвердили раскрытие памяти. Ошибке, через которую срабатывает уязвимость, не обязательно быть фатальной или попадать в лог, поэтому атака может пройти без следов в журналах.

Кто в зоне риска

Под угрозой — все инсталляции PHP ниже исправленных версий, которые обрабатывают веб-запросы. Официальный бюллетень PHP выделяет PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Уровень угрозы зависит от режима запуска:

• Apache с mod_php — самая опасная конфигурация. Для неё уже продемонстрирован рабочий эксплойт. Атака проходит без аутентификации и запускается до старта пользовательского приложения.
• PHP-FPM — ситуация сложнее. Если старт запроса срывается, FPM завершает дочерний процесс, что закрывает путь для CVE-2026-109618. Полного эксплойта для FPM пока не показали, хотя по анализу кода уязвимость достижима и после нормального старта. Ошибка CVE-2026-109619 затрагивает FPM, когда Nginx или mod_proxy_fcgi передают директивы PHP_VALUE и PHP_ADMIN_VALUE. Вектор атаки через session.upload_progress на FPM уже подтверждён.

Уязвимость находится в ядре интерпретатора. Обновлять необходимо все конфигурации без исключений.

Как обновиться и что обязательно перезапустить

Установка пакета обновляет файлы исключительно на диске. Процессы PHP-FPM, Apache и долгоживущие воркеры продолжают выполнять уязвимый код из оперативной памяти до принудительного рестарта. Приоритет — серверы, доступные из интернета.

1. Обновите пакеты PHP

Установите исправленную версию для вашей ветки: 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Команда PHP заранее передала патчи вендорам дистрибутивов. Проверьте обновления в репозитории своего дистрибутива. Сторонние репозитории могут отставать. Исходный код доступен на официальном сайте php.net.

2. Перезапустите процессы

Перезагрузите все службы, исполняющие PHP. Для Apache с mod_php:

systemctl restart apache2   # Debian, Ubuntu
systemctl restart httpd     # RHEL и производные

Для PHP-FPM перезапуск Nginx бесполезен. Перезагрузите сам процесс интерпретатора. В Debian и Ubuntu имя службы содержит номер версии:

systemctl restart php8.4-fpm   # Debian, Ubuntu
systemctl restart php-fpm      # RHEL и производные

Перезапустите и долгоживущие процессы: воркеры приложений и обработчики очередей. Старый код в памяти они держат так же, как FPM.

3. Пересоберите Docker-образы

Укажите новую версию PHP в слое сборки и пересоберите образ. Затем пересоздайте контейнеры с сохранением томов данных. Обычный рестарт контейнера оставляет систему уязвимой.

4. Проверьте результат

Успешная установка пакета подтверждает только обновление файлов на диске. Проверьте версию на работающем сервере: через phpinfo() или заголовок X-Powered-By в HTTP-ответах, если включён expose_php. Файл с phpinfo() после проверки удалите. Если дистрибутив переносит исправления в старую версию, как RHEL и производные, номер версии не изменится. В этом случае сверяйтесь с changelog пакета или бюллетенем вендора.

5. Примите решение по устаревшим веткам

Ветки 8.1 и более ранние команда PHP больше не поддерживает. Из-за критичности уязвимостей она всё же выложила исправления для PHP 7.4, 8.0 и 8.1, но только в исходном коде — PHP придётся собрать самостоятельно. Готовые пакеты ищите у дистрибутива Linux или поставщика продлённой поддержки.

Если обновиться сразу нельзя

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

• Против CVE-2026-109618: задайте memory_limit=-1 и ограничьте post_max_size до 8M, или до 32M, если нужна загрузка файлов. upload_max_filesize держите меньше post_max_size. Настройки задавайте так, чтобы приложение не могло их переопределить, например через php_admin_value в пуле FPM или конфигурации Apache. Ограничения RLIMIT_AS и RLIMIT_DATA вместо этого не используйте: они сами вызывают уязвимый сбой.
• Против CVE-2026-109619: задайте session.upload_progress.enabled=0 в php.ini, пуле FPM или конфигурации веб-сервера. На PHP 8.5 добавьте fatal_error_backtraces=0.

После изменений перезапустите все воркеры.

Уточнение по CVE-2026-115560

23 октября команда PHP выпустила дополнение об узкой уязвимости CVE-2026-115560 в механизме session.upload_progress. Она срабатывает только при строгом совпадении трёх условий:

1. В конфигурации параметр session.serialize_handler изначально установлен в значение php_binary или php_serialize.
2. Приложение меняет этот обработчик на php в рантайме через ini_set() строго до вызова session_start().
3. Параметр session.upload_progress.enabled остаётся включённым.

Подобная архитектура встречается редко. Команда PHP выпустит подробный отчёт и закроет баг в ближайшем плановом релизе. Дополнительных деталей о CVE-2026-115560 пока не сообщается.

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

Отключайте параметр в php.ini, пуле FPM или конфигурации веб-сервера. Через ini_set() и .user.ini настройка не сработает. После изменения перезапустите все воркеры.

В БДУ ФСТЭК эта уязвимость пока отсутствует.

Какие секреты ротировать после PHP2Shell и в каком порядке

Обе уязвимости дают злоумышленнику удалённое выполнение кода, а CVE-2026-109619 ещё и раскрывает память процесса. Считайте скомпрометированными все секреты, к которым имел доступ интерпретатор PHP.

Начинайте ротацию только после установки патчей или пересборки образов. Действуйте по приоритетам. GitGuardian в разборе PHP2Shell советует составить карту секретов: что защищает каждый из них и к чему приведёт утечка. Порядок ротации задаёт эта карта. Если карты нет, двигайтесь от самого критичного к уровню приложения:

Круг 1. Критичные данные и финансы

• Базы данных — смените пароли от внутренних и внешних БД, указанные в конфигурационных файлах (например, .env или config.php).
• Платёжные шлюзы — отзовите ключи от платёжных систем для блокировки прямых финансовых потерь.

Круг 2. Инфраструктура и деплой

• Облачные провайдеры — обновите ключи управления доступом (IAM), сервисные аккаунты облачных платформ и секреты кластеров.
• Доступ к серверу — замените SSH-ключи, токены доступа к репозиториям кода и ключи деплоя.
• Резервные копии — смените доступы к внешним объектным хранилищам, куда веб-приложение отправляет бэкапы.

Круг 3. Сторонние интеграции

• API-ключи — отзовите и перевыпустите токены для внешних SaaS-продуктов, CRM и сервисов рассылок.
• OAuth-секреты — обновите ключи для социальных авторизаций и федеративных интеграций.

Круг 4. Уровень приложения и сессии

• Ключи шифрования — замените APP_KEY и соли фреймворка, защищающие куки, пейлоады и локальные токены.
• Сессии пользователей — сбросьте активные сессии администраторов и клиентов. Это заставит их авторизоваться заново и инвалидирует украденные сессионные куки.

Аудит логов после ротации

Смена ключей закрывает доступ, но прошлую активность нужно проверить. Ищите:

• в журналах доступа веб-сервера — запросы с подозрительных IP-адресов и необычно большие multipart-запросы;
• на сервере — новые файлы в корне сайта, неожиданные дочерние процессы PHP и исходящие соединения от веб-сервера;
• в системах, к которым вели скомпрометированные секреты, — действия со старыми учётными данными до ротации.

Часто задаваемые вопросы