ИИ нашёл уязвимости в PHP: что делать владельцу сайта после PHP2Shell
21 октября государственные организации Финляндии и Нидерландов временно отключили часть сайтов. Администраторы ждали исправления двух критических уязвимостей PHP. Для посетителя это выглядело как сбой. Для владельца сайта выбор был серьёзнее: несколько часов простоя или риск оставить сервер открытым для атаки.
PHP работает на множестве сайтов, включая WordPress-магазины, корпоративные страницы и веб-приложения. По оценке W3Techs на 23 октября, его используют 69,3% сайтов, у которых удалось определить серверный язык. Это доля использования PHP, а не доля взломанных или уязвимых сайтов.
Что нашли исследователи
Уязвимости получили номера CVE-2026-109618 и CVE-2026-109619. Обе связаны с тем, как PHP обрабатывает память и завершает запросы с ошибкой. При определённых условиях злоумышленник может отправить специально подготовленный запрос и добиться выполнения кода на сервере без входа в аккаунт. Успех атаки зависит от конфигурации сайта и способа запуска PHP, но подтверждённые сценарии затрагивают Apache с mod_php и PHP-FPM.
Для бизнеса последствия понятнее без технических терминов: атакующий может получить доступ к данным, изменить сайт или нарушить его работу. Если на одном сервере стоят магазин, CRM и внутренние сервисы, проверять придётся всю связку, а не только главную страницу.
Как здесь помог ИИ
В видео я рассказываю о работе исследователей Calif и Wiz с ИИ-инструментами. Но история началась раньше: после аудита в 2024 году разработчики PHP уже видели признаки проблемы в обработке нехватки памяти. Тогда они не нашли убедительного пути к удалённому выполнению кода. В августе 2026 года исследователи показали такой путь, и команда PHP поставила исправление в приоритет.
Нейросеть помогла искать и проверять гипотезы, а люди подтвердили уязвимости, разобрали последствия и подготовили патчи. ИИ ускорил исследование; ответственность за исправление осталась у разработчиков и администраторов.
Какие версии PHP исправлены
Команда PHP выпустила исправления для четырёх поддерживаемых веток: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Если сайт работает на PHP 8.1 или более старой версии, официального исправления от проекта PHP для этой ветки нет. Нужно планировать переход на поддерживаемую версию и проверять, предлагает ли Ваш хостер или поставщик системы собственный проверенный патч.
Обновить WordPress или плагины полезно, но этого недостаточно: уязвимости находятся в самом PHP. И наоборот, сообщение хостера «обновление установлено» стоит проверить на том приложении, которое принимает запросы посетителей.
Что сделать владельцу сайта
Начните с версии PHP, на которой работает сайт. В WordPress её можно посмотреть в разделе «Инструменты» - «Здоровье сайта» - «Информация» - «Сервер». Если сайтов несколько, проверьте каждый домен, поддомен и отдельное приложение: они могут работать на разных версиях. Команда php -v в терминале показывает версию PHP для командной строки; веб-сервер иногда использует другую.
Если Вы пользуетесь хостингом, отправьте поддержке конкретный запрос: «Какая версия PHP обслуживает мой сайт? Установлены ли исправления для CVE-2026-109618 и CVE-2026-109619? Когда они начнут действовать для всех моих сайтов и поддоменов?» Сохраните ответ и проверьте работу сайта после обновления.
Если у Вас свой сервер, перед изменениями сделайте резервную копию и поручите администратору проверить способ установки PHP, доступность исправленных пакетов и совместимость приложения. Для Ubuntu и Debian команды обновления зависят от подключённых репозиториев. После установки пакетов нужно перезапустить веб-обработчик и убедиться, что посетителей обслуживает уже исправленная версия. Обновление всей системы одной командой без проверки может затронуть и другие компоненты.
Особое внимание - старым проектам на WordPress. Переход с PHP 5.6 или 7.x может потребовать обновить тему, плагины и код сайта. Эту работу лучше провести с копией проекта и планом отката. Случайный патч из комментариев или форума не даёт уверенности ни в безопасности, ни в сохранности сайта.
Можно ли обойтись защитным фильтром
Защитные правила и WAF могут снизить риск отдельных способов атаки, но не заменяют исправление PHP. Если быстро обновить публичный сервис невозможно, администратору стоит ограничить к нему доступ или временно отключить его до установки патча. Именно такой выбор сделали некоторые организации в Европе.
Я считаю, что главный вывод этой истории касается не одной новости о PHP. У бизнеса часто есть сайт, но нет точного ответа, кто отвечает за его сервер, обновления и восстановление после сбоя. Сейчас хороший момент получить этот ответ. Вы знаете, какая версия PHP обслуживает каждый Ваш сайт?
Видео и источники
Видео Олега Бердова с разбором и инструкцией: https://dzen.ru/video/watch/6ad98026cba82619cba47352
Источники: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ ; https://w3techs.com/technologies/details/pl-php ; https://yle.fi/a/74-20252600
Если Вам полезны такие разборы киберрисков для бизнеса, следите за новыми статьями BERDOFF AI AGENTS. Так я пойму, что стоит подробнее показать проверку сайтов и серверов на практике.
Если хочешь внедрить ИИ агентов в бизнес-процессы, но не знаешь с чего начать, напиши мне в телеграм t.me/berdoff, я проведу бесплатную консультацию.
