PHP2Shell: что я проверяю на своих серверах, когда весь мир латает дыру в PHP

21 октября проект PHP выпустил исправления двух дыр в самом интерпретаторе, CVE-2026-109618 и CVE-2026-109619, их назвали php2shell. Через них можно выполнить код на сервере без логина и пароля, затронуты все версии начиная с PHP 5.4. Если у вашей компании есть сайт, панель или внутренний сервис на PHP, на этой неделе их нужно было обновить. Ниже о том, как такие недели проходят у меня.

Что случилось и почему релиз сдвинули на день

Simon Willison 21 октября пересказал сообщение PHP Foundation: 20 октября около 15:00 UTC номера CVE утекли на форумы с неверной оценкой 10.0 (настоящая 9.2), и проект перенёс релиз с 22 на 21 октября. Одна из фирм, сообщивших об уязвимости, Calif, по ошибке опубликовала видео с рабочим эксплойтом. Там же хронология Wiz: уязвимость нашли 19 августа, 24 августа сообщили команде PHP.

Cloudflare 21 октября объяснил механику: обе дыры в том, как PHP обращается с памятью при ошибке. Отсюда два замечания, которые я бы выписал на стикер: обновление плагина или кода сайта не помогает, чинить надо сам PHP; если PHP обслуживает хостинг, обновление надо требовать у него. Правила WAF Cloudflare включил за 9 часов до раскрытия. 23 октября там же дописали: вышла связанная уязвимость CVE-2026-115560, она есть даже в обновлённом 8.5.12, исправят в следующем плановом релизе.

Ubuntu 21 октября выложил таблицу исправленных пакетов, от php5 в 14.04 до php8.5 в 26.10, и команду для проверки: apt list '?installed ?name(^php[0-9.]+$)'. Там же напоминание: unattended-upgrades поставит патч в течение суток, но процессы PHP от этого не перезапустятся. Docker 22 октября сообщил, что официальные образы обновили в пределах 24 часов после патчей: 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Если обновить сразу не можете, Docker советует выключить систему и ссылается на ту же рекомендацию ФБР.

GitLab 22 октября опубликовал самую практичную, на мой взгляд, памятку. Ubuntu и Red Hat бэкпортируют исправление, сохраняя старый номер версии, поэтому сравнивать надо версии пакетов, а php -v тут обманет. Образы с плавающим тегом вроде php:8.3 пересобирайте с docker build --pull, а производные образы wordpress или drupal получат исправление только после того, как их выпустят мейнтейнеры. И список того, что забывают: внутренний дашборд, сайт маркетинга, образ для CI.

OpenAI 21 октября описал координацию: уязвимость нашла Calif с помощью модели GPT-5.6 Sol, Wiz нашёл её независимо, исправления вели мейнтейнеры PHP, и таких находок OpenAI ждёт больше. OVHcloud 21 октября выпустил инструкцию для владельцев VPS: проверить версию, обновиться, перезапустить службы PHP. Percona 23 октября отчиталась: правила Cloudflare стояли до выхода патча, патч поставили сразу, следов компрометации не нашли.

Почему это касается компании, у которой «нет PHP»

Возьмём прокат автомобилей. Сайт бронирования делал подрядчик три года назад, живёт он на хостинге, и на каком языке написан, в компании никто не помнит. Владелец уверен, что PHP у него нет. По данным Cloudflare PHP работает почти на 70 % сайтов, так что чаще всего он есть, и в том месте, за которое никто не отвечает.

Вывод для владельца: список «что у нас крутится на PHP» нужен до того, как выйдет следующая такая дыра. В спокойную неделю его можно составить за час.

Как это устроено у меня

Для компании в сфере PDR в США я веду сервер с 2022 года: Debian в Google Cloud, на нём база MariaDB, API, сайт и телефония. Вопросы безопасности в компании идут ко мне, и при крупных взломах в мире я проверяю, касается ли это нас. Основной бэкенд у нас на Node.js и Python, но проверку это не отменяет: я прохожу по списку всего, что стоит на сервере и в контейнерах, и смотрю версии пакетов. Сервер, VPN и телефонию я обслуживаю сам, без переписки с подрядчиком. С 2022 года серьёзных сбоев с восстановлением у нас не было.

Сайт студии и сервис «Кофе вместе» живут на общем сервере с 2 ГБ памяти, в Docker за Nginx. Для «Кофе вместе» порядок такой: при обновлении старый экземпляр останавливается до запуска нового, а если сборке не хватает памяти, образ собирается вне сервера и загружается готовым.

Что я бы сделал на этой неделе

1. Составить список всего, где живёт PHP: сайты на хостинге, панели, форумы, Docker-образы, образы для CI.
2. Обновить пакет и перезапустить каждый процесс, который выполняет PHP. Сверять версию пакета.
3. Пересобрать контейнеры с --pull, производные образы проверить по дате выпуска у мейнтейнера.
4. Если обновить сейчас нельзя: включить WAF, ограничить загрузку файлов, в крайнем случае выключить сервис.
5. Посмотреть логи за 20–23 октября на странные запросы и новые файлы и вернуться к теме после следующего релиза PHP.

И держать проверенную резервную копию, из которой вы хоть раз восстанавливались, на случай, если взлом всё-таки был.

Связанные материалы

Зачем системе один сервер, который хранит состояние и проверяет права: статья Сервер: данные, доступ и выполнение процесса. Направление: инфраструктура, которую можно выпускать и восстанавливать. Сервер PDR-компании описан в кейсе технический партнёр PDR-компании в США и на странице Debian в Google Cloud. По той же теме: мой порядок обновления Node.js, Python и Next.js, zero trust для компании из 30 человек и бэкап, который никто не восстанавливал. Раньше я разбирал, как выбирать уязвимости для исправления и что такое SBOM и provenance. Если у вас есть сервер, за который давно никто не отвечает, расскажите, что на нём стоит: Обсудить задачу.