Un avviso recente con un elenco preciso di versioni

Il 25 settembre 2026 il Centro canadese per la sicurezza informatica ha pubblicato l’avviso AV26-963 sulle vulnerabilità di ServiceNow AI Platform. Il suo ambito operativo è chiaro: amministratori e team di sicurezza devono individuare la versione della propria istanza e confrontarla con i livelli corretti indicati dal fornitore. L’avviso dell’ente canadese si riferisce alle informazioni aggiornate al 24 settembre. Da solo, non conferma che una specifica istanza sia esposta o sia stata compromessa.

L’allerta è utile proprio perché distingue il nome commerciale della piattaforma dai rami di versione interessati. Non basta sapere che un’organizzazione utilizza ServiceNow, né che il suo ambiente appartiene a una famiglia recente: è necessario verificare il ramo e la patch applicata. La decisione operativa dipende da questo confronto; le organizzazioni con ambienti ospitati, autogestiti o amministrati da terzi dovrebbero confermare chi applica l’aggiornamento e come ne viene attestata l’installazione. Etichette di versione simili possono corrispondere a percorsi di manutenzione diversi, quindi il confronto deve basarsi sul ramo e sull’hot fix esatti dell’istanza. Occorre inoltre considerare la data dell’avviso: descrive quanto era noto allora, non ogni eventuale sviluppo successivo.

Quali rami confrontare con le patch

L’avviso elenca le versioni precedenti a tre livelli Australia: Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3 e Patch 5. Per Yokohama indica come soglia Yokohama Patch 13 Hot Fix 5a. Per Zurich riporta tre riferimenti distinti: Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32 e Patch 11 Hot Fix 3. La formulazione «precedenti a» significa che gli amministratori devono confrontare la versione esatta con la soglia pertinente, senza presumere che ogni installazione della stessa famiglia sia corretta.

È importante una precisazione: l’avviso non propone un unico numero di patch valido per tutti i rami. Inoltre, Zurich include diversi percorsi di aggiornamento, perciò è meglio non trasformare l’elenco in una regola semplificata come «installare la patch più alta». La versione di partenza, il calendario di manutenzione e il modello di servizio possono incidere sul percorso appropriato. Se l’inventario interno non permette di stabilire con certezza ramo e hot fix, chiedete conferma all’amministratore responsabile o al supporto del fornitore. Annotate quale soglia si applica a ciascun ambiente e su quali elementi si basa la decisione: la generica famiglia del prodotto non sostituisce questa verifica.

Cinque identificativi CVE, ma non cinque descrizioni tecniche complete

L’allerta del CSIRT italiano della Toscana, che rimanda al bollettino ServiceNow, elenca cinque identificativi: CVE-2026-86857, CVE-2026-86858, CVE-2026-86859, CVE-2026-86860 e CVE-2026-13016. Caratterizza inoltre il gruppo come composto da due falle critiche e tre di gravità alta. Questa indicazione aiuta a capire che l’elenco delle versioni riguarda più vulnerabilità, ma non sostituisce la lettura dell’avviso tecnico relativo a ciascuna CVE e non determina da sola l’esposizione di una configurazione specifica.

Tra i record accessibili durante questa verifica, CVE-2026-86857 è descritta come un problema di autorizzazione che potrebbe consentire a una persona autenticata di accedere a dati di AI Platform per i quali non dispone dell’autorizzazione. CVE-2026-86859 è descritta come un problema di autorizzazione che potrebbe permettere l’accesso non autenticato ai dati. Questi casi mostrano perché controllo degli accessi ed esposizione delle informazioni siano aspetti rilevanti; non giustificano però l’attribuzione degli stessi dettagli agli altri tre identificativi. Non deducete tecniche, condizioni o conseguenze specifiche per ogni CVE dal solo elenco aggregato dell’avviso. Il riepilogo delle gravità e gli identificativi offrono un orientamento, ma non sostituiscono descrizioni tecniche e criteri di applicabilità per ciascun problema.

