RCE в PHP: как работает уязвимость и как защитить сайт

Почему RCE в PHP — это не «экзотика»

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

Вторая причина распространённости — масштаб экосистемы. Значительная часть сайтов в Рунете работает на WordPress, 1С-Битрикс, Joomla, Drupal, Laravel и других PHP-платформах. Каждая CMS подтягивает десятки плагинов, модулей и библиотек Composer, и уязвимость в любом из них превращается в точку входа для всего сайта.

Третья причина — «долгая жизнь» устаревших версий. Ветки PHP 7.4 и 8.0 больше не получают официальных исправлений безопасности, но на хостингах и в корпоративных проектах их по-прежнему можно встретить. Любая найденная в них уязвимость остаётся незакрытой навсегда.

Отдельно стоит упомянуть уязвимости в самой среде выполнения. Они не зависят от качества вашего кода, но так же приводят к RCE. Здесь защита почти целиком сводится к обновлению и корректной конфигурации веб-сервера.

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

Реальные уязвимости из экосистемы PHP

Чтобы понять масштаб проблемы, полезно взглянуть на известные случаи. Они показывают, что RCE находят и в самом интерпретаторе, и в связках с веб-сервером, и в популярных фреймворках.

Уязвимость CVE-2024-4577 затронула PHP при работе в режиме CGI на Windows: из-за особенностей преобразования кодировки символов можно было передать интерпретатору дополнительные аргументы и выполнить код. Она была исправлена в версиях 8.1.29, 8.2.20 и 8.3.8. Уязвимость CVE-2019-11043 касалась связки Nginx и PHP-FPM при определённой конфигурации fastcgi_split_path_info и позволяла выполнять код через специально составленный адрес. В фреймворке Laravel ошибка CVE-2021-3129 в компоненте Ignition была опасна при включённом режиме отладки на рабочем сервере. А файл eval-stdin.php из старых версий PHPUnit (CVE-2017-9841), случайно оставленный в публичном каталоге vendor, годами использовался для массовых атак.

Для интернет-магазина или сервиса с заявками последствия взлома ощущаются сразу: перестаёт работать форма заказа, из выдачи пропадают страницы, а браузеры показывают предупреждение. Даже после очистки сайта репутацию приходится восстанавливать неделями: поисковые системы повторно проверяют ресурс, а рекламные кабинеты, например Яндекс Директ и Google Ads, могут отклонять объявления на домен с историей заражения.

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

Защита на уровне сервера и конфигурации

Безопасный код — только половина решения. Вторая половина — настройка среды, которая ограничивает ущерб, если ошибка всё же проскочила. Принцип здесь называется «минимальные привилегии»: процесс PHP должен иметь ровно столько прав, сколько нужно для работы сайта.

Запретите исполнение PHP в каталогах загрузок (uploads, cache, tmp) на уровне Nginx или Apache. Настройте раздельные пользователи и пулы PHP-FPM для разных сайтов, чтобы взлом одного не затронул соседние. Используйте open_basedir, ограничивающий доступ к файловой системе, и отключите неиспользуемые опасные функции в disable_functions. Перед обновлением конфигурации проверьте, что этим функциям не доверяет ни CMS, ни ваши модули, иначе часть возможностей сайта перестанет работать.

Как выявлять уязвимости заранее

Системный подход состоит из нескольких регулярных практик. Во-первых, инвентаризация: вы должны знать версию PHP, CMS, каждого плагина и пакета Composer. Команда composer audit проверяет зависимости проекта по базе известных уязвимостей, а подписка на рассылки безопасности вашей CMS помогает узнавать об исправлениях в день выхода.

Во-вторых, статический анализ: инструменты вроде PHPStan и Psalm с правилами безопасности, а также поиск по коду вызовов eval, system, unserialize и include с переменными. В-третьих, мониторинг: следите за изменением файлов (контрольные суммы, git status на сервере), необычной нагрузкой и новыми заданиями cron. Также подключите сайт к Яндекс Вебмастеру и Google Search Console: оба сервиса уведомляют, если обнаружили вредоносный код или взлом, и показывают раздел с проблемами безопасности.

Наконец, периодически проводите тестирование на проникновение на копии сайта. Оно покажет те сценарии, которые не видны при чтении кода.

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

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