Уязвимость PHP2Shell в 2026 году: что делать владельцу сайта на PHP

Коротко

• PHP2Shell это две критические уязвимости в самом PHP (CVE-2026-109618 и CVE-2026-109619, по 9,2 балла CVSS 4.0): при уязвимой версии чужой запрос может выполнить код на сервере без логина и пароля.
• Исправление вышло 21 октября 2026 года: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Ветки 8.1 и старше официальных обновлений не получают.
• Обновление WordPress, 1С-Битрикс или другой CMS уязвимость не закрывает: обновляют сам PHP на сервере и перезапускают его процессы.
• Попытку атаки Amazon зафиксировал 17 октября, за четыре дня до публикации исправления, поэтому любой сервер, который работал на уязвимой версии, проверяют на взлом и меняют пароли и ключи, даже если его обновили в первый же день.
• Скорость решают список серверов и версий, доступы и право начать работу без согласований; у внешней команды это фиксирует договор поддержки.

Автор: Антон Тарасенко

23.10.2026 Время чтения: 10 мин

268

Что такое PHP2Shell, какие сайты под угрозой, почему обновления WordPress и 1С-Битрикс мало, что сделать за первые сутки и что записать в договор поддержки.

Антон Тарасенко, сооснователь и CEO NerdSquad. Обновлено 23 октября 2026 года.

Если сайт работает на PHP, его нужно обновить сейчас: 21 октября 2026 года PHP закрыл две критические уязвимости, которые назвали PHP2Shell. Они позволяют выполнить код на сервере без логина и пароля. Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Обновление WordPress или 1С-Битрикс тут не помогает, обновляют сам PHP на сервере.

Что такое PHP2Shell и чем она опасна?

PHP2Shell это общее имя двух уязвимостей в ядре PHP: CVE-2026-109618 и CVE-2026-109619. Разработчики PHP оценили обе в 9,2 балла по шкале CVSS 4.0 из 10 (бюллетени PHP CVE-2026-109618 и CVE-2026-109619). По вектору оценки атака сложная и требует условий, но для Apache с mod_php разработчики показали её на настройках по умолчанию.

Первая: атакующий присылает запрос, на котором PHP упирается в свой лимит памяти на запрос (memory_limit) и прерывает обработку, а недособранные данные запроса потом принимаются за правильные. Объём памяти сервера тут не помогает. Вторая: после сбоя в рабочем процессе остаётся ссылка на уже освобождённую память запроса, и следующий запрос в тот же процесс может ею воспользоваться. Поэтому опасны постоянно работающие процессы PHP-FPM и Apache. В обоих случаях итог одинаковый: чужой запрос получает возможность выполнить свой код с правами веб-сервера. По разбору Qualys, через вторую можно ещё прочитать память процесса, а в ней бывают пароли, токены сессий и ключи API.

Выполнение кода на сервере сайта означает, что взломщик видит то же, что и сайт: базу заказов и заявок, данные клиентов, ключи платёжных и почтовых сервисов. Для компании это ещё и вопрос 152-ФЗ. Об утечке персональных данных оператор, то есть владелец сайта, уведомляет Роскомнадзор дважды: в течение 24 часов с момента, когда её выявили, и в течение 72 часов с того же момента сообщает результаты внутреннего расследования.

Какие сайты под угрозой?

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

На PHP работают WordPress, 1С-Битрикс, Drupal, Joomla, OpenCart, Magento и большинство самописных сайтов на Laravel и Symfony. По оценке Луки Сафонова из «Гарда», которую приводит «Фонтанка», под угрозой могут быть десятки, а возможно, и сотни тысяч российских сайтов и приложений.

Для веток 7.4, 8.0 и 8.1 команда PHP выложила только исходные патчи для тех, кто собирает PHP сам. Инженеру, который знает сервер, такая сборка с проверкой займёт несколько часов, без него растянется на дни.

Почему обновления CMS недостаточно?

Уязвимость сидит в интерпретаторе, а не в коде сайта. Кнопка «Обновить» в админке WordPress или SiteUpdate в 1С-Битрикс меняют файлы движка, но не трогают PHP, который их исполняет. Обновлять нужно PHP: через панель хостинга, пакетный менеджер сервера или образ контейнера.

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

Что сделать в первые сутки?

Шаги 1–3 и 6 собраны по рекомендациям американского агентства CISA и бюллетеню PHP, проверка на взлом и смена ключей по советам Луки Сафонова из «Гарда» и данным Qualys об утечке памяти:

