PHP2Shell после патча: как подтвердить атаку и сохранить следы

2026.10.29

📋 Кратко

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

⏱ 8 минут чтения│сложность

PHP2Shell сейчас обозначает две критические уязвимости в ядре PHP. Их идентификаторы — CVE-2026-109618 и CVE-2026-109619. Обе уязвимости позволяют выполнить произвольный код без авторизации.

Патчи выходят 21 октября 2026 года. Исправления получают версии PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Однако сам факт обновления не показывает, была ли атака раньше.

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

Главная мысль: исправление PHP закрывает уязвимость, но не стирает вопрос о прошлой эксплуатации. Сначала фиксируйте состояние и следы, затем меняйте пароли, ключи и токены.

PHP2Shell превращает открытую службу в критическую точку

🔍 Что именно называют PHP2Shell

PHP2Shell — это общее название двух уязвимостей в ядре PHP. Речь идёт о CVE-2026-109618 и CVE-2026-109619. Обе получают оценку 9,2 из 10 по CVSS 4.0.

Патч работает только после проверки обработчиков и перезапуска

Уязвимости позволяют удалённо выполнить произвольный код на сервере. Для атаки не требуется авторизация. Поэтому одна открытая веб-служба становится важной точкой проверки.

Риск относится не к одной CMS. В перечне затронутых проектов находятся WordPress, 1С-Битрикс, Drupal, OpenCart, Laravel и другие решения. Обновление самой CMS не исправляет проблему в интерпретаторе PHP.

Эксплуатацию уже показывают на WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal и WHMCS. Также фиксируются первые попытки атак. Это не доказывает взлом конкретного сервера, но повышает ценность проверки журналов.

Что сделать сейчас: составьте список сайтов и сервисов, где работает PHP. Отдельно отметьте проекты на популярных CMS и фреймворках.

🛡️ Какие версии закрывают уязвимость

Исправленные версии — PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Переход на одну из них или на более новую версию закрывает уязвимость на уровне интерпретатора.

Сохранённые данные отделяют расследование от поспешной очистки

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

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

После обновления нужно перезапустить всё, что держит PHP в памяти. Это касается PHP-FPM, веб-сервера, обработчиков очередей и Apache с mod_php. Без перезапуска старый код продолжает работать в памяти.

Проверьте версию командами php -v и php-fpm<ВЕРСИЯ> -v. Сохраните вывод вместе с датой проверки. Такой файл показывает, какое состояние сервера команда видит после обновления.

Что сделать сейчас: зафиксируйте фактическую версию PHP для каждого обработчика. Не смешивайте результаты разных сайтов и служб.

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

📋 Как подтвердить, что патч установлен

Проверка начинается с даты обновления. Запишите, когда команда установила пакет и кто выполнил работу. Если сервер обслуживает подрядчик, сохраните его подтверждение.

Временное ограничение снижает риск, но не заменяет обновление

В документе укажите старую и новую версию PHP. Добавьте вывод php -v и php-fpm<ВЕРСИЯ> -v. Отдельно отметьте перезапуск служб, которые держат интерпретатор в памяти.

Такой набор нужен не только администратору. Он показывает, когда организация приняла меры. При разборе инцидента важны дата, ответственный и подтверждение результата.

Скриншот или журнал с версией PHP и датой служит простым доказательством выполненной работы. Но один скриншот не подтверждает отсутствие атаки. Он только фиксирует состояние после обновления.

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

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

🧭 Как отличить патч от подтверждения атаки

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

Чек-лист связывает версию, следы, перезапуск и ответственность

Для второй проверки ищите признаки взлома. В доступном чек-листе названы посторонние файлы, подозрительные записи в журналах и новые учётные записи.

Посторонний файл сам по себе не доказывает PHP2Shell. Он становится важным следом, если появляется рядом по времени с подозрительной записью в журнале. Поэтому не удаляйте находку до сохранения данных.

Новая учётная запись также требует проверки. Сопоставьте время её появления с датой обновления и другими событиями. Сначала сохраните информацию, потом меняйте пароли, ключи и токены.

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

Что сделать сейчас: составьте таблицу с тремя колонками: время, источник следа и действие команды. Не называйте событие подтверждённой атакой без нескольких связанных признаков.

🧪 Какие конфигурации нужно проверить

Список проверяемых компонентов зависит от того, как сайт запускает PHP. В одном окружении работает PHP-FPM. В другом используется mod_php, php-cgi, FrankenPHP или LiteSpeed.

Сроки уведомления требуют быстрого назначения ответственного лица

Из-за этого проверка только командной строки может дать неполную картину. Сервер способен обслуживать сайт другим обработчиком. Такой обработчик нужно проверить отдельно.

Особое внимание требуется сайтам, где PHP давно не используют явно. На сервере может оставаться старая установка или отдельный инструмент управления базой данных. В одном случае обнаруживается phpMyAdmin, который лежит в папке сайта и доступен из интернета.

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

После патчей защитные правила иногда затрагивают соседние сайты. Например, правило в IIS может блокировать запросы с типом содержимого multipart/form-data. Такой тип используют формы загрузки файлов и некоторые обычные формы.

