ServiceNow corregge la RCE pre-auth CVE-2026-6875 tramite sandbox escape

🛡️ Executive Summary

• CVE-2026-6875 sfrutta gs.include negli endpoint pre-auth per uscire dal sandbox delle query GlideRecord ed eseguire JavaScript arbitrario.
• L’attacco consente di leggere tabelle, ignorare le ACL, creare amministratori e raggiungere MID Server collegati alle reti aziendali.
• ServiceNow ha mitigato le istanze cloud entro 24 ore e introdotto Guarded Script nelle patch definitive.

ServiceNow ha corretto CVE-2026-6875, una vulnerabilità critica di esecuzione remota di codice pre-autenticazione capace di compromettere completamente un’istanza senza richiedere credenziali. La falla permetteva di uscire dal sandbox applicato alle query GlideRecord abusando della funzione gs.include(), utilizzata per caricare Script Include eseguiti in un contesto meno restrittivo. Un aggressore poteva leggere dati protetti, ignorare le ACL, creare utenti amministrativi e raggiungere i MID Server collegati alla rete interna. Dopo la segnalazione del ricercatore Adam Kues, ServiceNow ha mitigato tutte le istanze cloud entro 24 ore e sviluppato il nuovo meccanismo Guarded Script.

CVE-2026-6875 parte da un endpoint accessibile senza autenticazione

Il vettore iniziale coinvolge endpoint pubblicamente raggiungibili come assessment_thanks.do, nei quali alcuni parametri vengono utilizzati per costruire filtri GlideRecord. Il parametro sysparm_assessable_type accettava stringhe con prefisso javascript:, valutate dal motore durante l’elaborazione della query. ServiceNow applicava a questo codice un sandbox progettato per impedire l’uso di funzioni pericolose, classi Java e costrutti complessi, ma l’attaccante poteva sfruttare gs.include() per caricare componenti preinstallati ed eseguire il payload fuori dal contesto ristretto. La natura pre-auth rende la falla più grave delle precedenti vulnerabilità ServiceNow capaci di esporre dati riservati, perché non richiede un account valido, una sessione compromessa o l’interazione di un dipendente. È sufficiente inviare una richiesta costruita verso un’istanza vulnerabile e raggiungibile dalla rete.

gs.include permette di superare il doppio sandbox

La piattaforma utilizza due livelli di isolamento. Il primo limita per tutti gli script l’accesso alle API più sensibili e alle classi Java sottostanti; il secondo applica restrizioni aggiuntive agli input non fidati inseriti nei filtri delle query. Questo ambiente vietava eval, new Function, dichiarazioni di funzione e accesso esteso all’oggetto gs, ma lasciava utilizzabile gs.include(). Alcuni Script Include richiamano internamente Object.extendsObject e Object.clone, funzioni che potevano essere manipolate attraverso Object.defineProperty. L’attaccante ridefiniva Object.clone, alterava il prototipo di AbstractAjaxProcessor e includeva successivamente uno script che invocava il percorso compromesso, ottenendo l’esecuzione del codice iniettato. Il meccanismo ricorda le falle critiche nella sandbox vm2 per Node.js, dove una funzione apparentemente consentita diventava il ponte verso primitive escluse dal modello di sicurezza. In entrambi i casi, il problema non risiedeva nell’assenza del sandbox, ma nella possibilità di raggiungere indirettamente un contesto più privilegiato.

L’exploit consente il controllo completo dell’istanza

Dopo l’escape, il payload otteneva accesso al motore Rhino JavaScript e alle classi Java utilizzate dalla piattaforma. L’aggressore poteva interrogare qualsiasi tabella, ignorare le Access Control List, leggere informazioni aziendali e creare un nuovo account con privilegi amministrativi. La compromissione poteva estendersi anche oltre il servizio cloud: le istanze ServiceNow vengono spesso integrate con MID Server, proxy e componenti collocati nella rete interna per gestire discovery, automazione e collegamenti con sistemi aziendali. L’esecuzione di comandi su questi server avrebbe aperto un percorso verso il movimento laterale e l’accesso a infrastrutture non esposte direttamente su Internet. Per questo la falla rientra pienamente nelle RCE che trasformano un singolo endpoint nel controllo dell’intero ambiente. La combinazione tra assenza di autenticazione, bypass delle ACL e collegamenti verso sistemi interni rendeva CVE-2026-6875 una vulnerabilità adatta tanto al furto di dati quanto alla persistenza e alla compromissione della rete.

ServiceNow mitiga il cloud e introduce Guarded Script

Adam Kues, ricercatore di Searchlight Cyber, ha segnalato la falla il 1° aprile 2026. ServiceNow ha distribuito entro 24 ore una mitigazione su tutte le istanze cloud, impedendo la modifica di primitive JavaScript critiche come Class.create e Object.clone. Nelle settimane successive sono arrivate le patch definitive e il nuovo sistema Guarded Script, progettato per ridurre drasticamente ciò che può essere eseguito nei filtri non fidati. Il meccanismo accetta una sola espressione semplice e vieta dichiarazioni var, let e const, strutture if, switch, for e while, definizioni di funzione e catene di assegnazione. La scelta elimina la complessità necessaria per costruire un payload di sandbox escape, seguendo un approccio più restrittivo rispetto alla semplice aggiunta di nuove funzioni a una blacklist. La rapidità dell’intervento riduce l’esposizione delle istanze SaaS, mentre gli ambienti gestiti direttamente devono verificare l’applicazione delle release indicate nella documentazione KB2944435.

Gli amministratori devono controllare endpoint e MID Server

Le organizzazioni devono confermare che l’istanza abbia ricevuto le mitigazioni cloud o le patch definitive e analizzare i log relativi a assessment_thanks.do, sysparm_assessable_type e stringhe contenenti javascript:. Devono essere ricercate chiamate anomale a gs.include, modifiche inattese agli Script Include, creazione di utenti amministrativi e accessi alle tabelle non coerenti con le normali attività. La verifica deve estendersi ai MID Server, controllando processi, comandi, connessioni in uscita e variazioni delle credenziali utilizzate per comunicare con l’istanza. Le catene di takeover remoto contro piattaforme enterprise come Flowise e Docker dimostrano che il rischio maggiore emerge quando un servizio applicativo possiede collegamenti fidati verso altri sistemi. In presenza di indicatori sospetti, non basta applicare la patch: occorre ruotare segreti e account amministrativi, ricostruire la sequenza delle attività e verificare che l’aggressore non abbia utilizzato ServiceNow come ponte verso la rete interna.