PHP object injection становится одним из самых опасных классов уязвимостей в экосистеме WordPress. Этому способствуют сложные среды плагинов и масштабная эксплуатация в настоящих атаках. От уязвимостей, не требующих аутентификации в широко используемых плагинах до атак на цепи поставки, затрагивающие сотни тысяч сайтов, такие проблемы сложно выявлять и легко использовать для атаки.
В этом материале объясняется, как работает PHP object injection, почему традиционные сканеры пропускают такие уязвимости и как современные подходы DAST могут выявлять и подтверждать реальный риск попадания в продакшн.
PHP object injection больше не является проблемой безопасности чисто для WordPress.
Она стала быстро распространяющимся и уже активно эксплуатируемым в реальных условиях классом уязвимостей.
По данным Patchstack, в 2025 году количество доступных для эксплуатации уязвимостей WordPress выросло на 113%. Это сигнал, что злоумышленники приоритезируют проблемы, которые можно использовать массово против большого количества сайтов. PHP object injection полностью соответствует этой категории, поскольку такие уязвимости часто доступны для эксплуатации, сложны для обнаружения и могут привести к серьезным последствиям.
Злоумышленники не нацеливаются только на отдельные плагины изолированно. Они массово сканируют большое количество развертываний WordPress в поисках любой открытой точки десериализации. В этой модели популярность плагина имеет второстепенное значение. Важно то, доступна ли уязвимость в живой среде.
Атака на цепочку поставок EssentialPlugin в апреле 2026 показывает, как эволюционировала эта угроза. Вредоносный бэкдор был добавлен в сентябре 2025 года при переходе права собственности, после чего он оставался неактивным до апреля 2026 года. Он задел 31 плагин с совокупной базой примерно 400 000 сайтов на основе заявленного количества установок, а не подтвержденных случаев компрометации. Активация проходила через конечную точку REST API без проверки подлинности, которая получала сериализованный PHP-объект с сервера под контролем злоумышленника. Такой паттерн невидим для статического анализа, но его можно обнаружить с помощью тестирования во время выполнения.
Недавние CVE подтверждают тот же тренд:
- CVE-2025-7697 – плагин интеграции с Google Sheets, эксплуатация уязвимости не требует аутентификации, более 40 000 установок.
- CVE-2025-7384 – Database for Contact Form 7, CVSS 9.8, не требует аутентификации, более 70 000 сайтов.
- CVE-2025-6464 – Forminator Forms, не требующий аутентификации, более 600 000 установок. Для достижения воздействия требуется отдельный плагин или тема с подходящим gadget chain.
- CVE-2025-6742 – SureForms, не требует аутентификации, более 200 000 установок.
Они отображают системную проблему в том, как плагины WordPress обрабатывают данные и как PHP работает с десериализацией объектов. Именно для такого класса уязвимостей предназначены современные DAST-платформы, которые подтверждают возможность эксплуатации в запущенных приложениях, а не ограничиваются обнаружением паттернов в коде.
Как работает PHP object injection: пример опасной десериализации
В основе PHP object injection лежит предполагаемый, но рискованный паттерн: десериализация данных, контролируемых пользователем.
Опасная десериализация в PHP
PHP object injection возникает из-за некорректного использования функции unserialize(). Эта функция восстанавливает объекты PHP с сериализованных строк, включая их свойства и поведение.
Когда в unserialize() передаются входные данные под контролем злоумышленника, приложение фактически позволяет внешней стороне контролировать создание объектов и поток выполнения.
// Уязвимо
$data = $_COOKIE['user_prefs'];
$prefs = unserialize($data);
// Более безопасная альтернатива
$data = $_COOKIE['user_prefs'];
$prefs = json_decode($data, true);Уязвимость появляется тогда, когда недоверенные входные данные обрабатываются как доверенные сериализованные данные. В современных плагинах WordPress этот паттерн встречается в cookies, AJAX-обработчиках, REST API и логике обработки форм.
Почему среды WordPress усиливают риск
Приложения WordPress особенно уязвимы из-за особенностей своей архитектуры. Типичная установка содержит десятки плагинов и тем, каждый из которых добавляет собственные классы PHP в среду выполнения.
Это создает большой «gadget pool» – набор всех классов PHP, доступных в приложении, которые могут быть соединены во время десериализации. Злоумышленнику не нужно, чтобы уязвимый плагин содержал полную цепочку эксплуатации. Другие установленные компоненты могут предоставить недостающие элементы.
CVE-2025-7384 наглядно это показывает. Сам уязвимый плагин не обеспечивал полный путь эксплуатации, но в сочетании с Contact Form 7 он давал возможность произвольно удалять файлы через gadget chain.
Ключевые элементы включают в себя:
- Магические методы, такие как __wakeup(), __destruct() и __toString().
- Gadget chains, которые формируются при выполнении между плагинами.
- Взаимодействие между ядром, плагинами и темами.
Это значит, что возможность эксплуатации зависит от полного контекста приложения, а не только от уязвимого кода.
Реальное влияние успешной эксплуатации
PHP object injection может приводить к ряду серьезных последствий:
- Удаленное исполнение кода через цепочку вызовов методов.
- Произвольное удаление файлов, например удаление wp-config.php фактически отключает сайт и приводит к отказу в обслуживании.
- SQL-инъекция из-за опасной обработки свойств.
- Обход аутентификации и манипуляции с сессиями.
- Постоянный доступ из-за размещения веб-шела.
В атаках на цепочки снабжения воздействие может быть еще шире. В случае EssentialPlugin инъецированные объекты действовали как загрузчики, получали инструкции из внешних серверов управления и контроля, обеспечивали дальнейшую компрометацию.
Даже после установки исправления риск может сохраняться. Сериализованные полезные нагрузки, сохраненные в базе данных в период наличия уязвимости, могут оставаться пригодными для эксплуатации в зависимости от логики приложения. Поэтому устранение проблемы без очистки данных может быть неполным.
Для команд безопасности это значит, что риск является непосредственным, практичным и потенциально длительным.
Почему оценки CVSS часто недооценивают риск
CVSS дает полезную базу для оценки серьезности уязвимостей, а версия 4.0 добавляет дополнительные метрики, включая safety и automatable exploitation. Однако она все равно не может моделировать факторы, специфичные для конкретной среды, например наличие gadget chains в разных плагинах и темах.
В результате уязвимости PHP object injection часто получают более низкие оценки, чем того заслуживает их реальная пригодность к эксплуатации в типичных развертываниях WordPress. Уязвимость, изолированно выглядящая умеренной, может стать критической в сочетании с распространенными компонентами.
Это подчеркивает ключевое ограничение статической оценки. Оно не учитывает поведение при выполнении или сложности среды. Подтверждение возможности эксплуатации в живом приложении часто более значимо, чем основание лишь на теоретической серьезности.
Почему PHP object injection сложно выявлять на практике
Выявление PHP object injection является сложным, поскольку по своей природе эта проблема проявляется при выполнении.
Инструменты статического анализа могут выявить и обозначить опасное использование unserialize(), но они не могут определить, доходят ли до нее входные данные под контролем злоумышленника в развернутой среде. Они также не могут оценить наличие подходящих gadget chains в нескольких плагинах.
Black-box сканирование обещает проверку во время выполнения, но имеет собственные сложности:
- Приложение может не генерировать видимый результат после обработки полезной нагрузки.
- Паттерны сериализованных данных легко распознать, но сложно подтвердить.
- Эксплуатация часто зависит от косвенных побочных эффектов, а не от прямых ответов.
Это создает пробел в обнаружении. Одни сканеры фиксируют слишком много потенциальных проблем, опираясь только на характерные паттерны, другие – вообще не сообщают о риске, поскольку не могут подтвердить возможность эксплуатации. PHP object injection как раз находится в этой «слепой зоне».
Сценарии атак на цепи снабжения делают это еще сложнее. Если вредные полезные нагрузки получаются с внешних сервисов, а не отправляются непосредственно пользователями, традиционные подходы к сканированию могут вообще не увидеть такое поведение. Для обнаружения нужно наблюдать, как приложение обрабатывает внешние данные во время выполнения.
Как Invicti обнаруживает и подтверждает уязвимости PHP object injection
Преодоление этих сложностей обнаружения требует принципиально иного подхода, чем статический или ориентированный на паттерны анализ. Здесь особенно полезно расширенное динамическое тестирование безопасности приложений (DAST).
Тестирование при выполнении на всей поверхности приложения
DAST от Invicti анализирует приложения WordPress извне, фокусируясь на том, как они ведут себя в условиях, приближенных к продакшну. Сканер охватывает:
- Пути, определенные плагинами
- Конечные точки AJAX
- REST API
- Аутентифицированные административные интерфейсы
- Пользовательские формы и обработчики входных данных
Каждый вектор ввода проверяется с помощью зависимости от контекста полезной нагрузки. Для PHP object injection это включает в себя сериализованные строки объектов, предназначенные для запуска контролируемых, недеструктивных побочных эффектов во время десериализации.
Invicti DAST обнаруживает уязвимости, действительно доступные и пригодные для эксплуатации в запущенном приложении.
Proof-based сканирование с использованием out-of-band обнаружения
Многие уязвимости PHP object injection являются blind-уязвимостью. Это означает, что приложение обрабатывает вредоносные входные данные без какого-либо видимого признака успеха.
Invicti решает это с помощью out-of-band обнаружения. Полезные нагрузки создаются так, чтобы вызывать внешние взаимодействия, например, обратные вызовы DNS или HTTP, когда происходит десериализация.
Получение обратного вызова подтверждает, что:
- Входные данные под контролем злоумышленника достигли unserialize().
- Процесс десериализации выполнил код.
- Уязвимость реальна и пригодна для эксплуатации.
Это устраняет потребность в предположениях. Вместо сообщения о потенциальных проблемах Invicti предоставляет подтвержденные результаты с видимыми доказательствами, чтобы уменьшить количество ложноположительных срабатываний и сосредоточить команды на реальном риске.
Как выглядит подтвержденное обнаружение
Находка Invicti DAST для PHP object injection обычно содержит:
- Точное место инъекции – параметр, конечная точка или куки.
- Сериализованную полезную нагрузку, использованную при тестировании.
- Доказательства обратного вызова out-of-band с временными метками, сопоставленные с начальным сканированием для blind-уязвимостей.
- Полные данные запроса и ответа для контекста.
- Классификацию серьезности и оценку CVSS.
- Четкие рекомендации по устранению, адаптированные к конкретной уязвимости.
Такой уровень детализации позволяет разработчикам понять, проверить и устранить проблему без дополнительного расследования.
Если вы хотите протестировать возможности платформы Invicti, оставьте свои контактные данные в форме ниже и мы с вами свяжемся.
