PHP2Shell: как закрыть RCE в PHP (CVE-2026-109618) на VPS

Что раскрыли и каких версий PHP это касается

21 октября 2026 команда безопасности PHP объявила о двух критических уязвимостях в php-src, ядре PHP. Оба объявления в рассылке oss-security указывают один и тот же диапазон версий и одну оценку, CVSS v4.0 9,2:

• CVE-2026-109618 (объявление, NVD): PHP использует longjmp(), чтобы прервать запрос при нехватке памяти. Сбой выделения памяти может прервать инициализацию, когда незавершённое состояние запроса уже доступно, а при завершении запроса PHP может обратиться к этому некорректному состоянию. Команда пишет, что удалённое выполнение кода без аутентификации показали по HTTP на Apache mod_php ещё до запуска кода приложения. Анализ исходников указывает, что PHP-FPM тоже уязвим, но полный эксплойт для FPM на тот момент не показали.
• CVE-2026-109619 (объявление, NVD): PHP хранит глобальное состояние, которое временно указывает в память запроса. Если оно сброшено неправильно, следующий запрос в том же воркере может обратиться к нему после освобождения памяти, то есть возникает use-after-free. Команда сообщает, что удалённое выполнение кода без аутентификации показали и на mod_php, и на PHP-FPM, а возможность эксплуатации зависит от состояния, настроек и приложения.

Затронутые версии по заявлению команды безопасности PHP: PHP 8.2 до 8.2.35, 8.3 до 8.3.36, 8.4 до 8.4.27 и 8.5 до 8.5.12. В данных php.net о релизах версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12 датированы 21 октября 2026. Позднее сообщение в той же рассылке цитирует пост CrowdStrike, где сказано, что лежащий в основе шаблон ошибки впервые вышел в PHP 7.3.0 в декабре 2018, поэтому старым веткам, которые больше не получают исправлений, тоже стоит уделить внимание; сам пост мы не читали.

О временных мерах команда PHP говорит прямо: для CVE-2026-109618 единственная полная мера это обновление, а для CVE-2026-109619 полного универсального обходного решения через настройки нет. Arctic Wolf называет уязвимыми конфигурации PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed и считает mod_php самой рискованной. WAF не заменяет обновление: ошибка в том, как PHP работает с памятью, а не в коде вашего приложения.

Кто это эксплуатирует по данным CISA и Arctic Wolf

Два независимых источника говорят, что уязвимость не просто раскрыта, а используется.

Первый источник, CISA. В JSON-ленте KEV (версия каталога 2026.11.04) у CVE-2026-109618 и CVE-2026-109619 стоит dateAdded 2026-10-26 и dueDate 2026-10-29. В каталог KEV попадают только уязвимости с надёжными данными об эксплуатации в реальных атаках, значит, эксплуатация подтверждена; что означает этот порог, см. в глоссарии: KEV.

Второй источник, Arctic Wolf Labs: в посте от 22 октября сообщается о массовом сканировании и попытках эксплуатации вскоре после раскрытия. В основном это были проверки: запросы, которые включают функцию session upload-progress в PHP с заданным атакующим идентификатором сессии и загружают около 63 КБ повторяющихся данных, а также попытки отравления сессии и включения локального файла. Один сканер представлялся user agent php2shell-scan/109618.

Arctic Wolf также выделил вероятно боевые запросы с адреса 92.118.112[.]100, которые выполняли id, печатали маркерную строку, переходили в /tmp и скачивали файл через wget. На стоящей за ними инфраструктуре лежали бинарные файлы ботнета Potassium, семейства на основе Mirai. Arctic Wolf аккуратен в двух вопросах, и мы это повторяем: по его телеметрии не видно, что эти запросы действительно скачали или запустили бинарные файлы, а записи запросов сами по себе не доказывают ни уязвимость цели, ни выполнение кода.

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

Уязвимость ядра Linux, которую CISA связывает с PHP2Shell

