Zero-day Oracle PeopleSoft CVE-2026-35273: ShinyHunters era già uscito prima dell'avviso

I dati erano sul leak site il 9 giugno. L'avviso di Oracle è uscito il 10 giugno. Per la maggior parte delle oltre cento organizzazioni colpite, il primo segnale affidabile che qualcosa non andava non è arrivato dal SIEM, né dalla console EDR, né da Oracle: è arrivato come un'email del Threat Intelligence Group di Google che comunicava che il loro IP risultava correlato a un endpoint PeopleSoft compromesso. A quel punto ShinyHunters era dentro, a intermittenza, dal 27 maggio. L'exploit era una remote code execution non autenticata e pulita. Il dwell time, circa due settimane. Il rilevamento, per quasi tutti, è stato esterno.

Questa sequenza — sfruttato come zero-day, esfiltrato, pubblicato e poi divulgato — è ciò che rende CVE-2026-35273 degno di un articolo. Non il bug in sé, che è una RCE da deserializzazione da manuale. La storia è lo scarto tra il momento in cui i dati sono usciti e il momento in cui qualcuno con l'obbligo di notificarlo se n'è accorto.

Cos'è davvero CVE-2026-35273

La falla risiede nell'Environment Management Hub (EMHub) di Oracle PeopleSoft PeopleTools, il componente che fa da broker dei metadati di configurazione tra gli ambienti PeopleSoft. Il Security Alert di Oracle del 10 giugno lo valuta CVSS 9.8 e indica come affette le versioni PeopleTools 8.61 e 8.62. È non autenticata, raggiungibile via rete e — secondo l'analisi di Google Mandiant — sfruttabile attraverso due endpoint che molte installazioni PeopleSoft espongono su internet senza pensarci: /PSEMHUB/hub e /PSIGW/HttpListeningConnector.

Il meccanismo è quello deprimentemente noto. Una POST malevola raggiunge un endpoint che passa input controllato dall'attaccante a un percorso Java XMLDecoder senza validazione, e il decoder istanzia con disinvoltura qualunque oggetto venga serializzato. Da lì è esecuzione di codice come utente applicativo. La parte interessante per chi difende non è il primitive — è che il servizio EMHub esiste, è spesso raggiungibile dall'esterno e quasi mai rientra nel perimetro quando qualcuno disegna alla lavagna la "superficie d'attacco" di PeopleSoft. È idraulica. È nell'idraulica che vivono gli zero-day.

Come ShinyHunters ha eseguito lo zero-day PeopleSoft

Il Threat Intelligence Group di Google traccia l'attore come UNC6240, il cluster noto pubblicamente come ShinyHunters, e data l'attività dal 27 maggio al 9 giugno 2026. La catena ricostruita da Mandiant va letta come sequenza, perché ogni fase è un punto in cui chi difende avrebbe potuto intercettarla, e nella maggior parte dei casi non l'ha fatto:

Fase	Cosa è successo	Cosa ha toccato
Accesso iniziale	RCE non autenticata via /PSEMHUB/hub	Log di accesso WebLogic
Persistenza	Webshell JSP in PSEMHUB.war/, oggetti XMLDecoder in envmetadata	Filesystem
C2	Agent MeshCentral verso azurenetfiles.net su wss://…:443	TLS in uscita
Movimento laterale	[vittima]_fanout.sh, SMB verso host interni	TCP 445
Raccolta	Staging su server Python SimpleHTTP (porta 8888)	HTTP interno
Esfiltrazione	Compressione zstd -3, poi SSH in uscita verso 176.120.22.24	Egress TCP 22

Il dominio C2 — azurenetfiles.net, che si finge Microsoft Azure NetApp Files — è il tipo di nome che sopravvive a un'occhiata distratta a un log di proxy. Lo strumento di accesso remoto era MeshCentral, un RMM open-source legittimo, firmato e con un comportamento da tool d'amministrazione. L'esfiltrazione era un archivio compresso con zstd spinto via SSH verso un singolo IP mai visto prima. Niente di tutto questo fa scattare una firma. Tutto questo è rumorosissimo sul filo, se qualcosa sta effettivamente modellando il filo.

