ServiceNow ha pubblicato il 27 agosto 2026 un advisory che corregge quattro vulnerabilità della ServiceNow AI Platform. Tre di queste sono valutate 10.0 su CVSS 4.0, il punteggio massimo, e in determinate condizioni sono sfruttabili da un attaccante non autenticato.

L'azienda ha già aggiornato le istanze che ospita direttamente e ha reso disponibile la correzione a partner e clienti self-hosted. Il che significa che chi gestisce la propria istanza deve applicarla da sé.

Le vulnerabilità

  • CVE-2026-18885 (CVSS 10.0) — code injection nella GraphQL Composite Data API: consente a un utente non autenticato di eseguire codice arbitrario e di accedere ai dati dell'istanza o modificarli.
  • CVE-2026-18886 (CVSS 10.0) — controllo degli accessi improprio nel processore di upload delle immagini di configurazione di sistema: consente a un utente non autenticato di creare o modificare dati dell'istanza, con conseguente escalation di privilegi.
  • CVE-2026-74820 (CVSS 10.0) — SQL injection raggiungibile attraverso una clausola ORDER BY a schema dinamico: consente a un utente non autenticato di eseguire istruzioni SQL arbitrarie contro il database sottostante.
  • CVE-2026-6876 (CVSS 8.7) — evasione dalla sandbox della Now Platform con esecuzione di codice arbitrario.

Le tre falle da 10.0 condividono lo stesso vettore: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Tradotto: attacco raggiungibile dalla rete, bassa complessità, nessun privilegio richiesto, nessuna interazione dell'utente, impatto elevato su riservatezza, integrità e disponibilità sia del componente vulnerabile sia dei sistemi collegati. È l'ultima metà della frase a fare la differenza: il punteggio pieno arriva proprio perché il danno non si ferma a ServiceNow.

Le versioni interessate

ServiceNow indica come vulnerabili, nel proprio articolo KB3152242:

  • Xanadu — qualsiasi versione precedente a Patch 11 Hot Fix 7a
  • Yokohama — qualsiasi versione precedente a Patch 12 Hot Fix 3b e a Patch 13 Hot Fix 4
  • Zurich — qualsiasi versione precedente a Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m (ramo m), Patch 10 Hot Fix 3 (standard), Patch 11 o Patch 12
  • Australia — qualsiasi versione precedente a Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 o Patch 5

Tutte e quattro le schede impostano come stato predefinito del prodotto "non interessato": una release non elencata ricade quindi fuori dal perimetro. ServiceNow dichiara di non essere a conoscenza di sfruttamento in corso e, alla data del 28 agosto, non risultava codice di exploit pubblico per le tre falle di gravità massima.

Come leggere un 10.0 in questo caso

Qui serve una precisazione che raramente accompagna i titoli, e che invece cambia il modo di gestire la priorità.

I punteggi sono assegnati da ServiceNow stessa. L'azienda è CVE Numbering Authority per i propri prodotti, e dal 15 aprile 2026 il NIST arricchisce soltanto le vulnerabilità che compaiono nel catalogo KEV della CISA, che riguardano software del governo federale statunitense o che sono designate critiche ai sensi dell'Executive Order 14028. Nessuna delle quattro figura nel catalogo KEV. La valutazione del fornitore è quindi, al momento, l'unica agli atti: nessuno l'ha verificata in modo indipendente.

Questo non è un motivo per sottovalutarla, ma per leggerla con l'occhio giusto. Vale la pena ricordare un precedente recente sulla stessa piattaforma: CVE-2026-6875, evasione dalla sandbox pre-autenticazione, segnalata da Searchlight Cyber il 1° aprile 2026 e pubblicata il 13 luglio. Pochi giorni dopo l'advisory una società di threat intelligence dichiarò di osservare sfruttamento in rete, salvo poi correggersi: il payload catturato corrispondeva al proof-of-concept pubblicato dai ricercatori. ServiceNow, da parte sua, ha affermato di non aver riscontrato evidenze che quell'attività riguardasse istanze da lei ospitate.

Se ne ricava una lezione operativa: la disponibilità di un PoC pubblico si traduce quasi subito in traffico di scansione, e la distinzione fra "qualcuno sta testando l'exploit" e "qualcuno sta compromettendo aziende" è sottile ma decisiva quando si deve decidere se convocare un intervento fuori orario.

