Due vulnerabilità critiche in WSO2 e Adobe Commerce/Magento sono state inserite il 25 settembre 2026 nel catalogo KEV di CISA, cioè l’elenco delle falle già sfruttate in attacchi reali. Per un’azienda questo significa una cosa molto semplice: se usa queste piattaforme, non è più un rischio teorico da pianificare “quando c’è tempo”, ma una priorità operativa immediata.
Cosa è successo
La CISA, l’agenzia statunitense per la cybersicurezza, ha aggiunto al proprio catalogo Known Exploited Vulnerabilities due falle critiche per cui esistono evidenze di sfruttamento attivo:
- CVE-2026-5430 in WSO2, con punteggio CVSS 9.8
- CVE-2026-71362 in Adobe Commerce e Magento, con punteggio CVSS 9.1
L’inserimento nel KEV è un segnale importante perché non riguarda vulnerabilità solo “gravi sulla carta”. Indica che esistono già tentativi o campagne reali che cercano di sfruttarle contro sistemi esposti.
Per le agenzie federali civili statunitensi, CISA ha fissato al 27 settembre 2026 la scadenza per applicare le correzioni. Anche se l’obbligo riguarda il settore pubblico USA, il messaggio per le imprese private è chiaro: la finestra utile per intervenire si sta chiudendo rapidamente.
La falla WSO2: perché è particolarmente delicata
La vulnerabilità CVE-2026-5430 colpisce diversi componenti dell’ecosistema WSO2: API Control Plane, API Manager, Traffic Manager e Universal Gateway. Secondo le informazioni disponibili, si tratta di una vulnerabilità di path traversal che può consentire il caricamento illimitato di file e arrivare fino alla remote code execution, cioè all’esecuzione di codice sul sistema bersaglio.
In termini pratici, è il tipo di difetto che può trasformarsi da semplice esposizione tecnica a compromissione completa del server o del servizio, soprattutto se il sistema è raggiungibile dall’esterno e non adeguatamente segmentato.
Un elemento da non sottovalutare è la tempistica. Secondo watchTowr, erano già visibili tentativi di sfruttamento nei propri honeypot almeno dal 13 settembre 2026. Il gruppo ha dichiarato di aver intercettato token JWT contraffatti usati per prendere di mira la falla e di essere riuscito a riprodurre il problema anche in assenza di dettagli tecnici pubblici completi.
Questo aspetto conta molto per le aziende: significa che gli attaccanti non aspettano necessariamente la pubblicazione di guide dettagliate o exploit “facili da usare”. Se una vulnerabilità è interessante e il prodotto è diffuso, i primi attacchi possono partire quasi subito.
WSO2, inoltre, non è una tecnologia di nicchia. Secondo quanto riportato nella fonte, è utilizzata da quasi 1.000 clienti in settori come banche, pubblica amministrazione, telecomunicazioni e logistica. In ambienti di questo tipo, un compromesso sull’infrastruttura API può avere effetti a catena su integrazioni, autenticazione, scambio dati e continuità operativa.
La falla Adobe Commerce e Magento: il rischio per chi vende online
La seconda vulnerabilità, CVE-2026-71362, riguarda Adobe Commerce e Magento ed è classificata come un problema di autorizzazione non corretta. In sostanza, un attaccante potrebbe ottenere accesso elevato a risorse sensibili senza interazione dell’utente.
Per chi gestisce un e-commerce, il punto più concreto è emerso dalle osservazioni di Sansec nell’agosto 2026: la falla permetterebbe di spostare una sessione cliente verso l’account di un altro cliente. Tradotto in linguaggio aziendale: un aggressore potrebbe accedere all’account della vittima e ai relativi dati privati.
Non si tratta quindi solo di un problema “tecnico del sito”, ma di un rischio diretto per:
- dati personali dei clienti
- cronologia ordini
- indirizzi e informazioni di contatto
- fiducia nel marchio
- conformità privacy
Ulteriori segnali di sfruttamento arrivano dalla telemetria di Previdian, che ha rilevato il 10 settembre 2026 un tentativo proveniente da un singolo indirizzo IP australiano contro i propri sensori honeypot.
Un dettaglio interessante è che, al momento citato dalla fonte, Adobe non aveva ancora aggiornato il proprio advisory per confermare formalmente lo stato di sfruttamento attivo. Anche questo è un promemoria utile: le aziende non dovrebbero aspettare sempre la conferma finale del vendor quando esistono già riscontri credibili da fonti indipendenti e l’inclusione nel KEV.
Perché il catalogo KEV è importante anche per le PMI italiane
Molte piccole e medie imprese vedono notizie come questa e pensano che riguardino soprattutto governi, grandi gruppi o bersagli internazionali. In realtà il catalogo KEV è utile proprio perché aiuta a distinguere tra migliaia di vulnerabilità teoriche e quelle che meritano attenzione immediata.
Quando una falla entra nel KEV, di solito siamo già oltre la fase dell’allerta preventiva. Gli attaccanti hanno avuto tempo per testare, automatizzare o integrare lo sfruttamento nelle loro campagne. Questo abbassa la soglia d’ingresso: non serve più necessariamente un attore molto sofisticato per tentare un attacco.
Per una PMI italiana il rischio è ancora più concreto in tre casi:
- piattaforme non aggiornate per mancanza di presidio interno
- sistemi esposti su internet gestiti da fornitori diversi senza una regia unica
- e-commerce o API considerate “funzionanti” e quindi lasciate in secondo piano fino al problema successivo
Il vero nodo non è solo avere il software vulnerabile, ma non sapere con precisione dove si trova, chi lo aggiorna e quanto tempo serve per mettere in sicurezza l’ambiente.
Cosa significa per la tua azienda
Se usi WSO2, Adobe Commerce o Magento, questo è il momento di fare verifiche immediate. Le priorità pratiche sono queste.
1. Verifica subito se sei esposto
Fai un censimento dei sistemi pubblicati online e degli ambienti interni che usano questi prodotti. Non limitarti al server principale: controlla anche ambienti di test, staging, nodi secondari e istanze dimenticate ma ancora raggiungibili.
2. Applica le correzioni disponibili con urgenza
Se il produttore ha già rilasciato patch o istruzioni di mitigazione, vanno pianificate come attività prioritaria. In casi come questi, rinviare di qualche giorno può fare la differenza tra prevenzione e incidente.
3. Controlla i log e i segnali anomali
Per WSO2, presta attenzione a upload sospetti, richieste anomale verso percorsi sensibili e utilizzo irregolare di token JWT. Per Magento o Adobe Commerce, verifica accessi inusuali agli account cliente, cambi di sessione inattesi e attività anomale nell’area utenti.
4. Riduci l’esposizione dei servizi critici
Se una console, un pannello o un endpoint non devono essere esposti direttamente su internet, conviene limitarne l’accesso. Segmentazione di rete, restrizioni IP e controllo degli accessi possono ridurre molto il rischio mentre si completano gli aggiornamenti.
5. Prepara un piano di risposta, non solo di patching
Se sospetti che un sistema sia già stato toccato, aggiornare non basta. Serve capire se ci sono stati accessi impropri, esfiltrazione di dati o persistenza dell’attaccante. In particolare per un e-commerce, la valutazione deve includere anche il profilo privacy e gli eventuali obblighi documentali.
In questo tipo di scenario può essere utile affiancare alle attività di patching un servizio continuativo di sicurezza informatica e una gestione più strutturata dei sistemi con desktop e IT management. Se il timore è la perdita di dati o la necessità di ripristino rapido dopo un incidente, anche un remote backup ben progettato fa parte delle contromisure essenziali.
L’errore più comune: aspettare conferme “definitive”
In molte aziende gli aggiornamenti urgenti si bloccano per un motivo comprensibile: si aspetta la validazione completa del fornitore, la finestra di manutenzione perfetta o una conferma interna che il rischio sia davvero alto.
Il problema è che le vulnerabilità già sfruttate seguono una logica diversa. Quando l’evidenza di attacco c’è già, il tempo perso in attesa diventa parte del rischio. Non significa aggiornare in modo caotico, ma avere una procedura chiara per i casi prioritari: verifica impatto, approvazione rapida, test essenziali, applicazione della correzione, controllo post-intervento.
Le aziende più esposte non sono sempre quelle con infrastrutture più grandi, ma quelle con processi più lenti o frammentati.
Una lezione più ampia: API ed e-commerce restano bersagli ad alto valore
Le due vulnerabilità di oggi colpiscono ambiti diversi ma molto strategici: gestione delle API e piattaforme e-commerce. È una combinazione che racconta bene dove si concentra l’interesse degli attaccanti.
Le API sono il tessuto connettivo di applicazioni, integrazioni e automazioni aziendali. Un problema su questo fronte può aprire varchi trasversali a più servizi. L’e-commerce, invece, unisce disponibilità del servizio, dati personali e impatto diretto sul fatturato. Per questo una falla su queste piattaforme non va trattata come un normale aggiornamento applicativo.
La conclusione operativa è semplice: se la tua azienda dipende da portali clienti, integrazioni via API o vendita online, serve una disciplina costante su aggiornamenti, monitoraggio e responsabilità chiare tra IT interno e fornitori.
Domande frequenti
Se uso Magento devo fermare subito il sito?
Non necessariamente, ma devi verificare subito versione, patch disponibili e segnali di abuso. Se emergono indicatori di compromissione o non puoi mitigare rapidamente il rischio, possono servire misure temporanee più restrittive.
Il fatto che CISA sia americana riguarda anche un’azienda italiana?
Sì, perché il catalogo KEV è un riferimento pratico globale sulle vulnerabilità già sfruttate. Non crea obblighi per le PMI italiane, ma aiuta a capire quali falle hanno priorità reale.
Se aggiorno il software sono al sicuro?
L’aggiornamento è il primo passo, non l’unico. Va accompagnato da controlli sui log, verifica di eventuali accessi anomali e, se necessario, da un’analisi dell’impatto su dati e continuità operativa.