1. Составить список всех серверов, где есть PHP: основной сайт, тестовый стенд, старый лендинг акции, личный кабинет, админка на отдельном адресе, внутренние инструменты на PHP (phpMyAdmin, Zabbix, Roundcube, коробочный Битрикс24). Забытый стенд взламывают так же, как основной сайт.
2. Обновить PHP до исправленной версии, начиная с серверов, которые открыты в интернет, и первыми Apache с mod_php. Обновляют все пакеты PHP на сервере: консольный, PHP-FPM и модуль Apache. На общем хостинге спросить хостера, закрыта ли уязвимость в вашей версии PHP; переключать старый сайт на новую ветку в панели без проверки нельзя, он может перестать работать.
3. Перезапустить все процессы PHP. Если сайт в контейнерах, пересобрать образ с принудительным обновлением базового образа (docker build --pull), иначе сборка возьмёт старый PHP из кеша, и выкатить все сервисы, включая обработчики очередей и задания по расписанию. Проверять версию у того PHP, который обслуживает сайт: php -v показывает только консольный. У пакетов дистрибутива версию пакета сверяют с бюллетенем дистрибутива или ищут номера CVE в журнале изменений пакета, затем проверяют, что процессы PHP-FPM и Apache запущены после обновления.
4. Проверить на взлом каждый сервер с уязвимой версией, который принимал запросы из интернета, даже если его обновили в первый же день. Готовых признаков взлома для PHP2Shell на 23 октября никто не опубликовал, поэтому ищут косвенные: файлы .php, изменённые после 17 октября, правки .htaccess и .user.ini, новые задания cron и администраторы в базе, процессы PHP, которые запускают командную оболочку или скачивают файлы, аварийные падения процессов PHP в журналах. Журналы веб-сервера и PHP с 17 октября сохранить сразу: на хостинге их часто хранят неделю. Если следы нашлись, сохранить журналы и копию диска для отчёта Роскомнадзору и поднять сервер заново из чистого образа с кодом из репозитория, а не чистить старый.
5. Сменить пароли базы данных и администраторов, ключи API платёжных и почтовых сервисов, токены интеграций с CRM и секреты самого приложения, например ключи и соли WordPress, завершить все сессии пользователей. Вторая уязвимость может отдать их из памяти, и обновление PHP утёкший ключ уже не вернёт. Менять после обновления PHP и перезапуска процессов, а если найден взлом, только на заново поднятом сервере, иначе новые ключи утекут так же.
6. Если обновиться прямо сейчас нельзя, CISA советует отключить сайт до обновления. Фильтр WAF у хостинга или провайдера защиты только частично снижает риск и помогает, только если до сервера нельзя достучаться в обход него. Если трафик сайта с персональными данными пойдёт через зарубежный фильтр, это трансграничная передача: такой вариант сначала обсуждают с юристом.

Временные меры из бюллетеня PHP закрывают только часть способов атаки. Против первой уязвимости: memory_limit=-1, заданный так, чтобы сайт не мог его переопределить, вместе с лимитом памяти контейнера или cgroup, и низкий post_max_size. Против второй: session.upload_progress.enabled=0, на PHP 8.5 ещё fatal_error_backtraces=0. Ставят их в php.ini, пуле PHP-FPM или настройках Apache, не через .user.ini и ini_set, и перезапускают все процессы. Сами разработчики PHP пишут, что безопасной установку эти меры не делают: единственный надёжный путь это обновление.

Почему такие уязвимости теперь будут появляться чаще?

Искать ошибки в старом коде стали нейросети. Исследователи Wiz говорят, что ошибки в PHP жили десятилетиями, а собрать из них рабочую атаку было слишком сложно. Современные модели этот порог сильно снизили. По данным «Фонтанки», одну из двух ошибок нашли с помощью модели ИИ.

Amazon поймал попытку атаки через PHP2Shell на своей ловушке 17 октября, за четыре дня до публикации исправления. Исследователи Sansec ожидали массовых атак примерно через 15 минут после выхода патчей, а Cloudflare, по данным Qualys, уже видит атакующий трафик, в том числе попытки обойти её фильтры. Часть сайтов администраторы отключили на время обновления, среди них реестр доменов .de.

Поэтому я считаю, что обновлять нужно в тот же день, когда вышли исправленные версии. Успеть проще, если кто-то заранее знает, что именно обновлять.

Почему сайту нужен подрядчик, который знает проект?

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

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

Что записать в договор поддержки сайта?

Для срочных случаев вроде PHP2Shell в договоре поддержки нужны такие пункты:

• срок реакции и срок установки исправления для критических уязвимостей на серверах, открытых в интернет, отдельно от обычных задач, в часах; подрядчик сам следит за бюллетенями PHP, CMS и дистрибутива;
• обновления безопасности PHP, CMS и модулей входят в оплаченную поддержку и не требуют отдельного согласования сметы;
• у подрядчика есть актуальный список серверов, версий и доступов, и он передаёт его вам по запросу;
• резервные копии хранятся отдельно от сервера сайта не меньше 30 дней, чтобы нашлась копия до взлома, удалить их с самого сервера нельзя, восстановление проверяли, а допустимая потеря данных и срок восстановления записаны в договоре; если в копиях персональные данные россиян, хранилище тоже в России (часть 5 статьи 18 152-ФЗ);
• если подрядчику доступна база с персональными данными, в договоре есть поручение на обработку по части 3 статьи 6 152-ФЗ с мерами защиты и обязанностью сообщить вам об инциденте в часах: срок 24 часа для уведомления Роскомнадзора лежит на вас;
• аккаунты хостинга, домена и облака оформлены на вас, а при расторжении подрядчик передаёт доступы и удаляет у себя копии;
• после инцидента подрядчик пишет короткий отчёт: что обновили, что проверили, какие ключи сменили.

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

