La segnalazione è arrivata il primo aprile

Il 1 aprile 2026 Adam Kues di Assetnote, il ramo di ricerca di Searchlight Cyber, ha inviato a ServiceNow un rapporto in cui descriveva un modo per eseguire codice sulla ServiceNow AI Platform senza alcuna credenziale. L'azienda si è mossa in fretta. Nel proprio resoconto della divulgazione il gruppo di ricerca annota che ServiceNow ha "applicato solide mitigazioni a tutte le istanze cloud entro 24 ore dalla nostra segnalazione" e ha fatto seguire nelle settimane successive le patch per i difetti sottostanti. Ogni cliente su un'istanza ospitata da ServiceNow era protetto già ai primi di aprile, senza dover muovere un dito e senza nemmeno saperlo.

Chi invece gestisce una propria copia non ha saputo nulla fino al 13 luglio, quando ServiceNow ha pubblicato l'avviso di sicurezza KB3137947 e ha rilasciato gli aggiornamenti per le installazioni on-premise. La falla è tracciata come CVE-2026-6875. ServiceNow, che agisce come CNA di sé stessa, le ha attribuito un punteggio CVSS 4.0 pari a 9,5 su 10. Il vettore riporta complessità di attacco elevata ma nessun privilegio e nessuna interazione dell'utente, ed è proprio questa combinazione a rendere appetibile un'istanza raggiungibile da internet per chi scandaglia la rete su larga scala.

Tra le due date passano 103 giorni. Per un'azienda SaaS questa è una divulgazione coordinata condotta bene. Per la parte di clientela che gestisce la piattaforma in proprio è un trimestre passato con addosso una falla critica sfruttabile prima dell'autenticazione, che il fornitore aveva già chiuso sul proprio parco.

Una sandbox che accettava di valutare JavaScript

La vulnerabilità sta nella sandbox della ServiceNow AI Platform, lo strato di contenimento che dovrebbe permettere al codice della piattaforma di girare senza raggiungere ciò che non deve. Il punto di ingresso è l'API GlideRecord, che supporta la valutazione di JavaScript dentro i filtri delle query. Un input fornito dall'utente arrivava a una chiamata addQuery con il prefisso javascript:, e la piattaforma lo valutava.

Una seconda sandbox avrebbe dovuto intercettare proprio questo caso e bloccare le funzioni pericolose. I ricercatori l'hanno aggirata con una catena di gadget costruita su Object.clone e Class.create.constructor, che insieme permettono l'esecuzione arbitraria di funzioni durante gli script include. Il punto di ingresso dimostrato è l'endpoint /assessment_thanks.do attraverso il parametro sysparm_assessable_type, e niente di tutto questo richiedeva un'autenticazione.

Quello che un aggressore ottiene non è un appiglio in un angolo del prodotto. L'analisi di Searchlight descrive la lettura di dati dalle tabelle, la creazione di account amministratore e l'esecuzione di comandi shell su qualsiasi proxy MID Server configurato, proxy che, come osservano i ricercatori, si trovano abitualmente dentro le reti interne delle aziende. Il MID Server è l'elemento che rientra nel vostro parco per censire gli asset ed eseguire le automazioni. È il ponte, e il ponte si raggiunge partendo dal difetto.

Chi si è tenuto davvero il rischio

Nei consigli di amministrazione europei l'istinto abituale è che l'on-premise sia l'opzione prudente. I dati restano sul proprio ferro, la questione della residenza si liquida in una frase e si evita di mettere sotto gli occhi di un regolatore uno schema imbarazzante. Nei settori regolamentati dell'UE, nella pubblica amministrazione, nel settore bancario e tra i gruppi più strutturati del tessuto industriale di media dimensione, è questo istinto a spiegare perché una quota non trascurabile dei parchi ServiceNow non stia sul cloud di ServiceNow.

Questo avviso di sicurezza ribalta il ragionamento. Chi aveva scelto il cloud del fornitore è stato protetto nei primi giorni di aprile da una mitigazione che non ha mai dovuto chiedere. Chi aveva scelto di gestirlo in proprio, per avere il controllo, si è tenuto addosso una falla di esecuzione di codice remoto non autenticata per tutto aprile, maggio, giugno e mezzo luglio, e ne è stato informato solo quando la correzione era pronta da distribuire. Il controllo sull'installazione si è rivelato la proprietà della finestra di esposizione.

