ServiceNow, la RCE pre-autenticazione CVE-2026-6875 è sfruttata in the wild: istanze self-hosted da mettere in sicurezza

Una vulnerabilità critica nella piattaforma AI di ServiceNow consente a un attaccante non autenticato di eseguire codice da remoto e prendere il controllo dell’istanza. Identificata come CVE-2026-6875 , è passata dalla pubblicazione del proof of concept tecnico ai primi payload osservati in rete in circa 72 ore, e la finestra di esposizione per chi gestisce ambienti self-hosted resta aperta.

Il perimetro non è marginale. ServiceNow dichiara di elaborare oltre 100 miliardi di workflow l’anno e di alimentare più di 100.000 applicazioni AI enterprise presso l’85 per cento delle aziende Fortune 500: la superficie interessata è quella dei processi di IT service management, workflow e automazione su cui poggiano interi reparti IT, e il raggio d’azione di un singolo exploit riuscito è proporzionale.

La catena tecnica di CVE-2026-6875: dall’iniezione all’esecuzione di codice

La ricerca è firmata da Assetnote, il team di attack surface management di Searchlight Cyber, che l’ha documentata nel report Smashing the ServiceNow Sandbox. Il punto di ingresso è la GlideRecord query API, l’interfaccia con cui centinaia di percorsi applicativi recuperano dati dalle tabelle. In diversi punti raggiungibili prima dell’autenticazione, l’input dell’utente arriva fino alla query senza sanitizzazione.

Il primo trucco sfrutta una funzione documentata: anteponendo javascript: a un valore, ServiceNow valuta la stringa come JavaScript prima di usarla come argomento di query. Ogni sink non autenticato diventa così un potenziale punto di esecuzione di script. La piattaforma anticipava questo scenario con un secondo strato di isolamento, lo script sandbox, che blocca eval , limita le classi Java accessibili e rende le tabelle in sola lettura per gli utenti non autenticati.

L’elemento centrale della ricerca è l’evasione di quello strato. Sovrascrivendo Object.clone con il costruttore Function e assegnando AbstractAjaxProcessor.prototype al payload dell’attaccante, una successiva chiamata a gs.include('ItemViewElementsProvider') induce la sandbox a invocare Function(payload) in un contesto privo di restrizioni: il risultato è una funzione eseguibile che lancia codice arbitrario. Il sink pre-autenticazione effettivamente raggiungibile è l’endpoint /assessment_thanks.do , tramite il parametro sysparm_assessable_type , che passa l’input direttamente nella query. Da lì, spiega il report, si possono estrarre dati da qualunque tabella, creare utenti amministratori a piacere ed eseguire comandi sui MID Server proxy configurati, spesso collocati all’interno delle reti aziendali.

La vulnerabilità, un sandbox escape nella piattaforma AI, è valutata 9,5 su 10, severità critica. Come sempre nei sistemi che introducono un rischio di questo tipo attraverso AI e automazione, l’esposizione dipende anche dai privilegi concessi agli agenti che operano nella piattaforma, un tema già affrontato analizzando la identity security degli agenti.

Tempistiche: cloud protetto ad aprile, patch self-hosted da giugno

La cronologia aiuta a inquadrare il rischio residuo. Assetnote ha segnalato il difetto a ServiceNow il 1° aprile 2026; il vendor ha applicato una mitigazione lato cloud entro 24 ore, bloccando la modifica delle funzioni JavaScript chiave. Per i clienti e i partner self-hosted le patch e gli aggiornamenti di sicurezza sono stati resi disponibili nel corso di giugno, come precisato da Help Net Security in una rettifica esplicita; il 13 luglio ServiceNow ha poi pubblicato l’advisory ufficiale ( KB3137947 ), consolidando la comunicazione pubblica, e il giorno seguente Searchlight ha diffuso i dettagli tecnici, con un proof of concept finito pubblico.

Le correzioni risultano incluse in Brazil EA e GA, Australia Patch 2, Zurich Patch 7b e Patch 9, Yokohama Patch 12 Hot Fix 1b e Patch 13. Chi ha già ricevuto la mitigazione cloud è coperto; il punto critico riguarda le organizzazioni che gestiscono ServiceNow in casa e non hanno ancora applicato gli aggiornamenti disponibili, a prescindere dalla data esatta di prima distribuzione.

Lo sfruttamento è già in corso

I primi tentativi di sfruttamento sono stati osservati venerdì 17 luglio; la conferma pubblica è arrivata il giorno successivo, quando la società di threat intelligence Defused ha documentato lo sfruttamento in the wild, rilevando payload che colpiscono lo stesso sink pre-autenticazione documentato da Searchlight, /assessment_thanks.do , ma raggiungono l’esecuzione di codice attraverso una diversa gadget chain. Il quadro è riportato anche da Security Affairs.

Non è la prima volta che ServiceNow si trova in questa posizione. Nel luglio 2024 la critica CVE-2024-4879 , anch’essa individuata da Assetnote, fu sfruttata contro oltre 105 organizzazioni tra agenzie governative, aziende energetiche e software house entro pochi giorni dalla pubblicazione di un writeup tecnico, con dati finiti su forum criminali e successivo inserimento nel catalogo Known Exploited Vulnerabilities della CISA il 29 luglio 2024; lo documentano i rilievi di Resecurity, ripresi da BleepingComputer e TechTimes. Il ritardo tra disponibilità della correzione e adozione è quindi un rischio concreto, non teorico.

Vale la pena segnalare una tensione: l’advisory di ServiceNow, al momento, continua a dichiarare di non aver riscontrato prove che l’attività sia legata alle istanze che ospita. La rilevazione indipendente di attività ostile mentre la comunicazione ufficiale non la registra ancora è un elemento che i team di sicurezza dovrebbero pesare nella propria valutazione del rischio, senza attendere una conferma dal fornitore per agire.

Per chi amministra istanze self-hosted, l’indicazione operativa è diretta: applicare gli aggiornamenti disponibili come intervento urgente, verificare gli accessi ai /assessment_thanks.do nei log e trattare come sospetta la creazione di nuovi utenti amministrativi o l’esecuzione di comandi sui MID Server. Sul piano più ampio, la vicenda ribadisce che l’estensione delle piattaforme aziendali verso funzioni agentiche moltiplica i sink raggiungibili e i percorsi di escape, una dinamica già osservata con la prompt injection negli agenti sulla stessa classe di prodotti.