Критична вразливість CVE-2026-35273 в Oracle PeopleSoft Enterprise PeopleTools версій 8.61 і 8.62, яку угруповання ShinyHunters експлуатувало як zero-day з травня 2026 року, насправді є не однією, а трьома окремими вразливостями, об’єднаними в ланцюжок. Про це минулого тижня повідомила команда Zero Day Initiative (ZDI), яка спочатку виявила проблему й передала інформацію Oracle. Вразливість має оцінку CVSS 9.8, дає змогу неавтентифікованому зловмиснику отримати віддалене виконання коду та внесена до каталогу CISA Known Exploited Vulnerabilities. Організаціям, які використовують PeopleSoft, необхідно негайно встановити патч Oracle, випущений 10 червня 2026 року, і провести перевірку на ознаки компрометації — встановлення патча не усуває доступ, отриманий зловмисником раніше. Ми вже писали про цю вразливість у контексті заяв ShinyHunters.
Анатомія ланцюжка: від SSRF до виконання коду
Oracle закрила всі три дефекти єдиним ідентифікатором CVE-2026-35273, однак, за даними ZDI, йдеться про три різні вразливості в двох компонентах PeopleSoft. ZDI координує з Oracle присвоєння окремих CVE кожному дефекту, але на момент публікації єдиний ідентифікатор залишається єдиним у реєстрі. Це важливий нюанс: наявність одного CVE й одного патча не означає наявність лише одного дефекту, і організаціям варто враховувати це під час оцінки поверхні атаки.
Задіяні два компоненти, що працюють як окремі вебзастосунки:
- Integration Gateway (PSIGW) — шлюз для обміну повідомленнями із зовнішніми системами;
- Environment Management Hub (PSEMHUB) — внутрішній адміністративний інтерфейс, призначений для доступу лише з довірених хостів.
За даними ZDI, ланцюжок експлуатації виглядає так:
- SSRF у PSIGW. Зловмисник надсилає запит до обробника вхідних з’єднань Integration Gateway і контролює як адресу призначення, так і повний вміст пересланого запиту. Обробник не перевіряє, чи є адреса призначення легітимною ціллю.
- Обхід перевірки довіри через loopback. PSEMHUB визначає довірених клієнтів за списком у файлі
allowedhosts.properties. За замовчуванням цей файл містить адресу 127.0.0.1. Зловмисник спрямовує SSRF-запит на loopback-адресу — запит надходить у PSEMHUB так, ніби він походить від самого сервера, і перевірка довіри проходить успішно. Внутрішній інтерфейс, який Oracle передбачала ізольованим, стає доступним ззовні. - Виконання коду. ZDI описує два шляхи перетворення доступу до PSEMHUB на виконання довільного коду. Перший — через команду запису логів, де зловмисник контролює і вміст файла, і шлях на диску, що дає змогу розмістити вебшел у каталозі застосунку. Другий — через запис шкідливого XML-файла, який PSEMHUB обробляє через Java XMLDecoder під час наступного запуску сервісу, виконуючи код зловмисника без розміщення вебшела.
Другий шлях виконання коду — через XMLDecoder — особливо небезпечний з погляду виявлення: він не залишає JSP-файлів, на які зазвичай орієнтуються правила детектування. Організації, чиї можливості моніторингу обмежені пошуком JSP-шелів, ризикують пропустити компрометацію. Для повноцінного виявлення необхідно поєднувати аналіз логів доступу з моніторингом процесів, породжених Java-процесом WebLogic.
Кампанія ShinyHunters: від університетів до держструктур
За даними Mandiant і Google Threat Intelligence Group, активна експлуатація CVE-2026-35273 спостерігалася з 27 травня по 9 червня 2026 року — до виходу патча Oracle 10 червня, що кваліфікує кампанію як zero-day. Кампанію атрибутовано угрупованню UNC6240, також відомому як ShinyHunters. Спочатку атаки були спрямовані переважно на сектор вищої освіти: за оцінкою Mandiant, 68% із понад 100 повідомлених організацій належали до університетів.
У вересні 2026 року Mandiant зафіксувала поновлену хвилю масової експлуатації, що поширилася на сектори технологій, IT-послуг, охорони здоров’я, сільського господарства, транспорту та державного управління. Вебшели були виявлені на десятках систем по всьому світу.
Показовою є техніка обходу WAF, застосована ShinyHunters у другій хвилі: замість прямого звернення до шляху /PSEMHUB/ зловмисники використовували URL-кодування одного символу — /%50SEMHUB/. Більшість правил WAF виконують зіставлення за відкритим текстом шляху, тоді як сервер PeopleSoft декодує шлях перед обробкою. Mandiant також відзначає характерний шаблон розвідки: від 5 до 15 POST-запитів до закодованого шляху перед початком експлуатації, що може слугувати індикатором у логах.
Індикатори компрометації
На основі даних дослідження доступні такі IOC:
- Хеші файлів:
48b4a0827da7bbfce9fb52464f8a659dea7a035189c52c506c0bfb4b1c3fe494,2bee941fb40519d0d1ec52bd79a8f63fc65aac6455c8f2d6b668e3360dfdb5d7 - IP-адреси: 142.11.200.186–190, 5.199.162.157, 104.219.234.138, 162.219.30.165
- Домени: azurenetfiles.net, winmanage-me.network
- C2 URL:
wss://azurenetfiles.net:443/agent.ashx(MeshCentral)
Рекомендації
- Встановіть патч. Застосуйте виправлення Oracle для CVE-2026-35273 і переконайтеся, що використовуєте підтримувану версію PeopleTools. Mandiant прямо зазначає, що блокування шляхів через WAF не є заміною патчу — техніка URL-кодування це наочно продемонструвала.
- Якщо патч наразі неможливий — вимкніть сервіс Environment Management Hub у багатосерверних конфігураціях або видаліть застосунок PSEMHUB в односерверних, як рекомендує Oracle. Це не порушує роботу користувацьких сесій.
- Проведіть перевірку на компрометацію. Шукайте не лише JSP-файли вебшелів, а й підозрілі XML-файли в каталогах PSEMHUB, а також нетипові дочірні процеси Java-процесу WebLogic. Перевіряйте логи на наявність POST-запитів до шляхів з URL-кодуванням (
/%50SEMHUB/). - У разі виявлення компрометації — вважайте хост повністю скомпрометованим, збережіть докази й ротуйтесь усі облікові дані, доступні з рівня PeopleSoft. ShinyHunters викрадає дані, а потім вимагає викуп, тож слід готуватися до спроб вимагання.
Ключовий урок цього інциденту — архітектурний: включення loopback-адреси до списку довірених хостів за замовчуванням перетворює будь-яку SSRF-вразливість на повний обхід контролю доступу до внутрішніх інтерфейсів. Організаціям, які експлуатують PeopleSoft, недостатньо встановити патч — потрібно переконатися, що на уражених серверах відсутні сліди уже отриманого зловмисниками доступу, оскільки ані Oracle, ані Mandiant не підтверджують, що патч видаляє раніше встановлені механізми закріплення.