Cosa si sa dello sfruttamento e della portata

Nella descrizione del record CVE-2026-86857, ServiceNow afferma di aver distribuito un aggiornamento alle istanze ospitate e di averlo fornito a partner e clienti autogestiti. Lo stesso testo dichiara che, al momento della pubblicazione del record, l’azienda non era a conoscenza di sfruttamento malevolo contro istanze ServiceNow. La frase va mantenuta entro il suo limite temporale: descrive ciò che il fornitore sapeva allora, non dimostra che non vi sia mai stato sfruttamento e non garantisce che non emergano informazioni successive.

L’avviso canadese elenca prodotto e versioni, ma non segnala incidenti specifici presso organizzazioni utenti e non consente di stimare quante istanze potrebbero essere interessate. «Vulnerabilità pubblicata» non va confuso con «intrusione confermata». Per valutare un caso specifico servono informazioni dell’istanza stessa, registri e conferma del fornitore; le fonti esaminate non consentono di affermare che queste falle siano attivamente sfruttate. Le organizzazioni non dovrebbero quindi considerare né l’assenza di incidenti segnalati né un avviso generale sul prodotto come una valutazione conclusiva del proprio ambiente.

Lista di controllo per i team operativi e di sicurezza

Per prima cosa, individuate il modello di servizio e chi è responsabile della manutenzione. Se l’istanza è ospitata da ServiceNow, chiedete conferma che l’aggiornamento pertinente sia stato applicato a quell’ambiente e registrate la risposta e la data. Se l’installazione è autogestita o mantenuta da un partner, confrontate ramo e livello di patch esatti con l’elenco dell’avviso e concordate l’aggiornamento secondo le istruzioni di ServiceNow. L’avviso pubblico raccomanda di consultare i collegamenti indicati e applicare gli aggiornamenti necessari; non fornisce una procedura universale nella console valida per ogni distribuzione.

Poi documentate le prove di chiusura: ramo, patch o hot fix, data di applicazione e responsabile della convalida. Se l’organizzazione gestisce più ambienti — produzione, test o istanze distinte per unità aziendale, per esempio — controllateli tutti, senza estendere automaticamente lo stato di un’installazione alle altre. Considerate ancora aperta qualsiasi versione che sembri precedente alle soglie pertinenti, finché il supporto non conferma il percorso di mitigazione. Se la versione raggiunge già il livello indicato, conservate la prova del confronto; non interpretatela automaticamente come una valutazione completa di altri rischi o configurazioni. Una registrazione datata agevola anche le verifiche successive, qualora cambino le responsabilità di manutenzione o il modello di hosting.

Il dato fondamentale è la versione esatta, non un’ipotesi

La conclusione verificabile al 26 settembre 2026 è circoscritta: il Centro canadese per la sicurezza informatica ha pubblicato un’allerta su ServiceNow AI Platform con rami e livelli di patch specifici; un riepilogo CSIRT elenca cinque CVE; i record consultati ne descrivono due come problemi di autorizzazione e accesso ai dati. Per gli amministratori, la condotta ragionevole è confrontare il livello esatto di ogni istanza con l’elenco, confermare la copertura con ServiceNow quando opportuno e applicare gli aggiornamenti pertinenti secondo il bollettino del fornitore.

Restano limiti informativi. L’avviso, da solo, non dettaglia i componenti tecnici di tutte e cinque le CVE, l’effetto di ciascuna singolarmente o lo stato dello sfruttamento osservato in tutte le istanze. L’assenza di questi dettagli nell’avviso pubblico non prova che non esistano; significa semplicemente che non è possibile affermarli qui. Finché il fornitore o i record tecnici non forniranno ulteriori informazioni, la priorità non è fare ipotesi sugli incidenti, ma verificare lo stato delle patch di ogni distribuzione e registrare la conferma. Tenete separate eventuali chiarimenti successivi dai fatti accertati in questo avviso e rivalutate gli ambienti interessati se cambiano soglie o indicazioni di manutenzione.