PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 устраняют критические уязвимости PHP2Shell

21 октября команда PHP выпустила версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Это экстренный выпуск безопасности: он устраняет две критические уязвимости, CVE-2026-109618 и CVE-2026-109619, с оценкой 9,2 по CVSS v4.0. Вместе они получили название PHP2Shell. Обе позволяют выполнить код на сервере без аутентификации. О предстоящем выпуске и утечке сведений об уязвимостях мы писали накануне.

Бюллетень безопасности на сайте php.net. Изображение: Comss.ru

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

Что исправлено

CVE-2026-109618 – удаленное выполнение кода через повреждение данных при нехватке памяти. Обработка нехватки памяти может прервать PHP в момент, когда внутренние данные запроса инициализированы лишь частично. Затем при очистке запроса PHP может принять эти недействительные данные за корректные.

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

Уязвимы все версии PHP ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12, включая старые ветки 7.x и 5.x.

Кто нашел уязвимости PHP2Shell и есть ли атаки

Уязвимости нашли исследователи Calif, Wiz и OpenAI, причем в поиске участвовал ИИ. OpenAI координировала раскрытие вместе с разработчиками PHP и поставщиками средств защиты. По данным BleepingComputer, у обеих уязвимостей общая причина: при аварийном завершении запроса PHP может оставить память в поврежденном состоянии. CVE-2026-109619, помимо выполнения кода, позволяет обращаться к уже освобожденной памяти и получать ее содержимое.

Проблема старая. По данным Calif, самый ранний уязвимый путь появился еще в PHP 5.4.0, и уязвимости можно эксплуатировать при настройках по умолчанию. В Wiz отмечают, что как минимум одной из них подвержена каждая версия PHP, вышедшая за последние десять лет.

Атаки уже начались. Технический директор Cloudflare Dane Knecht еще до выхода исправлений сообщил, что компания фиксирует первые атаки на эти уязвимости. Для сайтов на PHP за Cloudflare уже действуют правила WAF против известных способов эксплуатации, они доступны всем клиентам, включая бесплатный тариф. Knecht подчеркнул, что это лишь временная защита и обновление нужно установить сразу после выхода. Британский Национальный центр кибербезопасности (NCSC), по данным BleepingComputer, призвал организации немедленно обновить системы с PHP или отключить их до установки исправлений.

Затронуто огромное число серверов. По оценке VirusTotal, PHP работает примерно на 5,1 млн IP-адресов, из них около 3,8 млн доступны хотя бы по одному открытому порту.

Как обновить PHP

Сборки для Windows и архивы исходного кода всех четырех версий можно скачать с нашего сайта или с php.net:

Скачать PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35

Linux. По данным разработчиков PHP, дистрибутивы Linux и поставщики сборок с долгосрочной поддержкой получили исправления заранее, но выпускают их своими сборками и в свои сроки: вечером 21 октября исправленной сборки в штатном репозитории Ubuntu 24.04 еще не было. Следите за бюллетенями безопасности своего дистрибутива. В Debian и Ubuntu порядок такой:

• Узнайте, откуда установлен PHP. В штатных пакетах Debian и Ubuntu номер версии PHP не меняется: исправление переносится в ту же версию, и php -v после обновления покажет прежний номер, например 8.3.6. Исправленная сборка Ubuntu получит номер пакета вида 8.3.6-0ubuntu0.24.04.N со следующим значением N. Если PHP установлен из PPA ondrej/php, php -v после обновления покажет номер нового выпуска, например 8.3.36. Версию пакета показывает команда ниже (строки Installed и Candidate):

apt-cache policy php8.3-fpm

• Проверьте, вышло ли исправление. Обновите списки пакетов и посмотрите, есть ли обновления PHP:

sudo apt update
apt list --upgradable | grep php

• Убедитесь, что сборка закрывает эти уязвимости. В журнале изменений пакета должны быть CVE-2026-109618 и CVE-2026-109619. Для Ubuntu есть также бюллетени безопасности и страницы уязвимостей в трекере CVE – например, CVE-2026-109618. Журнал изменений пакета:

apt changelog php8.3-common | head -40

• Обновите все пакеты ветки, а не только PHP для командной строки. Если установлено несколько веток, например php8.2-fpm и php8.3-fpm, обновить нужно каждую, которая обслуживает сайты:

sudo apt install --only-upgrade 'php8.3*'
# или обновить все пакеты системы:
sudo apt upgrade

• Перезапустите службы. Пакет php-fpm обычно перезапускает службу сам, но лучше сделать это явно – для PHP-FPM и для Apache с mod_php:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

• Проверьте, что работает новая сборка. Время запуска в выводе systemctl status должно быть позже обновления, а утилита needrestart покажет службы, которые еще работают со старыми библиотеками:

systemctl status php8.3-fpm
sudo needrestart -r l

• Не полагайтесь только на автоматические обновления. unattended-upgrades устанавливает исправления безопасности сам, но раз в сутки и со случайной задержкой, поэтому критическое исправление лучше поставить вручную сразу после выхода сборки.

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

В контейнерах, например на официальных образах php:8.x-fpm, обновление пакетов на хосте ничего не дает: нужно скачать новый образ и пересоздать контейнер.

docker pull php:8.3-fpm
# затем пересоздайте контейнер с новым образом

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

Windows. Сборки выложены в виде ZIP-архивов. Разработчики советуют выбирать 64-разрядные сборки (x64), а вариант сборки зависит от способа запуска PHP:

• Thread Safe (TS) – для PHP, загружаемого модулем веб-сервера, например в Apache (mod_php);
• Non Thread Safe (NTS) – для FastCGI, в том числе вместе с IIS, и для командной строки.

Для работы сборок нужен распространяемый пакет Visual C++ для Visual Studio 2015–2022: PHP 8.5 и 8.4 собраны в Visual Studio 2022 (VS17), PHP 8.3 и 8.2 – в Visual Studio 2019 (VS16).

Исходный код. Архивы tar.xz подходят для сборки PHP вручную, их контрольные суммы SHA-256 опубликованы на странице загрузок PHP.

На любой системе после установки перезапустите все рабочие процессы PHP – пулы PHP-FPM, Apache, LiteSpeed и другие, иначе уже запущенные процессы продолжат работать со старой версией. Версию PHP показывает команда ниже, но для штатных пакетов Debian и Ubuntu ориентируйтесь на версию пакета, как описано выше.

php -v

PHP 8.1 и более старые ветки обновлений от команды PHP больше не получают. Часть дистрибутивов и поставщиков сборок с долгосрочной поддержкой переносит исправления в свои пакеты. Для тех, кто собирает PHP сам, команда опубликовала минимальные исправления в отдельных ветках для PHP 7.4, PHP 8.0 и PHP 8.1. Поддержка PHP 8.2 закончится 31 декабря 2026 года, после этого исправлений безопасности для нее не будет.

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

Разработчики перечислили меры, которые закрывают отдельные пути атаки на PHP2Shell, но не делают установку безопасной. Единственное полноценное решение – обновление.

Для CVE-2026-109618:

• задать memory_limit=-1 так, чтобы приложение не могло это переопределить, – например, через php_admin_value в пуле PHP-FPM или в конфигурации Apache – и проверить, что ни один пул, каталог или приложение не возвращает конечный лимит;
• уменьшить post_max_size: 8M для приложений без загрузки файлов и 32M, если загрузка файлов нужна, а upload_max_filesize держать ниже post_max_size;
• ограничить на веб-сервере или прокси размер запроса, число полей ввода, частей multipart и заголовков, а также глубину вложенности, в том числе для запросов без корректного заголовка Content-Length;
• ограничивать память контейнером или cgroup, но не через RLIMIT_AS и RLIMIT_DATA: они сами могут вызвать уязвимый сбой выделения памяти.

Для CVE-2026-109619:

• задать session.upload_progress.enabled=0 в php.ini, пуле PHP-FPM или конфигурации сервера и перезапустить все рабочие процессы – через ini_set() или .user.ini эта мера не работает;
• на PHP 8.5 задать fatal_error_backtraces=0 и перезапустить все рабочие процессы;
• убрать недопустимые или устаревшие настройки, которые выводят диагностические сообщения до инициализации запроса, – скрывать эти сообщения через error_reporting, display_errors или @ бесполезно;
• устранить фатальные ошибки и превышения времени выполнения, которые может вызвать атакующий, в том числе в обработчиках, при загрузке и импорте файлов.

Полные технические подробности приведены в бюллетенях на GitHub по каждой уязвимости: CVE-2026-109618 и CVE-2026-109619.