ServiceNow CVE-2026-6875: la sandbox escape pre-auth che apre l'intera piattaforma

ServiceNow sta sotto le parti dell'azienda che non entrano mai nel threat model: ticket IT, onboarding HR, vendor risk, change management, la CMDB che ogni altro strumento considera fonte di verità. Per molte imprese è anche il sistema più ricco di credenziali sul perimetro, perché si integra con tutto. Il 13 luglio 2026 ServiceNow ha completato la distribuzione delle patch ai clienti self-hosted per CVE-2026-6875, una sandbox escape non autenticata con CVSS 9.5 che trasforma una richiesta pre-auth in esecuzione di codice remoto dentro la piattaforma. Il weekend successivo era già sfruttata in the wild — e i payload visti negli attacchi non corrispondevano al proof-of-concept appena pubblicato.

È proprio quest'ultimo dettaglio la storia vera. Non è un articolo su una patch da applicare (va applicata — sotto trovate i dettagli). È su cosa succede quando la via per arrivare a un bug non si chiude sistemando una singola istanza di quella via, e sul perché una classe di vulnerabilità con più di un percorso di sfruttamento sconfigge ogni difesa costruita attorno al primo che qualcuno ha pubblicato.

Il bug: un prefisso javascript: di cui il query layer si fidava

La piattaforma ServiceNow esegue JavaScript non attendibile — comprese stringhe che arrivano prima dell'autenticazione — dentro una sandbox a due livelli. Il livello esterno concede allo script un raggio d'azione vicino a quello dell'amministratore di piattaforma, ma lo isola dal sistema operativo host. Il livello interno, la sandbox filter o script, dovrebbe essere il confine duro per l'input dell'utente: blocca eval, la costruzione dinamica di Function e l'accesso alle classi Java.

L'escape, scoperta e segnalata da Searchlight Cyber, vive nel modo in cui quel confine viene raggiunto. Percorsi applicativi pre-autenticazione passavano input controllato dall'utente all'API di query GlideRecord, e addQuery() accetta un prefisso javascript: — che porta la piattaforma a valutare l'espressione JavaScript prima di usarne il risultato come argomento della query. Una richiesta raggiunge il motore di query, il motore di query esegue il tuo codice. L'endpoint pre-auth documentato è /assessment_thanks.do, come riportato da BleepingComputer.

Entrare nella sandbox degli script non è la stessa cosa che uscirne. La ricerca pubblicata scala tramite gs.include(), che carica librerie di script in un contesto d'esecuzione meno restrittivo. Manipolando oggetti globali JavaScript e il comportamento del function-constructor su cui gli script inclusi fanno affidamento, un attaccante ottiene che codice arbitrario venga compilato ed eseguito fuori dalla sandbox stretta — passando da "espressione di filtro ristretta" a "contesto di scripting ServiceNow privilegiato". Da lì l'isolamento è finito.

Dalla sandbox escape alla compromissione dell'istanza

CVSS 9.5 non è marketing. Fuori dalla sandbox interna, l'attaccante opera con il raggio quasi-admin del livello esterno. Nel concreto, l'impatto divulgato è:

• Lettura di qualsiasi tabella. CMDB, record di incident, casi HR, segreti nelle system property — il modello dati di ServiceNow è un unico grande insieme di tabelle, e l'accesso alle tabelle è totale.
• Creazione di account amministratore. Persistenza che sopravvive alla sessione e sembra un utente legittimo finché qualcuno non audita i ruoli in sys_user.
• Esecuzione di comandi sui MID Server connessi. È questo il pivot che conta. Un MID Server è l'agente che ServiceNow colloca dentro la tua rete per raggiungere i sistemi on-prem che orchestra — Active Directory, vCenter, apparati di rete. L'esecuzione di comandi su un MID Server porta una compromissione SaaS cloud dritta nel patrimonio interno, con le credenziali che il MID Server già possiede.

Il raggio d'azione quindi non è "hanno bucato un sistema di ticketing". È: leggere tutto ciò che ServiceNow sa, coniarsi un admin, e attraversare il MID Server fino alla rete che ServiceNow era stato messo a gestire.

Perché la firma del PoC di ServiceNow CVE-2026-6875 non ti salva

Ecco la parte che dovrebbe cambiare il modo di ragionarci. Quando lo sfruttamento è iniziato nel weekend del 18–19 luglio, la società di threat intelligence Defused ha osservato che i payload in the wild raggiungevano lo stesso primitivo di esecuzione codice per una via diversa dal PoC pubblicato — una seconda catena di sandbox escape che bypassa le difese tarate sulla prima. Sia Help Net Security sia TechTimes hanno riportato lo sfruttamento multi-percorso.