28 октября CISA добавила в тот же каталог CVE-2026-46300, уязвимость ядра Linux, со сроком 31 октября. В тексте каталога сказано, что её можно связать с CVE-2026-109618 и CVE-2026-109619, чтобы поставить веб-шеллы на PHP и выполнять команды от root. Это важно, потому что PHP работает от имени веб-пользователя: сама по себе ошибка PHP даёт атакующему права этого пользователя, а локальная уязвимость ядра это шаг от них к полному контролю над машиной.

Сама ошибка ядра не новая. Запись в NVD опубликована 23 мая 2026. Она относится к коду объединения сетевых буферов в ядре, который теряет пометку о разделяемых фрагментах памяти, из-за чего расшифровка ESP-пакетов на месте может происходить поверх памяти, связанной с кэшем страниц. Иными словами, можно изменить кэшированные данные файлов, которые менять нельзя.

Хорошая новость: исправления есть в ядрах дистрибутивов уже несколько месяцев. Трекер безопасности Debian показывает исправление в Debian 12 (bookworm) начиная с ядра 6.1.174-1 (DSA-6306-1), в Debian 13 (trixie) с 6.12.90-1 (DSA-6295-1) и в Debian 11 (bullseye) с 5.10.257-1 (DLA-4606-1). Сервер, который ставил регулярные обновления и перезагружался, скорее всего уже защищён. Но есть нюанс с перезагрузкой: установленный, но не запущенный пакет ядра не защищает. Привычку, которая это предотвращает, описывает руководство по управлению обновлениями, а также термин live patching ядра.

Как проверить, исправлен ли ваш сервер

Начните с того, что работает, а не с того, что установлено. На сервере может стоять несколько версий PHP, а веб-сервер смотрит только на одну.

# какой PHP использует веб-часть
ps -eo pid,user,args | grep -E "php-fpm|apache2|httpd" | grep -v grep | head

# версия PHP в командной строке и установленные пакеты
php -v | head -1
dpkg -l | grep -E "^ii +php[0-9.]+-(cli|common|fpm)"      # Debian и Ubuntu
rpm -qa | grep -E "^php-(cli|common|fpm)"                   # семейство RHEL

Не полагайтесь только на номер версии. Дистрибутивы обычно переносят исправление в свой пакет и оставляют номер из upstream. Мы проверили это на текущих сборках пакетов: в Debian 12 пакет PHP 8.2 называется 8.2.35-1~deb12u1 и php -v показывает 8.2.35, а в Ubuntu 24.04 пакет PHP 8.3 8.3.6-0ubuntu0.24.04.13 по-прежнему сообщает PHP 8.3.6, хотя содержит патч с именем CVE-2026-109618_109619.patch. То есть сервер Ubuntu с версией 8.3.6 может быть исправлен. Надёжная проверка это журнал изменений пакета:

zgrep -h -m2 -E "CVE-2026-1096(18|19)" /usr/share/doc/php*/changelog*.gz

В Debian 12 команда вывела строки «Fix CVE-2026-109618 and CVE-2026-109619» для пакета 8.2.35, а в Ubuntu 24.04 вывела имя патча. Пустой вывод значит, что пакет не упоминает исправление: обновите его или посмотрите трекер дистрибутива, например запись в трекере Debian. Для версий из upstream или стороннего репозитория сравните номер с исправленными релизами из первого раздела.

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

Что делать и в каком порядке

