IBM ha pubblicato il 13 ottobre 2026 un bollettino di sicurezza che chiude 22 vulnerabilità in IBM Security Verify Access e IBM Verify Identity Access, le piattaforme di gestione delle identità e degli accessi usate da banche, pubbliche amministrazioni e grandi aziende in tutta Europa. Cinque di queste falle sono classificate come critiche, con due vulnerabilità che raggiungono un punteggio CVSS di 9,8 su 10. L’Agenzia per la Cybersicurezza Nazionale (ACN) ha segnalato l’aggiornamento nel suo bollettino settimanale dell’11 ottobre, inserendolo tra le patch da applicare con priorità nelle organizzazioni che usano i prodotti IBM per autenticare dipendenti e clienti.
La vicenda arriva in una settimana già pesante per la sicurezza perimetrale europea. Nello stesso periodo si sono sovrapposte le patch critiche di Citrix NetScaler, l’advisory su Cisco Secure Email Gateway e un rilascio di sicurezza di GitLab. Il caso IBM Verify Access, però, merita un’attenzione specifica perché riguarda non un firewall o un gateway di posta, ma lo strato che decide chi può entrare dove in migliaia di sistemi aziendali.
Cosa è successo: il bollettino IBM del 13 ottobre 2026
Il bollettino ufficiale pubblicato da IBM descrive 22 vulnerabilità distinte in IBM Security Verify Access e nella sua evoluzione IBM Verify Identity Access, comprese le relative edizioni containerizzate. Secondo la ripartizione per gravità, cinque falle sono critiche, cinque sono alte, dieci sono di livello medio e due sono basse. Nessuna delle 22 CVE risulta al momento inserita nel catalogo Known Exploited Vulnerabilities di CISA, e non ci sono segnalazioni pubbliche di sfruttamento attivo in rete.
Questo è un dettaglio importante per chi deve dare priorità alle patch. Una vulnerabilità critica non ancora sfruttata concede qualche giorno di margine operativo, ma la storia recente di NetScaler insegna che quel margine si chiude in fretta: Citrix ha confermato lo sfruttamento attivo delle sue falle critiche appena pochi giorni dopo la divulgazione. Per questo diversi analisti consigliano di trattare anche le CVE IBM non ancora exploitate come se lo sfruttamento fosse questione di settimane, non di mesi.
IBM Security Verify Access e Verify Identity Access: a cosa servono
IBM Security Verify Access è una piattaforma di Identity and Access Management (IAM) nata per gestire autenticazione, autorizzazione e single sign-on in ambienti enterprise. Nel 2026 IBM ha rinominato la linea di prodotto in Verify Identity Access, mantenendo in parallelo la vecchia denominazione Security Verify Access per le versioni 10.x ancora supportate. Le aziende la usano come punto centrale per decidere chi accede a portali interni, applicazioni web e servizi esposti a clienti e partner.
Proprio perché si tratta di un sistema di accesso centralizzato, una falla grave in questo tipo di software ha un raggio d’azione più ampio di un bug in una singola applicazione. Se un attaccante riesce a bypassare l’autenticazione o a eseguire codice da remoto sul server che gestisce gli accessi, in teoria ottiene le chiavi di tutto quello che quel server protegge. È la stessa logica per cui le falle in Okta, Microsoft Entra ID o CyberArk finiscono sempre ai primi posti delle liste di priorità dei team di sicurezza.
Le 22 vulnerabilità scoperte: la scomposizione per gravità
Il bollettino IBM non elenca pubblicamente ogni singolo CVE con il relativo punteggio in un’unica tabella consultabile, ma una rielaborazione tecnica pubblicata da Spirity Enterprise per la settimana 41 del 2026 ricostruisce la distribuzione completa: 5 vulnerabilità critiche, 5 alte, 10 medie e 2 basse, per un totale di 22. Tra i problemi di gravità media figura anche una falla di SQL injection che permette a un attaccante già autenticato di modificare dati e causare un’interruzione di servizio, un dettaglio che il bollettino IBM descrive separatamente.
Le cinque vulnerabilità critiche sono quelle che impongono l’aggiornamento immediato. Due di esse toccano il punteggio massimo quasi assoluto di 9,8 su 10, un valore che nella scala CVSS indica un attacco eseguibile da remoto, senza privilegi e senza interazione dell’utente. Le altre tre critiche riguardano bypass di autenticazione ed esecuzione di codice in condizioni più limitate, ma restano comunque nella fascia di rischio più alta prevista dallo standard.
Le cinque falle critiche in dettaglio
Due CVE con CVSS 9,8: deserializzazione insicura e RCE non autenticata
Le vulnerabilità CVE-2026-78406 e CVE-2026-78401 condividono la stessa causa tecnica: una deserializzazione insicura dei dati in ingresso che un attaccante remoto può sfruttare per eseguire codice arbitrario senza bisogno di credenziali valide. È una classe di bug nota da anni nel mondo Java enterprise, la stessa famiglia di difetti che ha colpito Apache Struts, Jenkins e più volte anche prodotti WebSphere, su cui IBM Verify Access si appoggia storicamente. Un oggetto serializzato malevolo, inviato al componente giusto, costringe il server a istanziare codice che l’attaccante controlla.
Con un punteggio CVSS di 9,8, queste due CVE si collocano nella fascia più alta possibile per un attacco di rete senza autenticazione. In pratica, un server Verify Access esposto a internet e non aggiornato può essere compromesso integralmente da chiunque riesca a raggiungerlo in rete, senza dover prima rubare una password o un token di sessione.
Bypass di autenticazione e iniezione SQL: le altre tre critiche
Le vulnerabilità CVE-2026-19491 e CVE-2026-16823 riguardano invece bypass di autenticazione, bug che permettono di aggirare il controllo degli accessi senza possedere credenziali legittime. IBM non ha reso pubblico il punteggio CVSS esatto per queste due falle nei materiali consultabili, ma la loro classificazione come critiche segnala comunque un impatto severo sulla capacità del sistema di distinguere utenti autorizzati da intrusi.
La quinta CVE critica, CVE-2026-16916, consente l’esecuzione di codice in forma autenticata: un attaccante con un account valido, anche a basso privilegio, può sfruttarla per allargare il proprio controllo sul sistema. È uno scenario frequente nelle intrusioni reali, dove l’accesso iniziale arriva quasi sempre da una credenziale rubata altrove, per esempio tramite phishing, e la vulnerabilità critica serve poi a scalare i privilegi.
Versioni colpite e versioni corrette
Secondo il bollettino IBM, l’intervallo di versioni interessate copre IBM Security Verify Access dalla 10.0 alla 10.0.9.3 e IBM Verify Identity Access dalla 11.0 alla 11.0.3.1, comprese le rispettive edizioni container. Le versioni corrette sono Security Verify Access 10.0.9.4 e Verify Identity Access 11.0.3.2. Il bollettino contiene anche un dettaglio apparentemente incoerente, secondo cui la falla di SQL injection colpirebbe solo fino alla 10.0.9.2 e alla 11.0.3, un disallineamento che IBM attribuisce a revisioni successive del testo e che non cambia l’indicazione operativa: aggiornare comunque alle build più recenti.
Per i team che gestiscono grandi distribuzioni, il punto dolente non è tanto applicare la patch su un singolo server quanto farlo su decine o centinaia di istanze distribuite tra data center on-premise e ambienti cloud, spesso con finestre di manutenzione limitate perché il sistema di autenticazione non può restare offline a lungo senza bloccare l’accesso di dipendenti e clienti.
Tabella: le cinque vulnerabilità critiche CVE per CVE
| CVE | CVSS | Tipo di impatto | Autenticazione richiesta |
|---|---|---|---|
| CVE-2026-78406 | 9,8 | Esecuzione di codice da remoto (deserializzazione insicura) | No |
| CVE-2026-78401 | 9,8 | Esecuzione di codice da remoto (deserializzazione insicura) | No |
| CVE-2026-19491 | Critica, score non pubblicato | Bypass di autenticazione | No |
| CVE-2026-16823 | Critica, score non pubblicato | Bypass di autenticazione | No |
| CVE-2026-16916 | Critica, score non pubblicato | Esecuzione di codice con privilegi elevati | Sì, privilegi bassi |
La segnalazione dell’ACN e il contesto italiano
In Italia è stata l’Agenzia per la Cybersicurezza Nazionale a dare visibilità al caso, includendolo nel proprio bollettino dedicato alle vulnerabilità risolte nei prodotti IBM nella settimana dell’11 ottobre 2026. Nello stesso avviso l’agenzia ha segnalato anche un aggiornamento critico per HPE Intelligent Management Center, confermando come quella settimana di ottobre sia stata particolarmente densa di patch urgenti per software enterprise usati nella pubblica amministrazione e nel settore privato italiano.
Per le organizzazioni italiane soggette agli obblighi della direttiva NIS2, la segnalazione dell’ACN non è solo un’informazione tecnica. È anche un punto di riferimento documentale: dimostrare di aver recepito e applicato tempestivamente l’avviso fa parte della diligenza richiesta dalla normativa in materia di gestione del rischio informatico, soprattutto per i soggetti classificati come essenziali o importanti.
Perché IBM Verify Access non è una novità: la cronologia 2026
Il bollettino di ottobre non è il primo del 2026 per questa linea di prodotto. Nel corso dell’anno IBM ha pubblicato almeno altri quattro avvisi di sicurezza rilevanti per Security Verify Access e Verify Identity Access, segno di un prodotto sotto osservazione costante da parte di ricercatori e, probabilmente, anche di attaccanti che ne studiano il codice alla ricerca di nuove falle da rivendere o sfruttare.
| Data | Bollettino | Versioni coinvolte | Versione corretta |
|---|---|---|---|
| 17 gennaio 2026 | Richieste HTTP create ad hoc, esposizione di dati sensibili o DoS | Security Verify Access 10.0.0–10.0.7 | Build successiva indicata nel bollettino |
| 14 aprile 2026 | CVE-2026-5926, algoritmi crittografici deboli | Security Verify Access 10.0–10.0.9.1, Verify Identity Access 11.0–11.0.2 | Non specificata nei dettagli pubblici |
| 2 giugno 2026 | Bollettino di aggiornamento su versioni precedenti | Fino a 10.0.9.1, 11.0.2 | 10.0.9.1 IF1, 11.0.2 IF2 |
| 2 settembre 2026 | Bollettino su versioni intermedie | Security Verify Access 10.0.0–10.0.9.2 IF1, Verify Identity Access 11.0.0–11.0.3 IF1 | Non specificata nei dettagli pubblici |
| 13 ottobre 2026 | 22 vulnerabilità, 5 critiche | Security Verify Access 10.0–10.0.9.3, Verify Identity Access 11.0–11.0.3.1 | 10.0.9.4, 11.0.3.2 |
Guardando questa sequenza, emerge un prodotto che riceve patch di sicurezza quasi ogni due o tre mesi nel 2026. Non è di per sé un segnale negativo: un ritmo di disclosure regolare indica spesso che il fornitore investe in audit interni e collabora con ricercatori esterni. Il problema pratico per chi amministra questi sistemi è diverso: tenere il passo con aggiornamenti così ravvicinati richiede processi di patching collaudati, non interventi d’emergenza improvvisati ogni volta.
Il quadro europeo: Citrix, Cisco e GitLab nella stessa settimana
Il bollettino IBM si inserisce in un ottobre particolarmente intenso per la sicurezza del software enterprise in Europa. Pochi giorni prima, Citrix aveva confermato lo sfruttamento attivo di due vulnerabilità critiche in NetScaler ADC e Gateway, seguite l’8 ottobre da una nuova falla di memoria in ambito SAML con CVSS 9,5. Il 12 ottobre GitLab ha rilasciato le versioni 19.4.2, 19.3.4 e 19.2.8 per correggere 24 problemi di sicurezza, tra cui un’esecuzione di codice arbitrario non autenticata. Il 14 ottobre è toccato a Cisco Secure Email Gateway, con una falla che consente la scrittura di file arbitrari e l’esecuzione di comandi con privilegi di root.
| Prodotto | CVE o riferimento | Gravità | Impatto principale | Data |
|---|---|---|---|---|
| Citrix NetScaler ADC/Gateway | CVE-2026-107406 | CVSS 9,5 | RCE o DoS da overflow di memoria SAML | 8 ottobre 2026 |
| GitLab | Non specificato pubblicamente | Critica, score non pubblicato | Esecuzione di codice arbitrario non autenticata | 12 ottobre 2026 |
| Cisco Secure Email Gateway | Advisory AMP | Critica, score non pubblicato nella fonte | Scrittura file arbitrari, comandi come root | 14 ottobre 2026 |
| IBM Verify Access/Identity Access | CVE-2026-78406, CVE-2026-78401 | CVSS 9,8 | RCE non autenticata da deserializzazione insicura | 13 ottobre 2026 |
Messi in fila, questi quattro episodi raccontano una cosa semplice: nell’autunno 2026 i team di sicurezza europei non hanno avuto una sola emergenza da gestire, ma quattro, tutte in una finestra di una settimana, tutte su software che siede ai margini della rete o al centro del controllo accessi. Per chi gestisce ambienti ibridi con più fornitori, la somma di queste patch si traduce in un carico di lavoro concentrato che spesso supera la capacità dei team interni, da cui il ricorso crescente a fornitori di managed detection and response per assorbire i picchi.
Perché la gestione delle identità resta un bersaglio strategico
I sistemi IAM occupano una posizione particolare nell’architettura di sicurezza aziendale. Non proteggono un solo dato o una sola applicazione, ma decidono l’accesso a tutto il resto. Un attaccante che compromette un server Verify Access non deve più muoversi lateralmente da un’applicazione periferica verso i sistemi critici, perché parte già dal centro. È lo stesso motivo per cui le falle in Okta nel 2023 e in Microsoft Entra ID negli anni successivi hanno generato reazioni così rapide da parte dei fornitori e dei clienti.
C’è poi un fattore meno discusso ma concreto. I prodotti IAM enterprise tendono a restare in produzione per molti anni, spesso oltre il ciclo di vita ideale, perché sostituirli significa rifare l’integrazione con decine di applicazioni collegate. Questo crea un parco installato eterogeneo, con versioni vecchie che convivono a lungo con quelle nuove, e aumenta la probabilità che qualche istanza resti scoperta anche dopo che una patch è disponibile da settimane.
L’impatto sul mercato IAM e sulle aziende che usano Verify Access
Sul piano commerciale, episodi come questo alimentano una tendenza già in corso, la migrazione verso piattaforme IAM cloud-native, gestite direttamente dal fornitore, dove il carico di patching ricade sul provider e non sul cliente. Okta, Microsoft Entra ID e Ping Identity promuovono da anni questo modello come argomento di vendita contro i deployment on-premise come Verify Access, che restano sotto la responsabilità diretta dell’azienda che li gestisce.
Allo stesso tempo, molte organizzazioni regolate, in particolare banche e assicurazioni italiane ed europee, mantengono Verify Access proprio per il controllo diretto che offre sui dati di autenticazione, un requisito spesso imposto da normative settoriali o da policy interne di data residency. Per queste aziende il costo di una migrazione resta più alto del costo di gestire patch frequenti, almeno finché non si accumulano incidenti concreti legati a vulnerabilità sfruttate.
Cosa devono fare subito i team di sicurezza
La priorità operativa è semplice da enunciare e più complessa da eseguire su larga scala, aggiornare ogni istanza di Security Verify Access alla 10.0.9.4 e ogni istanza di Verify Identity Access alla 11.0.3.2, comprese le edizioni container, verificando prima in un ambiente di staging che le integrazioni esistenti con applicazioni e directory aziendali continuino a funzionare. In parallelo, è utile condurre una verifica dei log per individuare segnali di tentativi di deserializzazione anomala nelle settimane precedenti alla patch.
# Esempio di verifica dei log per pattern di deserializzazione sospetta
grep -E "ObjectInputStream|readObject|serialVersionUID" /var/log/verify-access/*.log
# Controllo rapido delle richieste con payload anomali verso endpoint SAML
grep -i "saml" /var/log/verify-access/access.log | grep -E "POST" | tail -n 200
# Verifica della versione installata prima e dopo l'aggiornamento
rpm -qa | grep -i verify
Oltre alla patch, vale la pena rivedere l’esposizione diretta a internet dei pannelli di amministrazione di Verify Access. Molte delle falle più gravi scoperte quest’anno nei prodotti perimetrali, da Citrix a Cisco, colpiscono interfacce che non avrebbero dovuto essere raggiungibili dall’esterno in primo luogo. Segmentare la rete e limitare l’accesso amministrativo a reti interne o VPN riduce drasticamente la finestra di rischio anche quando una patch arriva con qualche giorno di ritardo.
Le previsioni per i prossimi mesi
- È probabile che una o più delle cinque CVE critiche di IBM Verify Access entrino nel catalogo CISA KEV entro la fine del 2026, se emergeranno i primi tentativi di exploitation pubblica, replicando lo schema già visto con Citrix NetScaler.
- Altri fornitori IAM enterprise, da CyberArk a SailPoint, pubblicheranno con ogni probabilità advisory simili nei prossimi mesi, perché l’attenzione dei ricercatori si sta spostando sempre più verso questa categoria di software dopo una serie di casi ad alto profilo.
- Le aziende italiane soggette a NIS2 affronteranno controlli più serrati sui tempi di applicazione delle patch IAM, con l’ACN che probabilmente pubblicherà indicazioni operative più dettagliate su questa categoria di prodotti.
- Ci si aspetta un’accelerazione della migrazione verso modelli di autenticazione passwordless e resistenti al phishing, non tanto per sostituire Verify Access quanto per ridurre il valore di un eventuale accesso ottenuto sfruttando falle come queste.
- Il numero di bollettini di sicurezza pubblicati da IBM per questa linea di prodotto nel 2027 difficilmente scenderà sotto i quattro o cinque registrati nel 2026, vista la cadenza osservata negli ultimi dodici mesi.
Domande frequenti
Quante vulnerabilità ha corretto IBM a ottobre 2026?
Il bollettino del 13 ottobre 2026 copre 22 vulnerabilità distinte in IBM Security Verify Access e IBM Verify Identity Access, cinque critiche, cinque alte, dieci medie e due basse.
Qual è il punteggio CVSS più alto tra le falle corrette?
Due vulnerabilità, CVE-2026-78406 e CVE-2026-78401, raggiungono un CVSS di 9,8 su 10 e permettono l’esecuzione di codice da remoto senza autenticazione tramite deserializzazione insicura.
A quali versioni devo aggiornare?
Alle versioni IBM Security Verify Access 10.0.9.4 e IBM Verify Identity Access 11.0.3.2, comprese le relative edizioni container, secondo il bollettino ufficiale IBM.
Le vulnerabilità sono già sfruttate da attaccanti?
Al momento della pubblicazione, nessuna delle 22 CVE risulta nel catalogo Known Exploited Vulnerabilities di CISA né ha segnalazioni pubbliche di sfruttamento attivo.
Perché l’ACN italiana ha segnalato questo bollettino?
L’Agenzia per la Cybersicurezza Nazionale pubblica regolarmente avvisi sulle vulnerabilità più rilevanti per aziende e pubbliche amministrazioni italiane, e questo caso riguarda un prodotto IAM diffuso nel settore bancario e pubblico, rilevante anche ai fini degli obblighi previsti dalla direttiva NIS2.
Cosa rende critica una falla in un sistema di identity management?
Un sistema IAM centralizza le decisioni di accesso per molte applicazioni collegate. Una falla critica in questo strato può dare a un attaccante un punto di ingresso diretto verso tutto ciò che il sistema protegge, invece di limitarsi a una singola applicazione periferica.
Esistono precedenti di falle simili in IBM Verify Access?
Sì. Nel corso del 2026 IBM ha già pubblicato bollettini a gennaio, aprile, giugno e settembre per la stessa linea di prodotto, segno di un ritmo di disclosure regolare nel corso dell’anno.