Niente di tutto questo rende scorretta la condotta di ServiceNow. Distribuire mitigazioni su un parco che si gestisce direttamente è semplicemente più rapido che far arrivare patch su un parco altrui, e trattenere i dettagli dell'avviso finché i clienti non sono in grado di agire è prassi consolidata, non occultamento. La lezione per chi opera è più circoscritta e più utile: "il fornitore ha corretto" e "noi siamo a posto" sono due affermazioni diverse, e questa volta in mezzo ci sono stati cento giorni.

Le due affermazioni sono vere nello stesso momento

Nel fine settimana del 18 e 19 luglio il gruppo di threat intelligence Defused ha segnalato sfruttamento attivo, con i primi tentativi osservati venerdì 17 luglio. L'avviso di sicurezza di ServiceNow, al lunedì mattina, continua a dichiarare che l'azienda "non è attualmente a conoscenza di sfruttamenti contro istanze ServiceNow". Messe una accanto all'altra, le due frasi sembrano quelle di un fornitore lento ad ammettere.

La faccenda è più interessante, e la riconciliazione è il cuore di questa storia. Le due parti stanno misurando popolazioni diverse. ServiceNow ha telemetria diretta sul parco che ospita, e quel parco è mitigato dai primi di aprile, quindi lì davvero non viene sfruttato nulla. Defused osserva il traffico su tutta internet, che è dove vivono le istanze on-premise. La popolazione che il fornitore non riesce a vedere è esattamente quella rimasta senza patch.

La frase del fornitore è dunque esatta e allo stesso tempo inservibile come dato di rischio per voi. "Nessuno sfruttamento confermato" detto da un fornitore SaaS è un'affermazione sul parco del fornitore stesso, a meno che non venga specificato altrimenti. Se il software lo gestite voi, l'unico stato di sfruttamento che descrive la vostra situazione è quello che ricavate dai vostri log.

L'exploit non ha aspettato il proof of concept

Defused è stata precisa su ciò che ha visto. I payload, ha riferito, "colpiscono lo stesso sink pre-autenticazione documentato da @SLCyberSec (/assessment_thanks.do), ma il gadget di evasione dalla sandbox raggiunge la stessa primitiva di esecuzione di codice per una strada diversa da quella del loro PoC pubblicato". Gli aggressori non stavano riproponendo l'exploit dei ricercatori. Erano arrivati alla stessa primitiva per conto proprio, avendo fatto il proprio lavoro a partire dallo stesso punto di partenza.

Questo dettaglio smonta un'abitudine di pianificazione molto diffusa nelle organizzazioni con controllo formale delle modifiche: considerare la comparsa di un proof of concept pubblico come il momento in cui parte l'orologio, e applicare la patch nella finestra successiva. Qui la capacità sviluppata in autonomia è arrivata insieme all'analisi pubblica e non dopo di essa, e l'avviso di sicurezza stesso, il 13 luglio, è stato l'ultimo avvertimento affidabile che qualcuno avrebbe ricevuto.

Che cosa controllare prima di martedì

Partite dalla famiglia di release, perché i nomi delle correzioni non sono intuitivi. Le versioni corrette sono Brazil EA e Brazil GA, Australia Patch 2, Zurich Patch 7b o Zurich Patch 9, Yokohama Patch 12 Hot Fix 1b o Yokohama Patch 13. Tutto ciò che sta sotto la soglia pertinente è vulnerabile, e un'istanza on-premise che non ha avuto una finestra di manutenzione dal 13 luglio in poi non è stata corretta da nessuno al posto vostro.

Poi date per scontato che quella finestra abbia pesato. Estraete i log di accesso relativi a /assessment_thanks.do e guardate in modo specifico il parametro sysparm_assessable_type. Riesaminate la creazione di account amministratore sull'intero periodo e non solo sulle ultime due settimane, perché la falla consente a un aggressore di crearsene uno. Passate poi ai MID Server, cercate esecuzioni di processo inattese e ricordate che quegli host stanno dentro la rete interna e non davanti a essa, ed è questo che trasforma un difetto di piattaforma in un problema di movimento laterale.

Se trovate qualcosa, l'orologio è regolamentare oltre che tecnico. Per i soggetti essenziali e importanti dell'UE la NIS2 impone un preallarme al proprio CSIRT nazionale entro 24 ore da quando si viene a conoscenza di un incidente significativo, più una notifica completa entro 72 ore. Nel Regno Unito, dove la NIS2 non si applica, il canale di segnalazione resta l'NCSC, e in entrambi i casi è il lavoro sulle evidenze a rendere la segnalazione degna di essere presentata.

Da leggere ora: Una richiesta poteva dirottare il tuo sito WordPress  |  Applicare la patch a SharePoint non chiude più la porta