Un ultimo dettaglio utile: ServiceNow ha valutato le tre nuove falle a complessità d'attacco bassa, mentre l'evasione dalla sandbox di luglio aveva ricevuto 9,5 con tutte le metriche identiche tranne la complessità, fissata ad alta. È esattamente quel parametro a separare un 9,5 da un 10,0 — e, nella pratica, a separare uno sfruttamento che richiede condizioni favorevoli da uno che non ne richiede.

Cosa significa per le aziende italiane

In Italia ServiceNow non è un prodotto di nicchia: è la piattaforma ITSM di riferimento in gran parte dei grandi gruppi bancari, assicurativi, delle telco, delle utility e dei principali gruppi industriali, e ha una presenza crescente nella pubblica amministrazione centrale attraverso i grandi contratti di system integration.

Il punto è che cosa contiene un'istanza ServiceNow, ed è qui che il rating massimo trova la sua giustificazione concreta:

  • la CMDB, cioè la mappa aggiornata di server, applicazioni, dipendenze e proprietari dell'infrastruttura: per un attaccante è documentazione di ricognizione già pronta e già validata;
  • le credenziali di integrazione verso i sistemi collegati (discovery, orchestration, connettori verso Active Directory, cloud, monitoraggio), che spesso sono account di servizio con privilegi generosi;
  • i ticket, che nel mondo reale contengono dati personali di dipendenti e clienti, screenshot, allegati e, con imbarazzante frequenza, password scambiate in chiaro con l'help desk.

Chi ottiene esecuzione di codice non autenticata su quell'istanza non ha compromesso un'applicazione gestionale: ha ottenuto la piantina dell'edificio e un mazzo di chiavi. È esattamente ciò che il vettore CVSS descrive quando registra impatto elevato sui sistemi collegati.

C'è poi una questione organizzativa tipicamente italiana. In molte grandi realtà l'istanza ServiceNow è gestita da un system integrator esterno, che decide finestre di manutenzione e calendario delle patch. Il cliente non applica l'aggiornamento: lo chiede. E la differenza fra chiedere e verificare, su una falla da 10.0, si misura in settimane.

Contesto normativo

Per gli enti finanziari vale il regolamento DORA, applicabile dal 17 gennaio 2025, che impone un processo strutturato di gestione delle vulnerabilità e, soprattutto, la gestione del rischio derivante da fornitori terzi di servizi ICT. Una piattaforma come ServiceNow rientra tipicamente fra i fornitori censiti nel registro delle informazioni: l'aggiornamento non è solo un'attività tecnica, è un'evidenza da produrre.

Per i soggetti in perimetro NIS2 (d.lgs. 138/2024) l'obbligo si colloca sulla gestione delle vulnerabilità e sulla sicurezza della catena di fornitura, con l'onere di dimostrare tempi di reazione documentati sulle vulnerabilità critiche.

In entrambi i casi, se l'istanza contiene dati personali — e ne contiene sempre — un'eventuale compromissione fa scattare la valutazione ai sensi degli artt. 33 e 34 GDPR, con le consuete 72 ore verso il Garante.

Cosa fare subito

  • Identificare release family e patch level dell'istanza (Xanadu, Yokohama, Zurich o Australia) e confrontarli con l'elenco dell'articolo KB3152242.
  • Se l'istanza è self-hosted, applicare la correzione fuori dal ciclo ordinario. Attendere la finestra di manutenzione trimestrale su tre falle non autenticate da 10.0 non è una scelta difendibile a posteriori.
  • Se l'istanza è ospitata da ServiceNow, chiedere conferma scritta dell'avvenuto aggiornamento con data e patch level. Serve anche come evidenza per DORA e NIS2.
  • Verificare l'esposizione dell'istanza su Internet e, dove l'architettura lo consente, limitare l'accesso per intervalli di indirizzi IP o attraverso il VPN aziendale.
  • Rivedere i log dell'endpoint GraphQL e del processore di upload delle immagini di configurazione per il periodo precedente all'aggiornamento.
  • Censire e, in caso di dubbio, ruotare le credenziali di integrazione memorizzate nell'istanza: sono il vero bersaglio a valle.
  • Mappare quali dati personali risiedono nella piattaforma, prima di doverlo fare sotto pressione durante la valutazione di una notifica di violazione.
  • Inserire ServiceNow fra i sistemi a monitoraggio prioritario per la comparsa di un PoC pubblico: come mostra il precedente di luglio, è quello il momento in cui il rischio cambia scala.