Zero-day-ul Oracle PeopleSoft exploatat de ShinyHunters era, de fapt, trei vulnerabilități înlănțuite

Vulnerabilitatea critică din Oracle PeopleSoft pe care grupul de extorcare ShinyHunters o abuzează de la sfârșitul lunii mai nu este un singur bug. Detaliile tehnice disponibile acum arată că CVE-2026-35273, identificatorul folosit de Oracle când a publicat remedierea de urgență pe 10 iunie, acoperă trei slăbiciuni distincte din două componente PeopleSoft. Înlănțuite, ele permit unui atacator fără niciun fel de credențiale să ruleze comenzi pe server.

Identificatori CVE separați pentru fiecare defect sunt în curs de alocare, dar deocamdată cel din iunie rămâne singurul înregistrat. Echipele care urmăresc „un singur CVE" trebuie să înțeleagă că au de-a face, de fapt, cu un lanț.

Ce s-a întâmplat

CVE-2026-35273 afectează PeopleSoft PeopleTools 8.61 și 8.62, are un scor CVSS de 9,8 și permite preluarea serverului prin rețea, fără autentificare. Oracle a remediat-o printr-o alertă de securitate publicată în afara ciclului obișnuit, pe 10 iunie, iar vulnerabilitatea figurează acum în catalogul CISA de vulnerabilități exploatate activ (KEV).

Remedierea a venit prea târziu pentru primele victime. Activitatea atribuită ShinyHunters (urmărit și ca UNC6240) a exploatat bug-ul între 27 mai și 9 iunie, în special împotriva universităților. Pentru că a precedat avizul Oracle, a fost un zero-day veritabil pe toată durata acelei ferestre. Un al doilea val, mai amplu, în septembrie, a depășit sectorul educației și a lovit tehnologia, serviciile IT, sănătatea, agricultura, transporturile și administrația publică, afectând zeci de sisteme din întreaga lume.

Cum funcționează lanțul

Sunt implicate două aplicații web. Integration Gateway (PSIGW) schimbă mesaje cu sisteme externe și este menit să fie accesibil. Environment Management Hub (PSEMHUB) este o interfață internă de administrare care ar trebui să răspundă doar gazdelor de încredere.

1. Server-side request forgery în gateway. Conectorul de ascultare al PSIGW acceptă o cerere și o retransmite, iar apelantul controlează atât adresa de destinație, cât și întregul conținut. Nimic nu verifică dacă destinația este legitimă.
2. O setare implicită care are încredere în loopback. PSEMHUB decide în cine are încredere comparând solicitantul cu o listă din fișierul allowedhosts.properties. Fișierul vine din fabrică cu 127.0.0.1 deja pe listă. Îndreptați SSRF-ul către adresa locală de loopback și cererea pare că vine chiar de pe mașină, verificarea trece, iar hub-ul „intern" devine brusc accesibil din internet.
3. Scriere arbitrară de fișiere în hub. Odată hub-ul accesibil, o comandă gândită pentru scrierea intrărilor de jurnal îi permite apelantului să aleagă atât conținutul fișierului, cât și calea exactă de pe disc.

De aici, două rute duc la execuția de cod. Cea directă plasează un web shell în directorul aplicației și rulează comenzi cu contul de serviciu PeopleSoft. Cea discretă scrie un fișier XML malițios pe care hub-ul îl interpretează cu XMLDecoder din Java la următoarea pornire a serviciului, executând codul atacatorului la restart fără a lăsa vreun web shell în urmă. A doua cale oferă mult mai puține indicii mecanismelor standard de detecție.

De ce contează

Lecția principală ține de proiectare: o verificare de încredere bazată pe IP-ul sursă nu valorează nimic odată ce pe aceeași gazdă există un SSRF, iar intrarea de loopback din lista implicită a făcut-o inutilă din start. Organizațiile care au presupus că un firewall în fața PSEMHUB le protejează s-au înșelat, pentru că cererea ostilă vine din interior.

Valul din septembrie a arătat și cât de fragil este „patch-ul virtual". Regulile de web application firewall care blocau calea simplă /PSEMHUB/ au fost ocolite prin codificarea URL a unui singur caracter, cererea devenind /%50SEMHUB/. Multe semnături WAF compară textul literal, în timp ce serverul PeopleSoft îl decodifică fără probleme și servește pagina.

În plus, modul de operare al ShinyHunters este furtul de date urmat de o cerere de răscumpărare, așa că o gazdă PeopleSoft compromisă înseamnă o breșă cu bilet de extorcare atașat, nu doar o problemă de disponibilitate.

Ce este de făcut

• Aplicați patch-ul. Instalați remedierea din alerta de securitate Oracle pentru CVE-2026-35273 și rămâneți pe o versiune PeopleTools suportată. Blocarea căilor în WAF nu înlocuiește patch-ul.
• Dacă nu puteți aplica patch-ul imediat, dezactivați serviciul Environment Management Hub în instalările multi-server sau eliminați aplicația PSEMHUB în instalările single-server. Restricționarea acestor endpoint-uri de administrare nu afectează sesiunile utilizatorilor obișnuiți.
• Căutați calea discretă. Verificați dacă există fișiere JSP neașteptate în directorul web al PSEMHUB și fișiere XML neașteptate sau modificate recent în folderul de metadate al mediului, acolo unde stă încărcătura cu execuție întârziată.
• Dacă este posibil să fiți deja compromiși, tratați orice gazdă cu web shell ca fiind complet compromisă, păstrați dovezile și rotiți toate credențialele accesibile din nivelul PeopleSoft: conturi de bază de date, credențiale de integrare, conturi de serviciu și chei API stocate. Pregătiți-vă pentru o tentativă de extorcare.
• Nu presupuneți că patch-ul dă afară intrusul. Aplicarea remedierii închide ușa, dar nimic din ghidajul producătorului nu spune că elimină accesul pe care un atacator l-a obținut deja. Rotirea credențialelor și vânătoarea de web shell-uri pornesc tocmai de la premisa că nu o face.

Slăbiciunile înlănțuite ca aceasta, în care fiecare piesă pare tolerabilă luată separat, sunt exact ceea ce un scanner care verifică un număr de versiune nu vă poate spune și ceea ce un test de penetrare bine delimitat este conceput să scoată la iveală. Angajamentele de penetration testing ale echipei noastre exersează pivotările SSRF către servicii interne, presupunerile implicite de încredere și ocolirile de WAF asupra aplicațiilor de business expuse extern, precum PeopleSoft, astfel încât lanțul să fie găsit de noi, nu de următoarea grupare de extorcare.