CISA ha inserito il 5 agosto 2026 tre nuove vulnerabilità nel catalogo KEV, l’elenco delle falle per cui esistono prove di sfruttamento reale da parte degli attaccanti. Per un’azienda questo significa una cosa molto concreta: se usi Langflow, Apache Tomcat o N-able N-central e non hai già applicato le correzioni, il rischio non è teorico ma attuale.
La notizia riguarda anche chi non riconosce subito questi nomi. Molte PMI utilizzano software esposti su Internet, strumenti di gestione remota o componenti applicativi integrati da fornitori esterni: sapere che una falla è finita nel KEV vuol dire dare priorità immediata alla verifica, alle patch e ai controlli di esposizione.
Cosa è successo
Il 5 agosto 2026 la Cybersecurity and Infrastructure Security Agency statunitense, nota come CISA, ha aggiunto tre vulnerabilità al suo catalogo Known Exploited Vulnerabilities. L’inserimento nel KEV non è un semplice avviso: indica che ci sono evidenze di sfruttamento attivo “in the wild”, cioè in attacchi reali.
Le tre vulnerabilità segnalate sono:
- CVE-2026-9198 in Langflow, con punteggio CVSS 9.8
- CVE-2026-34486 in Apache Tomcat, con punteggio CVSS 7.5
- CVE-2026-18556 in N-able N-central, con punteggio CVSS 8.2
Per le agenzie federali civili statunitensi il termine fissato da CISA per intervenire è molto ravvicinato: 7 agosto 2026. Anche se questo obbligo riguarda il settore pubblico USA, il messaggio per le imprese private è chiaro: non si tratta di vulnerabilità da mettere in coda, ma di urgenze operative.
Perché queste vulnerabilità sono diverse dalle altre
Ogni settimana emergono nuove CVE, ma solo una parte arriva nel catalogo KEV. La differenza è importante per chi deve decidere le priorità IT con tempo e risorse limitate.
Una vulnerabilità nel KEV ha tre caratteristiche che la rendono particolarmente rilevante:
- esiste una falla tecnica confermata;
- sono disponibili indizi o prove di utilizzo da parte di attori malevoli;
- il rischio operativo è immediato, soprattutto se il sistema è esposto su Internet.
Per una PMI, questo cambia l’ordine delle attività. Se un server vulnerabile è accessibile dall’esterno, oppure se il software è usato per amministrare infrastrutture o automatizzare processi, una correzione ritardata può trasformarsi rapidamente in blocco operativo, furto di dati o compromissione della rete.
I tre prodotti coinvolti e il rischio pratico
Langflow: esecuzione di codice da remoto senza autenticazione
La vulnerabilità CVE-2026-9198 interessa Langflow, piattaforma open source per lo sviluppo di applicazioni basate su AI. Secondo la fonte, il difetto consente a un attaccante non autenticato di ottenere esecuzione di codice da remoto completa nelle installazioni predefinite.
Il dato più importante per chi lo utilizza è che la correzione è stata rilasciata a luglio 2026 con la versione 1.10.1. Se in azienda o presso un fornitore sono presenti ambienti Langflow esposti, il livello di criticità è molto alto.
Anche in assenza di dettagli pubblici completi sulle modalità di sfruttamento di questa specifica CVE, la fonte ricorda che difetti di sicurezza in Langflow sono stati già usati più volte negli ultimi mesi. In altre parole, chi attacca conosce bene questa superficie e la considera appetibile.
Apache Tomcat: problema di cifratura in ambienti cluster
La CVE-2026-34486 riguarda Apache Tomcat e ha a che fare con una mancata cifratura di dati sensibili che può consentire di aggirare EncryptInterceptor, componente usato nei cluster per proteggere con chiave precondivisa i messaggi tra nodi.
La falla è stata corretta ad aprile 2026 nelle versioni:
- 11.0.21
- 10.1.54
- 9.0.117
Qui il rischio è più sottile rispetto a un classico bug “RCE”, ma non per questo secondario. Tomcat è presente in molte applicazioni aziendali, anche come componente invisibile all’utente finale. Se un’applicazione interna o pubblica usa cluster Tomcat, soprattutto in ambienti esposti, la verifica va fatta subito.
La fonte collega inoltre lo sfruttamento di questa CVE a campagne offensive attribuite a attori di lingua cinese. Palo Alto Networks Unit 42 ha descritto un’operazione in cui un attore identificato con gli alias knaithe e KnYuan, ritenuto basato a Zhuhai, in Cina, avrebbe usato DeepSeek attraverso il framework Hermes Agent per colpire dispositivi esposti su Internet.
Secondo Unit 42, l’attore avrebbe tentato di colpire oltre 460 target, combinando tecniche autonome e manuali. Il punto da notare non è solo geopolitico: è operativo. Gli attaccanti stanno già usando strumenti AI per accelerare la ricerca dei bersagli, testare più falle e cambiare tattica in pochi minuti.
N-able N-central: bypass dell’autenticazione
La terza vulnerabilità, CVE-2026-18556, colpisce N-able N-central, piattaforma usata per monitoraggio e gestione IT. Il problema è un bypass dell’autenticazione, quindi un difetto che può aprire la porta a operazioni non autorizzate su uno strumento particolarmente sensibile.
La fonte evidenzia un dettaglio importante: una prima correzione è risultata incompleta, tanto che N-able ha dovuto pubblicare una nuova patch tracciata come CVE-2026-18577, anch’essa con CVSS 8.2. Quest’ultima era già stata inserita nel KEV il lunedì precedente; ora l’aggiornamento di CISA segnala che entrambe le vulnerabilità risultano sfruttate.
Per chi usa strumenti RMM o di amministrazione centralizzata, questo è un campanello d’allarme forte. Un problema di autenticazione su una console di gestione può avere impatti molto più ampi del singolo server: può diventare un punto di accesso all’intera infrastruttura.
Il contesto: attacchi più automatizzati e più opportunistici
Le informazioni riportate dalle società di sicurezza citate nella fonte mostrano una tendenza ormai chiara. Gli attori malevoli non cercano più solo il bersaglio “perfetto”: eseguono campagne vaste, rapide e automatizzate, provando una sequenza di vulnerabilità note su molti sistemi esposti.
SOCRadar, analizzando un server di staging esposto controllato dagli avversari, ha osservato una campagna contro infrastrutture governative e commerciali in oltre 100 Paesi. Tra gli elementi individuati figurano liste di ricognizione, exploit per nove CVE, strumenti di tunneling e payload come SNOWLIGHT, descritto come un loader leggero per Linux scritto in C.
Secondo la stessa analisi, gli attori hanno sfruttato nove vulnerabilità distinte per compromettere 107 endpoint, inclusi 16 takeover root-level di cPanel/WHM tramite CVE-2026-41940 e un compromesso a livello Domain Admin via ProxyShell.
Per un manager non tecnico la sintesi è semplice: oggi un sistema vulnerabile e visibile su Internet può finire in una scansione massiva globale anche se la tua azienda non è un obiettivo “prestigioso”. Si viene colpiti perché si è esposti e aggiornati in ritardo, non necessariamente perché si è famosi.
Cosa significa per la tua azienda
La priorità non è inseguire ogni notizia di sicurezza, ma trasformare questi avvisi in azioni ordinate e verificabili.
Ecco i passi pratici consigliati per una PMI italiana:
-
Fai un censimento rapido dei sistemi coinvolti
Verifica subito se in azienda, presso il tuo consulente o in cloud sono presenti Langflow, Apache Tomcat o N-central. Tomcat in particolare può essere incorporato dentro applicazioni gestionali o portali sviluppati da terzi. -
Controlla versioni ed esposizione Internet
Un server vulnerabile ma non esposto richiede comunque intervento, ma un sistema accessibile dall’esterno ha priorità assoluta. Per Langflow e N-central questo punto è decisivo. -
Applica le patch corrette, non solo quelle “iniziali”
Nel caso di N-central, la fonte segnala esplicitamente che una prima correzione era incompleta. Occorre quindi verificare di avere installato la patch definitiva e non una mitigazione superata. -
Verifica log e accessi anomali
Se il sistema è rimasto esposto dopo il rilascio delle patch, non basta aggiornarlo: conviene controllare gli accessi, le modifiche di configurazione, gli account creati di recente e le connessioni amministrative insolite. -
Riduci la superficie esposta
Dove possibile, limita l’accesso a console e pannelli amministrativi tramite VPN, segmentazione di rete, allowlist IP o autenticazione forte. Meno servizi pubblici esponi, meno occasioni dai a campagne automatiche di scansione. -
Formalizza un processo di patch management
Il problema non è solo questa tripla segnalazione. È la capacità dell’azienda di sapere rapidamente cosa usa, chi lo gestisce e in quanto tempo può aggiornarlo. Se manca questo processo, ogni nuova CVE critica diventa un’emergenza. -
Assicurati di avere copie di sicurezza affidabili
Se un attacco dovesse trasformarsi in compromissione o blocco operativo, la differenza la fanno backup testati e procedure di ripristino chiare. Su questo tema può essere utile rivedere la strategia di remote backup.
Per molte PMI il nodo vero è organizzativo: sapere chi controlla i sistemi, chi autorizza gli aggiornamenti e chi verifica che siano andati a buon fine. Se questa governance manca, anche un semplice avviso KEV può diventare una falla aperta per settimane. In questi casi ha senso rafforzare il presidio con servizi di sicurezza informatica e con una gestione strutturata delle postazioni e dei sistemi tramite desktop IT management.
Come distinguere l’urgenza reale dal rumore
Non tutte le vulnerabilità richiedono lo stesso sforzo. Ma quando ricorrono insieme questi fattori, l’intervento deve salire in cima alla lista:
- presenza nel catalogo KEV;
- sfruttamento attivo confermato;
- possibilità di accesso senza autenticazione o di bypass dei controlli;
- sistema esposto su Internet;
- ruolo centrale del prodotto nell’infrastruttura aziendale.
Nella notizia del 5 agosto 2026 questi elementi compaiono in modo molto netto, soprattutto per Langflow e N-central. Tomcat richiede una lettura più attenta del contesto architetturale, ma proprio per questo non va sottovalutato: spesso i componenti middleware restano vulnerabili più a lungo perché nessuno li considera “proprietà” di un team preciso.
Domande frequenti
Se non uso direttamente questi software, posso ignorare la notizia?
No. Apache Tomcat può essere presente dentro applicazioni realizzate da terzi, mentre N-central può essere usato dal fornitore IT. Conviene chiedere una verifica esplicita.
Aggiornare basta a mettermi al sicuro?
Non sempre. Se il sistema è stato esposto mentre la falla era già sfruttata, oltre alla patch serve controllare log, account, configurazioni e possibili segni di compromissione.
Per una PMI qual è la priorità assoluta oggi?
Sapere rapidamente se i sistemi coinvolti esistono nella tua infrastruttura, capire se sono esposti su Internet e applicare subito le versioni corrette indicate dai fornitori.