В NerdSquad техническую поддержку сайтов ведём помесячно, годовым договором или по заявкам (страница создания сайтов). Срок реакции и то, входит ли срочное обновление в оплату, фиксируем в договоре до начала работ. Управление уязвимостями у нас входит в систему информационной безопасности, сертифицированную по ГОСТ Р ИСО/МЭК 27001:2021: список ПО и версий на серверах, которые мы поддерживаем, ведём заранее.

Команда делает пентесты и работы по 152-ФЗ. Подробнее о формате на странице ИТ-аутсорсинга и поддержки проектов. Как устроено сопровождение после запуска, разобрано в статье о технической поддержке приложения после релиза, а что спросить у подрядчика до договора, в чек-листе выбора подрядчика.

Об авторе. Антон Тарасенко, сооснователь и CEO NerdSquad, сооснователь YotaPhone и экс-CTO Yota Devices. NerdSquad (nerdsquad.ru) основана в 2015 году, разрабатывает веб-сервисы, мобильные приложения и ИИ-решения и усиливает ИТ-команды компаний специалистами. У компании сертификат ГОСТ Р ИСО/МЭК 27001:2021, услуги по 152-ФЗ и пентестам.

Услуга по теме: IT-аутсорсинг

Источники и методика

Данные сверены 23 октября 2026 года по бюллетеню PHP и публикациям агентств и исследователей.

• Бюллетени PHP CVE-2026-109618 и CVE-2026-109619 и новость о выпуске на php.net от 21 октября 2026 года: версии с исправлением, затронутые конфигурации, временные настройки, поддержка веток.
• Рекомендации CISA от 21 октября 2026 года.
• Разбор Qualys и обзор Help Net Security: утечка памяти, попытка атаки 17 октября по данным Amazon, атакующий трафик по данным Cloudflare, оценка Wiz.
• «Фонтанка» об угрозе для сайтов Рунета, новость Хабра об отключённых сайтах и оценке Sansec.
• Требования «1С-Битрикс» к версии PHP.
• Срок уведомления Роскомнадзора: часть 3.1 статьи 21 закона 152-ФЗ.
• Сведения о NerdSquad по данным компании и страницам услуг аутсорсинга и создания сайтов.

Частые вопросы

Как узнать, какая версия PHP на моём сайте?

На хостинге версия видна в панели управления, в разделе настроек PHP. На своём сервере команда `php -v` показывает только консольный PHP, а сайт может работать другой версией, поэтому версию проверяют у PHP-FPM или модуля Apache, например страницей phpinfo, закрытой от посторонних. Если доступа нет ни у кого в компании, это первый повод найти подрядчика на поддержку.

Мой сайт на 1С-Битрикс обновлён. Он защищён?

Нет, если не обновлён сам PHP. SiteUpdate меняет файлы продукта, а уязвимость находится в интерпретаторе. Свежие версии продуктов «1С-Битрикс» требуют PHP не ниже 8.2, для неё исправление вышло в версии 8.2.35. На 7.4 или 8.1 сейчас ставят исправленный пакет или собирают PHP с патчем, иначе отключают сайт; переход на новую ветку с проверкой модулей планируют отдельно.

Что делать, если на сервере PHP 7.4 или 8.1?

Официальных релизов для этих веток нет. Закрыть уязвимость сейчас можно исправленным пакетом дистрибутива или поставщика долгой поддержки (в его бюллетене должны быть оба номера CVE) либо сборкой PHP с патчем команды PHP. Если ни того, ни другого нет, сайт отключают до обновления: фильтр WAF снижает риск лишь частично. Переход на 8.4 и выше планируют отдельно.

Нужно ли что-то делать, если сайт обновили через день после выхода патча?

Да. Amazon зафиксировал попытку атаки ещё до публикации исправления, поэтому сервер проверяют на следы взлома и меняют пароли и ключи. Если выявлена неправомерная или случайная передача персональных данных, в том числе доступ к ним, у компании 24 часа на уведомление Роскомнадзора и 72 часа на отчёт о расследовании, за неуведомление штраф по статье 13.11 КоАП.

Об авторе

Антон Тарасенко

Сооснователь и CEO NerdSquad

Российский IT-предприниматель, технологический бизнес-ментор, сооснователь и CEO студии разработки веб-сервисов и мобильных приложений NerdSquad.

Telegram Telegram-канал биография

Связанные статьи

• Что входит в техническую поддержку мобильного приложения после релиза в 2026 году 20.09.2026
• Как выбрать подрядчика для разработки сайта в 2026 году: проверка, вопросы и договор 12.07.2026

Поделиться