Грубое правило может сработать для всех сайтов сервера. В одном случае оно блокирует функции ColdFusion, хотя сайт не содержит PHP. Это показывает, почему изменения защиты нужно проверять по каждому приложению.

Что сделать сейчас: проверьте обработчики PHP, старые каталоги и доступные из интернета инструменты. Затем убедитесь, что защитные правила не ломают соседние сайты.

🗂️ Как сохранять журналы и найденные файлы

Если проверка находит следы взлома, сначала сохраните журналы и данные расследования. Не начинайте с удаления файлов или смены всех секретов. Такие действия могут уничтожить полезную последовательность событий.

Сохраните дату обнаружения каждого следа. Отдельно отметьте дату патча и дату перезапуска служб. Сопоставление времени помогает понять, что происходило до обновления и после него.

Посторонние файлы нужно сохранить до очистки сервера. Журналы нужно сохранить до ротации. Новые учётные записи нужно зафиксировать до их удаления или блокировки.

Храните исходные материалы отдельно от рабочих копий. Рабочую копию можно анализировать и передавать участникам расследования. Исходный файл должен оставаться неизменным.

В журнале действий укажите, кто получил файл, когда его скопировал и где хранит. Простая запись снижает риск путаницы. Она также показывает порядок работы с доказательствами.

Если журнал уже ротировался, не скрывайте пробел. Запишите, какие данные недоступны и почему. Затем сопоставьте оставшиеся записи с датами обновления, перезапуска и обнаружения.

Что сделать сейчас: создайте папку расследования с копиями журналов, найденных файлов и выводом версий. Добавьте текстовый файл с временной шкалой.

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

⚖️ Почему важны дата и ответственный

Компания отвечает за защиту данных даже тогда, когда сервер обслуживает подрядчик. Перед пользователями и Роскомнадзором отвечает владелец данных.

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

При утечке персональных данных возможен штраф до 15 млн рублей. Сам факт уязвимости ещё не означает утечку. Обязанность уведомления появляется, когда установлена неправомерная или случайная передача персональных данных либо доступ к ним.

После обнаружения утечки первое уведомление в Роскомнадзор направляют в течение 24 часов. В нём указывают событие, вероятные причины, возможный вред, меры и контакт ответственного.

Второе уведомление направляют в течение 72 часов. Оно содержит результаты внутреннего расследования и сведения о виновных, если их установили. Отсчёт идёт с момента обнаружения утечки.

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

Что сделать сейчас: проверьте внутренний порядок эскалации. Администратор должен знать, кому передать сведения о найденных журналах, файлах и учётных записях.

🚧 Что делать, если обновление пока невозможно

Иногда команда не может сразу обновить PHP. В таком случае доступ к серверу из интернета нужно ограничить. Решение следует зафиксировать письменно.

Временные настройки из бюллетеня могут закрыть часть сценариев. Однако они не заменяют установку исправленной версии. После настройки всё равно нужен переход на PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 или более новую версию.

Ограничение доступа не отменяет проверку следов прошлой атаки. Пока сервер оставался доступным, нельзя считать риск устранённым только по изменению правил. Сохраняйте журналы и проверяйте посторонние файлы.

Изменения защитных правил могут повлиять на другие приложения. Правило для всех сайтов способно блокировать загрузку изображений, файлов и работу административных форм. Проверяйте результат отдельно для каждого сайта.

После установки патча перезапустите службы, которые держат PHP в памяти. Затем снова проверьте версии и сохраните вывод. Финальная запись должна содержать дату и исполнителя.

Что сделать сейчас: если патч задерживается, ограничьте доступ и запишите причину. Назначьте срок повторной проверки и не считайте временное правило окончательным решением.

✅ Финальный чек-лист после исправления

Проверка PHP2Shell заканчивается не установкой пакета. Команда должна подтвердить состояние служб и изучить признаки прошлой активности.

Определите ответственного за каждый сервер.
Проверьте PHP на версиях 8.2.35, 8.3.36, 8.4.27, 8.5.12 или новее.
Проверьте PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed.
Перезапустите PHP-FPM и другие службы, которые держат PHP в памяти.
Сохраните вывод php -v и php-fpm<ВЕРСИЯ> -v.
Запишите дату обновления и имя исполнителя.
Сохраните подтверждение подрядчика или хостинга.
Проверьте посторонние файлы.
Проверьте подозрительные записи в журналах.
Проверьте новые учётные записи.
До очистки сохраните журналы и найденные данные.
После сохранения следов смените пароли, ключи и токены.
Проверьте забытые установки PHP и доступный из интернета phpMyAdmin.
Проверьте, не ломают ли защитные правила соседние сайты.
При установленной утечке передайте сведения ответственному за уведомление.

Такой чек-лист разделяет два результата. Первый показывает, что сервер сейчас исправлен. Второй помогает понять, были ли признаки компрометации до патча.

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

Главное правило после PHP2Shell простое: обновление закрывает уязвимость, а сохранённые данные подтверждают действия команды. Эти задачи нужно выполнять параллельно.

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

📚 Читайте также

📖 Термины

CVE (Common Vulnerabilities and Exposures) · RCE (Remote Code Execution) · Индикаторы компрометации (IoC) · Инцидент-реагирование