Два идентификатора PHP2Shell (CVE‑2026‑109618, CVE‑2026‑109619) следует рассматривать как инцидент чрезвычайной важности: злоумышленнику не нужны никакие учётные данные, достаточно доступа к сервису, открытому в интернет, чтобы потенциально выполнить команды непосредственно на вашем сервере. Рекомендуемый порядок действий: сначала убедиться, входите ли вы в зону поражения, затем решить — устанавливать патч или сначала применить временные меры смягчения, и в конце обязательно проверить результат и просмотреть журналы. Ниже всё разложено по шагам в порядке выполнения.
Шаг первый: за 30 минут определить, действительно ли вы подвержены уязвимости
Не стоит сразу останавливать весь сайт — сначала выполните три действия для определения поверхности атаки.
1. Подтвердите версию. Войдите на сервер и выполните `php -v`, а также проверьте тег образа контейнера, `composer.lock`, версию PHP, переключённую в панели управления. Многие корпоративные сайты работают на старых версиях 7.x, а эксплуатация считает, что обновление выполнено, хотя фактически работает другая среда.
2. Подтвердите поверхность атаки. Просканируйте с внешней точки зрения: какие домены/IP имеют порты 80, 443, 8080, открытые напрямую в интернет, есть ли тестовые среды, старые панели администратора, временно запущенные интерфейсы, которые забыли закрыть. Доступность из внутренней сети не означает безопасность — горизонтальное перемещение часто начинается именно отсюда.
3. Подтвердите пути срабатывания. Сверьтесь с официальным бюллетенем, в котором указаны затронутые компоненты и точки входа, проверьте, покрыты ли ваши маршруты, интерфейсы загрузки, точки десериализации, места рендеринга шаблонов. Если определить невозможно — считайте, что подвержены уязвимости, это менее затратно.
Зафиксируйте результаты в таблице: домен, версия PHP, доступность из интернета, наличие затронутых компонентов, ответственное лицо. Эта таблица понадобится для проверки и разбора в дальнейшем.
Шаг второй: если можно установить патч — устанавливайте, не заменяйте обновление «правкой конфигурации»
Патч — единственное радикальное средство, временное смягчение лишь выигрывает время.
- Сначала проверьте на предпродуктивной среде. Обновление напрямую на продакшене очень рискованно, особенно для корпоративных сайтов, работающих много лет, где расширения и версии фреймворка взаимосвязаны. Прогоните на предпродуктивной среде основные сценарии: вход, оформление заказа/отправка формы, платёжные колбэки, загрузка файлов.
- Обновляйте в порядке зависимостей. Сначала обновите среду выполнения, затем фреймворк и сторонние библиотеки, в конце разберитесь с устаревшими вызовами в бизнес-коде. После обновления выполните `composer update`, затем перегенерируйте файл блокировки и закоммитьте его.
- Сохраните путь отката. Перед обновлением сделайте снимок или сохраните тег старого образа, пропишите команды отката. Обновление без плана отката — по сути азартная игра.
- Подводный камень: не объявляйте о завершении, обновив только одну машину. За балансировщиком нагрузки часто остаются несколько нетронутых серверов — злоумышленник атакует именно пропущенный.
Если бизнес выполнен на аутсорсе и исходный код недоступен, сначала свяжитесь с разработчиком для получения информации о версии и плана установки патча; если получить не удаётся — примените временные меры из следующего раздела.
Шаг третий: временное смягчение при невозможности установки патча — по приоритету
Меры смягчения «снижают вероятность эксплуатации», а не «исправляют» — обязательно внесите в план с крайним сроком обновления.
1. Сократите поверхность атаки: уберите панели администратора, отладочные интерфейсы, тестовые среды из интернета, переведите на доступ из внутренней сети или добавьте белый список IP. Это даёт наибольший эффект при наименьших затратах.
2. Предварительная блокировка: настройте правила блокировки на уровне WAF или Nginx по признакам, указанным в бюллетене, одновременно ограничьте права на выполнение в каталоге загрузок (`php_flag engine off` или эквивалентная конфигурация).
3. Снижение привилегий: веб-процесс не должен работать от root, уберите ненужные права на запись в каталогах, отключите опасные функции в `disable_functions`.
4. Добавьте мониторинг: настройте оповещения об аномальных дочерних процессах, внешних подключениях, новых исполняемых файлах в каталоге загрузок.
Подводный камень: добавить только правила WAF без изменения кода — значит доверить жизнь базе правил. Злоумышленник может обойти, сменив кодировку, поэтому в период смягчения ежедневно просматривайте журналы блокировок.
Шаг четвёртый: после исправления обязательна проверка, иначе это не исправление
Многие команды завершают работу после установки патча, а старые процессы продолжают работать.
- Перезапустите PHP-FPM и веб-службу, убедитесь, что `php -v` показывает новую версию на всех узлах.
- Повторно протестируйте исходный путь срабатывания внешним сканером, убедитесь, что возвращаемое состояние больше не позволяет эксплуатацию.
- Проверьте журналы: в окне между публикацией уязвимости и исправлением были ли аномальные POST-запросы, подозрительные загрузки, аномальные внешние подключения. Если да — действуйте как при инциденте вторжения, а не просто устанавливайте патч.
- Проверьте задания по расписанию, открытые ключи SSH, новые учётные записи — убедитесь, что не оставлено бэкдоров.
Конкретный пример (иллюстрация): во время редизайна корпоративного сайта временно открыли интерфейс загрузки файлов для дизайнеров и забыли закрыть — он как раз попал на уязвимую версию. Такие «временные интерфейсы» — зона наибольшего риска; при завершении редизайна должен быть «список очистки временных точек входа».
В каких случаях стоит обратиться в MIC Studio
Если у вас одна из следующих ситуаций, справляться самостоятельно невыгодно:
- Исходный код у аутсорсера, информацию о версии не получить, план установки патча не составить;
- Много сайтов, разнородные среды, невозможно определить, какие доступны из интернета, а какие в зоне поражения;
- После установки патча нужно провести ещё один цикл тестирования безопасности и обратного тестирования, чтобы убедиться в отсутствии остаточных точек входа и бэкдоров;
- Попутно требуется рефакторинг старой системы с унификацией технологического стека разработки сайтов, мини-программ или App до поддерживаемых версий.
MIC Studio занимается разработкой корпоративных сайтов, мини-программ, App и скриптов, а также тестированием безопасности сайтов и обратным тестированием — может работать в порядке «сначала остановить кровотечение, затем проверить, потом рефакторинг». Не все проблемы требуют аутсорса; если можете установить патч самостоятельно — сначала установите патч, это важнее.
Заключение: три вещи, которые можно сделать уже сегодня
1. Составьте список сегодня: перечислите все PHP-среды, доступные из интернета, с указанием версий и ответственных — не полагайтесь на память.
2. Завершите обновление или смягчение в течение 48 часов: если можно обновить — обновите, если нет — сократите поверхность атаки и добавьте блокировку, указав крайний срок.
3. Сохраните доказательства: сделайте резервную копию журналов до и после обновления, после исправления проверьте аномальные запросы в окне времени — убедитесь, что вторжения не было.
Часто задаваемые вопросы
Используется только во внутренней сети — нужно ли исправлять?
Нужно. Внутренняя сеть — не изолирующий барьер; терминалы сотрудников, тестовые машины, подключения третьих сторон могут стать точкой опоры. В первую очередь исправляйте доступные из интернета, внутренние — в том же окне обслуживания.
Можно ли не обновлять, если добавлены правила WAF?
Только как переходная мера. Правила зависят от сопоставления признаков, стоимость обхода невысока, а поддержка правил сама требует внимания. WAF — это жгут, обновление — операция; они не заменяют друг друга.