"Mostrami la regola di firewall che blocca una sessione SSH in uscita verso un IP con cui non hai mai parlato prima, che trasporta un archivio compresso, da un server il cui unico compito è stare fermo e servire dati HR."

La maggior parte delle reti questa regola non ce l'ha. Hanno una lista di ciò che è proibito, non un modello di ciò che è normale.

Il punto cieco di detection: perché 100 organizzazioni l'hanno saputo da Google

Ecco il numero che dovrebbe inquietare ogni responsabile della sicurezza che legge: Google ha notificato oltre 100 organizzazioni. Quella formulazione dice molto. Significa che quelle organizzazioni non hanno rilevato l'intrusione da sole. L'esfiltrazione — gigabyte di PII compressi e spediti via SSH — si è conclusa senza un allarme interno nella stragrande maggioranza dei casi. La sola Università di Nottingham ha perso circa 40 GB di dati personali e di fatturazione relativi a centinaia di migliaia di studenti attuali ed ex.

È il punto cieco di detection canonico, e non ha nulla a che fare con la novità della CVE. La CVE era un mezzo di consegna. La ragione per cui la violazione è stata silenziosa è che la post-exploitation viveva interamente in pattern di traffico che EDR e NDR basati su firma gestiscono male per costruzione:

• Un agent RMM (MeshCentral) che deve fare beacon in uscita.
• Un dominio C2 che sembra cloud storage.
• Esfiltrazione su SSH, cifrata, verso un IP che nessuno aveva segnalato perché nessuno aveva una baseline di con chi quel server parla normalmente.
• Movimento laterale su SMB dentro una rete piatta dove l'SMB è ovunque.

Gli agent endpoint non sono scattati perché nulla sull'endpoint somigliava a malware. Il pattern era anomalo, non malevolo-per-firma — e "volume in uscita anomalo da un host che storicamente solo riceve" è esattamente la classe di evento che non finisce mai in una regola, perché nessun analista scrive quella regola per ogni singolo host.

Il vero conto alla rovescia non è la SLA di patching — è quello della notifica

Applica la patch a CVE-2026-35273 e hai chiuso la porta da cui l'attaccante è già passato. È necessario, e non è la parte difficile. Per le entità regolate di questa campagna — e le università lo sono sempre di più — nel momento in cui arriva la notifica di Google parte un orologio diverso e molto meno indulgente.

Con l'art. 33 del GDPR, il titolare ha 72 ore dal momento in cui viene a conoscenza di una violazione di dati personali per notificarla all'autorità di controllo. Con la NIS2, le entità essenziali e importanti devono un preallarme entro 24 ore e una notifica più completa entro 72. Molte università ed enti di ricerca europei rientrano nell'ambito ricerca e istruzione della NIS2 nelle rispettive trasposizioni nazionali, e quasi tutti sono titolari del trattamento di enormi quantità di PII studentesche. Quindi la domanda operativa dell'11 giugno non era "come applichiamo la patch" — era:

• Quali categorie di dati personali erano nell'archivio esfiltrato?
• Quando esattamente è avvenuta l'esfiltrazione, e per quanto tempo?
• Di chi sono i record — studenti attuali, alumni, candidati, personale?
• E soprattutto: possiamo dimostrare una qualunque di queste risposte, o le stiamo ricostruendo a partire dai buchi?

