Уязвимости PHP2Shell: как проверить и обновить сайт на PHP

Что это и как работает

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

Злоумышленнику не нужен логин и пароль: достаточно отправить на сайт специально подготовленный запрос. Если атака удалась, он может запустить на сервере свою программу — то есть получить доступ к тому же, к чему есть доступ у сайта: базе клиентов, заказам, файлам. Кроме того, по данным The Hacker News, через эти ошибки можно прочитать память PHP, где лежат пароли, ключи доступа и данные чужих запросов, — даже не запуская своей программы.

Разработчики PHP описывают две ошибки:

1. CVE-2026-109618. Если запросу не хватает памяти, PHP может прервать работу на полпути, когда служебные данные запроса подготовлены не до конца. При уборке после запроса недоделанные данные принимаются за нормальные — через это и проходит атака.
2. CVE-2026-109619. PHP обрабатывает запросы одной и той же рабочей программой по очереди. После одного запроса в ней могут остаться ссылки на уже освобождённую память, и следующий запрос успевает ими воспользоваться.

Обе ошибки оценены в 9,2 балла из 10. Под угрозой все способы запуска PHP на сервере: PHP-FPM, Apache с модулем mod_php, php-cgi, FrankenPHP и LiteSpeed. Самым опасным разработчики считают Apache с mod_php: для него показана атака, которая срабатывает ещё до того, как начинает работать код сайта. Для PHP-FPM полная атака пока показана только для одной из двух ошибок и зависит от того, что делает сам сайт, — но обновлять такие сайты нужно так же срочно.

Как развивались события. 20 октября команда PHP предупредила о срочном выпуске, а после утечки подробностей выпустила исправления на день раньше — 21 октября. По данным The Hacker News, Cloudflare ещё до выхода исправления заметила первые попытки атак и включила правила защиты, а watchTowr в тот же день сообщила об активных попытках использовать обе уязвимости. Американское агентство по кибербезопасности CISA на момент своего предупреждения успешных атак не видело. Некоторые организации на время отключили свои сервисы.

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

Кому подходит и сколько стоит

Обновление нужно всем, у кого есть сайт или сервис на PHP: сайт компании, интернет-магазин, лендинги, личный кабинет клиентов, база знаний или система заявок на своём сервере. Это касается и готовых движков вроде WordPress, и сайтов, написанных на заказ, например на Laravel.

Версии с исправлением:

• PHP 8.5 — 8.5.12;
• PHP 8.4 — 8.4.27;
• PHP 8.3 — 8.3.36;
• PHP 8.2 — 8.2.35. Поддержка этой ветки заканчивается 31 декабря 2026 года, дальше её обновлять не будут.

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

PHP 8.1 и старше разработчики больше не обновляют. Для версий 7.4, 8.0 и 8.1 они выложили минимальные исправления в исходном коде — пригодятся тем, кто сам собирает PHP на сервере. Некоторые дистрибутивы и поставщики долгой поддержки выпускают свои исправления для старых версий. Если ничего из этого нет, надёжный путь один — переход на поддерживаемую версию. CISA советует до тех пор держать такие сайты выключенными.

Сам PHP бесплатный, платить за обновление не нужно. Затраты — время администратора или подрядчика. Если PHP свежий, обновление обычно сводится к установке пакетов и перезапуску. Переход со старой версии может потребовать обновить движок, плагины и код сайта; сколько это займёт, зависит от конкретного сайта.

Как внедрить

1. Составьте список сайтов. Вспомните всё, что работает у компании в интернете: основной сайт, магазин, старые промо-страницы, личный кабинет, внутренние системы на своём сервере. CISA отдельно напоминает, что PHP бывает встроен в другие программы и об этом легко забыть. Старый забытый лендинг так же опасен, как основной сайт.

2. Поймите, кто отвечает за сервер.