È il modello di fallimento della validazione basata su firma, detto nel modo più pulito possibile. Una sandbox escape non è una singola stringa; è una proprietà di come si compongono le vie d'uscita della sandbox. gs.include() è un percorso d'uscita. Il trucco del function-constructor è un'altra leva. Qualsiasi regola WAF, firma IDS o rassicurazione del tipo "abbiamo testato l'exploit pubblico e l'abbiamo bloccato" scritta contro la prima catena è cieca verso la seconda — e non c'è ragione di credere che due sia il tetto. La classe di bug (input non attendibile che raggiunge una sandbox con primitivi d'uscita accessibili) genera exploit più in fretta di quanto i difensori generino firme.

"Abbiamo lanciato il PoC pubblico sulla nostra istanza e il WAF l'ha bloccato — siamo coperti."

Hai bloccato una serializzazione del bug. L'istanza bucata sabato è stata colpita da una catena che la tua regola non ha mai visto, che raggiunge lo stesso primitivo di classe gs.include() da un'altra direzione. La firma corrispondeva a un payload. La vulnerabilità è una proprietà.

Il patch gap che ha fatto entrare gli attaccanti

La cronologia è a sua volta una lezione sul perché "patchato" sia una parola sfumata per il SaaS multi-tenant con un tier self-hosted. Searchlight Cyber ha segnalato la falla a ServiceNow ai primi di aprile 2026. ServiceNow ha patchato le istanze hosted ad aprile — silenziosamente, come fanno i vendor cloud. I clienti self-hosted, che eseguono ServiceNow nei propri datacenter (settori regolati, PA, difesa), hanno ricevuto le patch solo lungo giugno, con divulgazione pubblica e write-up tecnico il 13 luglio. Lo sfruttamento è seguito in pochi giorni.

È la forma ricorrente dei CVE "SaaS-più-on-prem": i tenant del vendor sono al sicuro settimane prima dei clienti che il software lo eseguono da sé, e la divulgazione pubblica che finalmente allerta la flotta self-hosted è anche il colpo di pistola di partenza per gli attaccanti. La posizione pubblica di ServiceNow all'inizio dello sfruttamento era di "non essere attualmente a conoscenza di sfruttamento contro istanze ServiceNow" — mentre ricercatori indipendenti lo stavano guardando accadere. Non è la prima volta che i layer di query e template di ServiceNow vengono trasformati in RCE: la catena di Jelly-injection CVE-2024-4879 è stata sfruttata in massa sulle istanze esposte nel 2024. La lezione di quel giro — che una ServiceNow esposta a internet è un bersaglio ad alto valore e attivamente cacciato — non è scaduta.

Remediation

Tratta ogni istanza ServiceNow self-hosted raggiungibile da internet come presunta-bersaglio. Procedi dall'alto verso il basso.

1. Sono esposto?

Verifica famiglia e patch level dell'istanza in System Diagnostics → Stats (o dal build tag). Sei vulnerabile se stai eseguendo una qualsiasi di:

Famiglia release	Vulnerabile se sotto	Versione corretta
Brazil	pre-EA/GA	Brazil EA, Brazil GA
Australia	prima di Patch 2	Australia Patch 2
Zurich	prima di Patch 7b / Patch 9	Zurich Patch 7b, Zurich Patch 9
Yokohama	prima di Patch 12 Hot Fix 1b / Patch 13	Yokohama Patch 12 Hot Fix 1b, Yokohama Patch 13

Le istanze hosted (gestite da ServiceNow) sono state rimediate dal vendor ad aprile 2026. L'esposizione che conta ora è quella self-hosted. Verifica la superficie pre-auth: /assessment_thanks.do e ogni percorso .do non autenticato raggiungibile da internet non dovrebbero esserlo.

2. Patch — versioni corrette esatte

Applica la fix indicata per la tua famiglia secondo l'advisory ServiceNow KB3137947: Brazil EA, Brazil GA, Australia Patch 2, Zurich Patch 7b, Zurich Patch 9, Yokohama Patch 12 Hot Fix 1b, Yokohama Patch 13. Non rimandare perché hai lanciato il PoC pubblico e non ha funzionato — una seconda catena in the wild bypassa già quell'assunto.

3. Non puoi patchare questa settimana? Controlli compensativi

• Abilita Guarded Script, la mitigazione ServiceNow che restringe il tipo di codice ammesso nei contesti sandbox. Riduce la superficie d'uscita anche dove non puoi ancora applicare la patch di versione.
• Blocca il sink pre-auth al bordo. Nega l'accesso non autenticato a /assessment_thanks.do e audita quali endpoint .do il reverse proxy espone senza sessione. Non affidarti a una regola WAF che corrisponde alla stringa del PoC pubblicato — scrivi la regola contro l'endpoint, non contro il payload.
• Restringi i MID Server. Ruota subito le credenziali del service account dei MID Server al minimo privilegio, prima che un'escape diventi un pivot. Un MID Server che può raggiungere il Domain Admin è un percorso di movimento laterale pre-autorizzato.
• Riduci l'esposizione di gestione. Se l'istanza non deve essere esposta a internet, mettila dietro VPN/ZTNA immediatamente.

4. Caccia alla compromissione

La finestra di sfruttamento pre e post patch rende il rilevamento importante anche dopo aver patchato. Mappa su MITRE ATT&CK e caccia:

• Accesso iniziale — T1190 (Exploit Public-Facing Application): richieste a /assessment_thanks.do e altri percorsi .do pre-auth con parametri con prefisso javascript: o token GlideRecord/addQuery/gs.include in query string o body POST. Rivedi i log di accesso dei nodi e i transaction log (syslog_transaction), non solo il WAF.
• Esecuzione — T1059.007 (JavaScript): esecuzione di script inattesa fuori dal contesto autenticato di business rule/scheduled job; attività anomala su sys_script / sys_script_include.
• Persistenza — T1136 (Create Account): nuovi record sys_user con ruoli admin (o security_admin) creati fuori dal workflow di provisioning; nuovi token API o client OAuth.
• Movimento laterale / accesso alle credenziali — T1210 e T1552 (Unsecured Credentials): esecuzione di comandi o connessioni in uscita anomale che originano da host MID Server; uso di credenziali del MID Server verso sistemi che normalmente non tocca.
• Raccolta — T1213 (Data from Information Repositories): export massivi di tabelle, letture ampie di sys_attachment, o query fuori orario contro tabelle sensibili (CMDB, sys_user, store di credenziali/vault).

Poiché la catena in the wild differisce dal PoC, caccia l'esito (admin inatteso, anomalia MID Server, lettura massiva di tabelle) tanto quanto la firma in ingresso.

5. Eradica e verifica

• Rimuovi account admin/service, token API e registrazioni OAuth che non riesci a legare a un change record.
• Ruota tutto ciò che l'istanza custodiva: credenziali dei MID Server, service account di integrazione, segreti di connessione nelle system property, e ogni credenziale che la CMDB o un discovery job potessero leggere. Se trovi evidenza di sfruttamento, assumi che i contenuti delle tabelle siano stati esfiltrati.
• Conferma la pulizia dopo la patch — rilancia il rilevamento contro l'istanza patchata, verifica che Guarded Script sia applicato, e valida che non resti esposizione .do pre-auth residua.

Dove un pentest generativo cambia lo scenario

Il tratto distintivo di CVE-2026-6875 è che un PoC pubblicato ha dato un falso senso di copertura: l'exploit che contava ha preso una via diversa verso lo stesso primitivo. Fare signature-matching su un singolo payload non può validare una sandbox con più vie d'uscita accessibili. Dimostrare se la tua istanza è sfruttabile richiede scrivere un exploit contro la tua configurazione — quali endpoint .do esponi, quale release e patch level, se Guarded Script è attivo, cosa può raggiungere un MID Server se l'escape riesce.

È ciò che fa lo swarm di 10 agenti AI di Zero Hunt. Gli agenti Exploit e Web generano una catena di exploit per-target con un LLM locale — codice scritto per l'ambiente che hanno davanti, non pescato da ExploitDB — così la validazione copre la classe di escape e non l'unica catena che un ricercatore ha pubblicato. Ogni skill candidata è backtestata nell'AI Gym (142+ skill auto-evolutive, benchmarkate su Vulhub, NYU CTF Bench e Vulhub-Bench) prima di girare in produzione, e ogni finding è firmato ECDSA con chain-of-custody, così "abbiamo validato l'esposizione ServiceNow" è un artefatto probatorio, non un'affermazione.

Il pivot via MID Server è dove il secondo pilastro guadagna il suo posto. Se un'escape effettivamente ponte verso la rete interna, il traffico che genera — un host MID Server che d'improvviso esegue comandi e si muove lateralmente, query sostenute contro tabelle sensibili — è esattamente il comportamento che il modello di deep learning sul traffico di Zero Hunt (quattro teste di inferenza, 2.7+ Gbit/s, senza cloud) è costruito per segnalare mentre accade, non nel digest SIEM del mattino dopo. Per un bug la cui forma in the wild ha superato il suo stesso PoC, la difesa che regge è quella che testa la proprietà e osserva il comportamento — scopri la piattaforma o contattaci.