È su quest'ultima domanda che la maggior parte delle risposte agli incidenti crolla. La notifica entro 72 ore non viene sanzionata perché è una brutta notizia. Viene sanzionata se è assente, tardiva o — peggio ancora in un audit — smentita in seguito perché lo scope iniziale era a indovinare. Un'organizzazione che non sa produrre un resoconto difendibile e con marca temporale di ciò che ha lasciato la rete è costretta a scegliere tra il sotto-dichiarare (un'inadempienza) e il sovra-notificare a ogni interessato (un problema reputazionale e legale). Le divulgazioni di Coupang e Kyushu Electric della stessa settimana ricordano che la prima domanda del regolatore non è mai "siete stati violati" — è "cosa mi puoi mostrare".

Auditor: "Avete dichiarato 450.000 studenti coinvolti. Come siete arrivati a quel numero?"

Interlocutore: "È la dimensione della tabella nel sistema che hanno raggiunto."

Auditor: "È la dimensione di ciò che avrebbero potuto prendere. Le sto chiedendo cosa hanno preso. Avete il record dell'egress?"

Se la risposta all'ultima domanda è "no", la violazione è ora anche un problema di prova, e il problema di prova sopravvive alla patch per anni — attraverso l'istruttoria del regolatore, le richieste degli interessati e la perizia dell'assicurazione cyber.

L'higher education è il bersaglio morbido con gli obblighi duri

ShinyHunters non ha preso di mira le università per caso. Il 68% delle organizzazioni colpite apparteneva all'istruzione superiore. Il settore è un punto debole strutturale: PeopleSoft è di fatto l'ERP per anagrafe studenti, HR e finanza in fette enormi del mondo accademico; le installazioni sono datate, federate e spesso esposte su internet per l'accesso remoto dei campus; e i team di sicurezza sono sottodimensionati rispetto alla massa di PII su cui siedono. Una singola compromissione di PeopleSoft restituisce decenni di record studenteschi — esattamente i dati che si monetizzano su un leak site ed esattamente i dati la cui perdita fa scattare gli obblighi di notifica più pesanti.

La combinazione è feroce: la PII di valore più alto, la copertura di detection più sottile e ora un quadro normativo (NIS2 più GDPR) che dà per scontato che tu sappia rendere conto di ciò che è successo. Quel presupposto è il buco che questa campagna ha messo a nudo.

Dove si inserisce Zero Hunt

Il conto alla rovescia della notifica è implacabile proprio perché la prova di solito manca. Il pilastro Automatic Compliance di Zero Hunt è costruito per il momento successivo all'arrivo della notifica. Ogni finding, scansione e remediation viene mappato in continuo su 32 framework — GDPR, NIS2 (incluso il Titolo 13), ISO 27001 e gli altri — con mappatura cross-framework dei controlli, così che un singolo finding di esposizione di PeopleSoft ricada simultaneamente nella tua postura art. 32 GDPR, nei tuoi obblighi NIS2 da entità essenziale e nel tuo audit ISO, invece di essere ridiscusso tre volte. Ogni record è firmato ECDSA al momento della scrittura con catena di custodia per costruzione, che è la differenza tra dire al regolatore "crediamo 450.000 record" e consegnargli un resoconto verificabile e con marca temporale tramite il Trust Center — l'export pronto per l'auditor in un clic, che trasforma la corsa delle 72 ore in un recupero.

Ma la prova deve esistere prima di poter essere firmata, ed è qui che il pilastro AI Traffic Analysis risponde alla parte di questa campagna che l'ha resa silenziosa. Zero Hunt esegue un modello di deep learning proprietario con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo — addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'appliance a 2,7+ Gbit/s. La sequenza esatta che ha svuotato un centinaio di server PeopleSoft — un host che storicamente solo riceve apre all'improvviso una sessione SSH in uscita verso un IP mai visto, trasportando un archivio compresso con zstd, dopo una raffica di fan-out SMB interno — è la firma comportamentale che il modello è costruito per segnalare mentre sta accadendo, non nel digest del SIEM del mattino dopo. È quel record di egress che l'auditor chiede. E il pilastro di generative pentest è ciò che trova il /PSEMHUB/hub esposto sul tuo perimetro, in una campagna attivata dal cambiamento, prima che ShinyHunters esegua la stessa scansione che tu non hai fatto.

Una patch chiude CVE-2026-35273. Non risponde al regolatore. Le organizzazioni che usciranno più pulite da questa campagna saranno quelle in grado di dire, sul filo e nel log di audit, esattamente cosa è uscito — e di dimostrarlo.

Scopri come l'evidenza di compliance continua e l'analisi del traffico a velocità di rete si incastrano sulla piattaforma Zero Hunt, oppure contattaci.