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 endpoint без автентифікації, який отримував серіалізований 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 зазвичай містить:
- Точне місце ін’єкції – параметр, кінцева точка або cookie.
- Серіалізоване корисне навантаження, використане під час тестування.
- Докази зворотного виклику out-of-band із часовими мітками, зіставлені з початковим скануванням для blind-вразливостей.
- Повні дані запиту й відповіді для контексту.
- Класифікацію серйозності та оцінку CVSS.
- Чіткі рекомендації щодо усунення, адаптовані до конкретної вразливості.
Такий рівень деталізації дає змогу розробникам зрозуміти, перевірити та виправити проблему без додаткового розслідування.
Якщо ви бажаєте протестувати можливості платформи Invicti, будь ласка, залиште свої контактні дані у формі нижче і ми з вами зв’яжемося.