• Сайт на обычном хостинге — напишите в поддержку и спросите: обновлён ли PHP на вашем тарифе до исправленной версии или до пакета с исправлениями CVE-2026-109618 и CVE-2026-109619. Попросите ответ письменно.
• Свой сервер или VPS — задача для администратора или подрядчика: обновить пакеты PHP средствами системы и перезапустить все процессы PHP и веб-сервер. Без перезапуска старый код продолжает работать.
• Сайт в контейнерах — пересобрать образы на обновлённом базовом образе и перевыпустить.

3. Проверьте результат. Версию PHP обычно видно в панели хостинга. Если у вас есть доступ к серверу через консоль — по SSH или через «Терминал» в панели хостинга, — проверить можно и самому за минуту. Скопируйте команду и выполните её — она подходит для Debian, Ubuntu, CentOS, AlmaLinux и Rocky Linux:

{ rpm -qa --changelog 'php*' 2>/dev/null; zcat /usr/share/doc/php*/changelog.Debian.gz 2>/dev/null; } | grep -oE 'CVE-2026-10961[89]' | sort -u; php -v | head -n 1

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

• Есть строки CVE-2026-109618 и CVE-2026-109619 — исправление установлено, даже если версия выглядит старой: дистрибутивы встраивают исправления в пакеты со старым номером.
• Номеров нет, но версия не ниже исправленной из списка выше — например, PHP 8.3.36 для ветки 8.3, — тоже всё в порядке.
• Номеров нет и версия ниже — скорее всего, PHP нужно обновить. Перешлите ответ команды администратору или в поддержку хостинга: пусть обновят PHP или подтвердят, что исправление уже стоит. То же, если вместо версии написано, что команда не найдена.

На сервере может стоять несколько версий PHP. В консоли отвечает не обязательно та, на которой работает сайт, а номера уязвимостей могут найтись в пакетах другой версии: сверьтесь с версией в панели хостинга или спросите администратора. Исправление добавило в PHP жёсткий предел памяти: если запрос его превышает, PHP сразу прерывает работу. Поэтому после обновления попросите администратора сверить настройки memory_limit и post_max_size с тем, что действительно нужно сайту, — например, для загрузки больших файлов. Не оставляйте на сайте открытую страницу с технической информацией о PHP: она подсказывает злоумышленникам, что у вас стоит.

4. Если PHP старый. Это повод запланировать переход на поддерживаемую версию, а не откладывать. Сделайте резервную копию, обновите копию сайта и проверьте на ней главные сценарии: заказ, оплату, формы заявок, вход в кабинет. Старые плагины после смены версии иногда перестают работать — лучше узнать об этом на копии. Пока переход не завершён, решите вместе с подрядчиком, можно ли временно выключить сайт или закрыть его веб-защитой (WAF — фильтр, который отсекает подозрительные запросы). CISA предупреждает: такая защита не заменяет обновление.

5. Если обновиться сегодня нельзя. Временных настроек, которые защищают сайт, нет. Разработчики PHP перечисляют меры, которые закрывают лишь отдельные известные пути атаки, и прямо пишут, что безопасным сайт от них не становится. Например, выключение session.upload_progress.enabled — ту самую настройку, которую до выхода исправления советовали как обходной путь, — перекрывает только подтверждённые способы атаки через одну из двух ошибок, а против второй не помогает вовсе. Если администратор всё же применяет эти меры, то весь список из бюллетеня PHP и в основных настройках сервера: через настройки самого сайта они не работают. Это мера на часы до обновления, а не замена ему. Если обновление откладывается, надёжнее на это время выключить сайт.

6. Проверьте, не было ли взлома. Попытки атак начались до выхода исправления, поэтому после обновления стоит осмотреться. CISA советует искать процессы PHP, которые запускают команды или скачивают программы. Попросите администратора посмотреть журналы сервера за последние дни, проверить новые файлы на сайте и новых пользователей в админке. Если что-то вызывает подозрения — смените пароли от админки, базы данных и хостинга и восстановите сайт из чистой копии.

7. На будущее. Договоритесь с хостингом или подрядчиком, кто и в какой срок ставит срочные обновления безопасности, держите свежие резервные копии вне сервера и не оставляйте сайты на версиях PHP без поддержки. Ближайшая дата — конец поддержки PHP 8.2 в декабре 2026 года.