CISA, l’agenzia federale statunitense per la cybersicurezza, ha segnalato il 25 settembre 2026 quattro vulnerabilità già sfruttate in attacchi reali che coinvolgono Microsoft SharePoint, WSO2, Adobe Commerce/Magento e Mikrotik RouterOS. Per un’azienda italiana questo conta subito: quando una falla entra nel catalogo delle vulnerabilità note come attivamente sfruttate, il rischio non è più teorico e il tempo per intervenire si misura in ore o pochi giorni, non in mesi.
Cosa è successo
Il 25 settembre 2026 CISA ha aggiornato il proprio catalogo KEV, cioè l’elenco delle vulnerabilità note come effettivamente sfruttate dagli attaccanti. L’aggiornamento riguarda quattro problemi di sicurezza in prodotti molto diffusi in ambito aziendale:
- WSO2: vulnerabilità critica CVE-2026-5430
- Adobe Commerce / Magento: vulnerabilità critica CVE-2026-71362
- Microsoft SharePoint: vulnerabilità ad alta gravità CVE-2026-65660
- Mikrotik RouterOS: vulnerabilità di media gravità CVE-2026-67279
Per le agenzie federali USA che usano i prodotti coinvolti, CISA ha fissato scadenze molto ravvicinate: 27 settembre per le due vulnerabilità critiche di WSO2 e Adobe Commerce, e 28 settembre per SharePoint e Mikrotik RouterOS. Anche se l’obbligo formale riguarda il settore pubblico statunitense, il messaggio per le imprese private è chiaro: queste falle vanno trattate come priorità immediata.
Le vulnerabilità da tenere d’occhio
WSO2: bypass dell’autenticazione con impatto potenzialmente totale
La vulnerabilità CVE-2026-5430 colpisce più prodotti WSO2, tra cui:
- API Manager versioni 4.1.0 fino a 4.6.0
- API Control Plane
- Traffic Manager
- Universal Gateway versioni 4.5.0 e 4.6.0
Secondo il produttore, che aveva pubblicato un advisory originario il 3 maggio, un attaccante può arrivare a compromettere account amministrativi e ottenere il pieno controllo dell’ambiente colpito. L’origine del problema è nella gestione dell’autenticazione JWT: il sistema accetterebbe token firmati con un algoritmo non supportato.
CISA non ha diffuso dettagli tecnici sugli attacchi in corso, ma la società di sicurezza watchTowr ha comunicato il 15 settembre di aver osservato tentativi di sfruttamento nei propri honeypot, con attività registrata il 13 settembre da un singolo indirizzo IP. I ricercatori hanno anche verificato in laboratorio che, sul prodotto corretto, un token contraffatto può esporre endpoint API e credenziali applicative.
Il punto importante per le aziende è questo: WSO2 non è una piattaforma “di nicchia” nel senso del rischio. Viene usata in contesti critici come banche, pubblica amministrazione, telecomunicazioni e logistica. Dove ci sono integrazioni, API e flussi applicativi centrali, una compromissione può avere effetti a catena.
Adobe Commerce e Magento: rischio serio per l’e-commerce
La seconda vulnerabilità critica inserita nel KEV è CVE-2026-71362, che interessa Adobe Commerce e Magento. È descritta come una falla di autorizzazione non corretta.
Secondo Sansec, società specializzata nella sicurezza e-commerce, la vulnerabilità è già sfruttata in rete e presenta un aspetto particolarmente preoccupante: per l’attacco non sarebbero necessari un account esistente, privilegi amministrativi o l’interazione di un utente.
Per chi vende online, questa è la tipica combinazione che impone massima prudenza. Quando una piattaforma e-commerce è esposta su Internet e gestisce catalogo, ordini, dati cliente e integrazioni con pagamenti o gestionali, anche una singola vulnerabilità sfruttata può trasformarsi rapidamente in interruzione del servizio, manipolazione del sito o compromissione dei dati.
SharePoint: falla ad alta gravità in un componente diffusissimo
CISA ha richiamato l’attenzione anche su CVE-2026-65660, descritta come una vulnerabilità di code injection ad alta gravità in Microsoft SharePoint.
SharePoint è spesso usato come piattaforma documentale, intranet aziendale o punto di accesso a processi interni. Proprio per questo una vulnerabilità in questo ambito non va letta come un problema “solo IT”: può impattare documenti riservati, procedure, permessi, workflow e collaborazione tra uffici.
Se SharePoint è esposto verso l’esterno oppure integrato con altri sistemi, l’urgenza cresce ulteriormente. In molti casi, questi ambienti diventano snodi centrali dell’organizzazione, e quindi obiettivi appetibili.
Mikrotik RouterOS: gravità media non significa trascurabile
L’ultima falla menzionata è CVE-2026-67279, una vulnerabilità pre-autenticazione nella macchina a stati o nel workflow SSH di Mikrotik RouterOS.
Il punteggio non è il più alto tra quelli segnalati, ma c’è un punto che spesso viene sottovalutato: se una vulnerabilità viene aggiunta al KEV, significa che qualcuno la sta già usando. In pratica, la gravità teorica non basta per decidere le priorità: conta anche il fatto che l’exploit sia reale e in circolazione.
Per router e apparati di rete, il rischio riguarda la porta d’ingresso dell’infrastruttura. Un dispositivo compromesso può diventare un punto di osservazione, di transito o di attacco verso altri sistemi interni.
Perché questa notizia riguarda anche le PMI italiane
Molte piccole e medie imprese pensano di essere troppo piccole per finire nel mirino. In realtà, gli attacchi su vulnerabilità note e già sfruttate sono spesso automatizzati: non serve essere un bersaglio “famoso” per essere colpiti.
Ci sono almeno tre motivi per cui questo aggiornamento va preso sul serio anche fuori dagli Stati Uniti:
- i prodotti coinvolti sono usati globalmente, non solo nel mercato americano;
- la pubblicazione nel catalogo KEV accelera gli attacchi opportunistici, perché segnala chiaramente ai criminali quali falle stanno funzionando;
- SharePoint, piattaforme e-commerce e apparati di rete sono componenti comuni anche nelle aziende italiane.
In altre parole, non è una notizia lontana: è un promemoria concreto sul fatto che la finestra tra disclosure e sfruttamento si sta accorciando sempre di più.
Cosa significa per la tua azienda
Se nella tua organizzazione sono presenti SharePoint, Adobe Commerce/Magento, apparati Mikrotik o prodotti WSO2, servono verifiche immediate. Le azioni pratiche, in ordine di priorità, sono queste.
1. Fai l’inventario dei sistemi esposti
La prima domanda non è “abbiamo già applicato la patch?”, ma “dove sono installati questi prodotti?”. In molte aziende la visibilità non è completa: un portale SharePoint legacy, un router in filiale, un modulo e-commerce affidato a un fornitore esterno o una componente API possono sfuggire al controllo centrale.
Serve un elenco aggiornato di:
- sistemi pubblicati su Internet;
- versioni installate;
- fornitori o partner che li gestiscono;
- integrazioni con altri ambienti aziendali.
2. Applica patch o mitigazioni senza attendere la finestra mensile
Per vulnerabilità già sfruttate, la logica del “patch day interno” spesso non basta. Se il produttore ha rilasciato aggiornamenti o mitigazioni, è opportuno valutarne l’applicazione immediata, con test rapidi ma rigorosi.
Dove l’aggiornamento non è possibile nelle prossime ore, bisogna almeno ridurre l’esposizione: limitare accessi esterni, restringere gli IP ammessi, disabilitare servizi non essenziali, aumentare monitoraggio e logging.
3. Controlla i segnali di compromissione
Una patch chiude la porta per il futuro, ma non dice nulla su eventuali accessi già avvenuti. Per questo, dopo un allarme KEV, è prudente verificare:
- accessi anomali agli account amministrativi;
- creazione di nuovi utenti o modifiche ai privilegi;
- chiamate API insolite;
- alterazioni su siti e-commerce, template o moduli;
- comportamenti anomali su router e apparati di rete.
Se l’infrastruttura non è monitorata con regolarità, ha senso farsi supportare per una verifica straordinaria di sicurezza e per una gestione più ordinata degli endpoint e dei server, ad esempio con servizi di desktop IT management.
4. Proteggi i dati in caso di incidente
Quando una vulnerabilità viene sfruttata, il problema non è solo l’intrusione: è anche la continuità operativa. Un sito e-commerce fermo, una intranet compromessa o un sistema API fuori servizio possono bloccare lavoro, ordini e rapporto con i clienti.
Per questo è essenziale affiancare il patching a backup affidabili, isolati e verificati. Un piano di remote backup ben progettato riduce tempi di fermo e margini di improvvisazione quando bisogna ripristinare rapidamente.
5. Chiediti se il tuo processo di sicurezza è adeguato, non solo il singolo prodotto
Queste notizie mostrano un problema più ampio: molte aziende reagiscono solo quando leggono il nome del software che usano. Un approccio più maturo prevede invece:
- monitoraggio continuo delle vulnerabilità rilevanti;
- ruoli chiari tra IT interno e fornitori;
- tempi massimi di intervento definiti per i sistemi critici;
- verifiche periodiche su backup, log e accessi privilegiati.
Se oggi la gestione di aggiornamenti e incidenti dipende da chiamate estemporanee o da un singolo fornitore “quando capita”, conviene strutturare un presidio stabile con un contratto di assistenza informatica che includa priorità, SLA e responsabilità chiare.
Una lezione utile: non conta solo la severità, conta l’evidenza di attacco
Tra le quattro vulnerabilità citate ci sono livelli di gravità diversi, ma tutte hanno una caratteristica comune: risultano già sfruttate. È questo il punto chiave per il management.
In termini pratici, una vulnerabilità “media” ma attivamente usata può meritare più attenzione di una vulnerabilità “critica” ancora solo teorica. Il catalogo KEV di CISA è prezioso proprio per questo: aiuta a distinguere i rischi accademici da quelli che stanno generando compromissioni reali.
Per chi prende decisioni in azienda, il messaggio è semplice: non basta sapere che esiste una falla; bisogna sapere se quella falla è già nella cassetta degli attrezzi degli attaccanti.
Domande frequenti
Se non usiamo WSO2 o Magento, possiamo ignorare l’allerta?
No. La notizia segnala anche problemi su SharePoint e Mikrotik, ma soprattutto ricorda che la priorità va data alle vulnerabilità già sfruttate, in qualunque prodotto critico presente in azienda.
Cosa dobbiamo fare oggi stesso?
Verificare se i prodotti coinvolti sono presenti, controllare le versioni, applicare patch o mitigazioni disponibili e rivedere i log per individuare eventuali accessi anomali.
Il nostro sito e-commerce è gestito da un fornitore: basta chiedere conferma?
È il primo passo, ma non basta una risposta generica. Chiedi esplicitamente versione installata, stato delle patch, eventuali mitigazioni adottate e conferma di controlli sui log e sugli accessi amministrativi.