1. Обновите PHP. В Debian и Ubuntu: sudo apt update && sudo apt upgrade (или только пакеты PHP). В семействе RHEL: sudo dnf upgrade "php*". Для стороннего репозитория берите сборку 8.2.35, 8.3.36, 8.4.27, 8.5.12 или новее.
2. Перезапустите то, что загружает PHP. Обновление пакета обычно перезапускает PHP-FPM, но проверьте через systemctl status php8.3-fpm (подставьте версию), что время запуска позже обновления. При mod_php перезапустите Apache: sudo systemctl restart apache2.
3. Обновите ядро и перезагрузитесь. Установите отложенные обновления и сравните uname -r с самым новым установленным ядром (ls /boot/vmlinuz-*). Если они разные, перезагрузите сервер в плановое окно.
4. Проверьте признаки взлома командами только для чтения из следующего раздела, начиная с 21 октября, даты раскрытия. Обновление закрывает дверь, но не выгоняет того, кто уже вошёл.
5. Запишите, что сделано. Зафиксируйте версию пакета PHP, дату и ядро, чтобы следующее уведомление заняло минуты. Подходящий порядок действий показывает руководство по управлению обновлениями.

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

Проверки только для чтения: следы взлома

Эти команды ничего не меняют. Это наши предложения, где атакующий, использующий такую цепочку, оставил бы следы, исходя из поведения, которое описывают Arctic Wolf и CISA. Если ничего не нашлось, это не доказывает чистоту сервера: опытный атакующий может скрыть файлы и очистить журналы.

# 1. PHP-файлы, созданные или изменённые после раскрытия (веб-шеллы это PHP-файлы)
sudo find /var/www -type f -name "*.php" -newermt 2026-10-21 -ls 2>/dev/null | head -50

# 2. файлы во временных каталогах (наблюдавшаяся нагрузка попадала в /tmp)
sudo find /tmp /var/tmp /dev/shm -type f -newermt 2026-10-21 -ls 2>/dev/null

# 3. user agent сканера и названный адрес источника в логах веба
sudo grep -rIl -e "php2shell-scan" -e "92\.118\.112\.100" /var/log 2>/dev/null

# 4. исходящие соединения и кто их держит
sudo ss -tupn state established | head -40

# 5. новые задания планировщика и новые учётные записи
sudo ls -la /etc/cron.d /var/spool/cron 2>/dev/null
sudo awk -F: '$3 == 0 {print $1}' /etc/passwd

Проверка 1 самая полезная: PHP-файл в каталоге загрузок или недавно изменённый файл там, куда ваши деплои не пишут, классический признак веб-шелла. Если вы используете WordPress, выполните в каталоге сайта ещё и wp core verify-checksums: команда сравнивает файлы ядра с официальными контрольными суммами. Если что-то выглядит подозрительно, остановитесь и перейдите к руководству по реагированию на взлом: сначала изолируйте сервер, сохраните журналы и меняйте секреты с чистой машины. Постоянный разбор журналов описан в материале мониторинг и анализ логов.

Как ограничить ущерб от следующей ошибки в PHP

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

• Запускайте PHP от непривилегированного пользователя, отдельного для каждого сайта. В PHP-FPM заведите для каждого сайта свой пул и пользователя без прав sudo и без записи за пределами своих каталогов. О служебных учётных записях и узких правилах sudo рассказывает руководство sudo и минимальные привилегии.
• Делайте корень сайта только для чтения для пользователя PHP, кроме каталогов загрузок и кэша, и не выполняйте PHP из каталогов загрузок. Веб-шеллу нужно куда-то записаться.
• Обновляйтесь по расписанию, а не по новостям. Оба исправления PHP вышли в день раскрытия. Автоматические обновления безопасности, как в термине unattended-upgrades, закрывают этот разрыв для большинства серверов.
• Следите за изменениями файлов. Контроль целостности файлов в корне сайта превращает тихий веб-шелл в оповещение.
• Знайте, что у вас запущено. Список серверов с версиями PHP делает день вроде 21 октября десятиминутной задачей. Отправная точка: чек-лист безопасности VPS.

Это ещё и пример того, как быстро закрывается окно. В нашем обзоре KEV за октябрь в каталоге ещё не было записей про ядро Linux, GitLab и WordPress. К 3 ноября появились все три, и ещё PHP. Продолжение про WordPress: ядро WordPress, CVE-2026-119977.