ServiceNow, una delle piattaforme cloud più diffuse al mondo per la gestione dei servizi IT aziendali, ha confermato un incidente di sicurezza che ha esposto dati contenuti nelle istanze dei clienti. Gli attaccanti hanno sfruttato un endpoint API raggiungibile senza alcuna autenticazione, riuscendo a interrogare direttamente le tabelle delle istanze compromesse.
Cosa è successo
Il punto debole era l'endpoint /api/now/related_list_edit/create, che in determinate configurazioni risultava impostato con il parametro requires_authentication=false. In pratica, chiunque conoscesse l'indirizzo dell'istanza poteva inviare richieste HTTP e ottenere risposte con dati interni, senza credenziali né sessione attiva.
La cronologia rende il caso ancora più delicato: la vulnerabilità era stata segnalata a ServiceNow tramite il programma di bug bounty già il 22 aprile 2026, ma lo sfruttamento attivo è avvenuto tra il 2 e il 3 giugno, prima che l'azienda completasse il rilascio della correzione, distribuita poi alle istanze ospitate il 5 giugno. Le più colpite risultano le istanze sulla release "Australia" della piattaforma o quelle con specifiche modifiche di configurazione su versioni più datate.
Perché l'impatto può essere rilevante
ServiceNow non ha precisato quali dati siano stati effettivamente consultati, ma le istanze della piattaforma ospitano tipicamente informazioni aziendali sensibili: ticket di assistenza IT, anagrafiche dei dipendenti, documentazione interna, inventari degli asset e perfino report sugli incidenti di sicurezza. Per un attaccante, questo tipo di dati è oro: consente di mappare l'infrastruttura di un'organizzazione e preparare attacchi mirati molto più credibili.
Cosa fare
Le organizzazioni che usano ServiceNow dovrebbero verificare con il fornitore se la propria istanza rientra tra quelle interessate, esaminare i log delle richieste API tra fine maggio e inizio giugno alla ricerca di chiamate anomale verso l'endpoint coinvolto e rivedere le configurazioni di autenticazione di tutti gli endpoint esposti. Il caso conferma una lezione ormai ricorrente: nelle piattaforme SaaS le API "dimenticate" o configurate male sono una delle superfici d'attacco più sfruttate, e la sicurezza dell'istanza non può essere delegata interamente al fornitore.
