Zero-day febbraio 2026: la crisi della patch management che ha rotto il modello patch-and-pray

Zero-day, febbraio 2026, crisi della patch management: non è uno slogan allarmistico. È la sintesi di sette giorni – dall’11 al 17 febbraio 2026 – in cui l’ecosistema della sicurezza informatica ha ricevuto simultaneamente più colpi critici di quanti qualsiasi team operativo possa ragionevolmente assorbire. Non uno alla volta, con il tempo di respirare tra un’emergenza e l’altra. Tutti insieme, in una settimana che ha reso evidente ciò che molti sospettavano da tempo: il modello reattivo della patch management non è più sostenibile.

In sette giorni si sono concentrati: due CVE critiche in Ivanti EPMM con sistemi giudiziari europei compromessi; una vulnerabilità CVSS 9.9 in BeyondTrust sfruttata entro 24 ore dalla pubblicazione del proof-of-concept; il Patch Tuesday di Microsoft con 59 vulnerabilità e sei zero-day attivamente sfruttati; uno zero-day Apple descritto come parte di un attacco “estremamente sofisticato”; 30 estensioni Chrome malevole che hanno colpito oltre 260.000 utenti; una nuova variante ClickFix basata su DNS; e campagne attive di supply chain poisoning su npm e PyPI collegate a Lazarus Group.

Nessun SOC al mondo è dimensionato per gestire tutto questo contemporaneamente. Ed è esattamente questo il punto.

Il catalogo dell’impossibile: cosa è successo tra l’11 e il 17 febbraio

Per comprendere la portata della crisi è necessario ricostruire la sequenza degli eventi con la precisione di una timeline forense. Non perché l’elenco sia fine a sé stesso, ma perché la densità temporale è il dato che trasforma una serie di incidenti individuali in un problema sistemico.

Ivanti EPMM: il vendor che non smette di essere vulnerabile

Il 29 gennaio 2026, Ivanti ha divulgato due vulnerabilità critiche nel suo Endpoint Manager Mobile – CVE-2026-1281 e CVE-2026-1340, entrambe con score CVSS 9.8 – che consentivano l’esecuzione di codice remoto senza autenticazione. Nelle settimane successive la situazione è degenerata rapidamente: il governo olandese ha confermato al Parlamento che la Dutch Data Protection Authority e il Consiglio della Magistratura erano stati compromessi. La Commissione Europea ha ammesso un attacco alla propria infrastruttura di gestione dei dispositivi mobili. La finlandese Valtori ha rivelato l’esposizione di dati relativi a fino a 50.000 dipendenti governativi.

L’analisi di GreyNoise ha rivelato un dato particolarmente allarmante: l’83% dell’attività di sfruttamento proveniva da un singolo indirizzo IP ospitato su infrastruttura bulletproof di PROSPERO OOO (AS200593), registrato a San Pietroburgo. In nove giorni (1-9 febbraio) i sensori GreyNoise hanno registrato 417 sessioni di exploitation, con un picco di 269 in un singolo giorno – l’8 febbraio – pari a tredici volte la media giornaliera della settimana precedente.

Il dettaglio più inquietante non è lo sfruttamento in sé, ma la natura dell’attività post-compromissione. Defused Cyber ha identificato una campagna che installava web shell “dormienti” – class loader Java in memoria al percorso /mifs/403.jsp – attivabili solo con un parametro specifico. Nessuna attività malevola osservata dopo l’impianto. Il pattern è quello dell’initial access broker: compromettere, catalogare, rivendere l’accesso. Il che significa che le conseguenze reali di questa campagna potrebbero manifestarsi settimane o mesi dopo.

Il problema Ivanti, tuttavia, non è la singola vulnerabilità. È il pattern. Ivanti EPMM (precedentemente MobileIron Core) è stato colpito da vulnerabilità critiche di esecuzione remota a luglio 2023 (CVE-2023-35078, sfruttata contro il governo norvegese), a maggio 2025 (CVE-2025-4427 e CVE-2025-4428, catena di authentication bypass + RCE sfruttata da attori state-nexus cinesi) e ora a gennaio 2026. A luglio 2025 la campagna “ToolShell” – attribuita ad APT27 e APT31 e diretta primariamente contro server SharePoint on-premise – ha visto gli stessi attaccanti sfruttare anche vulnerabilità note in Ivanti EPMM come vettore complementare, come documentato da Check Point Research.

Stesso prodotto, stesso tipo di falla (code injection, RCE non autenticata), stesso risultato: governi europei compromessi. Come ha osservato Dark Reading, i prodotti Ivanti restano ampiamente implementati nelle organizzazioni di alto profilo nonostante una storia di sicurezza che dovrebbe indurre a riconsiderarne l’adozione. L’NHS britannico ha puntualizzato che i dispositivi edge come EPMM sono esposti a internet by design e rappresentano bersagli attraenti per gli attaccanti, e ha valutato come “altamente probabile” che le vulnerabilità in questi dispositivi continuino a essere sfruttate come zero-day.

BeyondTrust: CVSS 9.9 e sfruttamento in ore, non giorni

Il 6 febbraio 2026, BeyondTrust ha pubblicato l’advisory BT26-02, rivelando una vulnerabilità critica di tipo OS command injection – CVE-2026-1731, CVSSv4 9.9 (CVSSv3 9.8) – nei prodotti Remote Support e Privileged Remote Access. Lo sfruttamento non richiede autenticazione, non richiede interazione dell’utente e la complessità dell’attacco è bassa. In termini pratici: un attaccante può eseguire comandi arbitrari sul sistema operativo inviando richieste appositamente costruite.

I ricercatori di Hacktron AI, che hanno scoperto la vulnerabilità attraverso un’analisi di varianti assistita dall’intelligenza artificiale, hanno stimato circa 11.000 istanze esposte su internet, di cui 8.500 on-premise e potenzialmente vulnerabili.

La cronologia successiva è un caso di studio sulla velocità con cui il panorama delle minacce si muove nel 2026. Il 10 febbraio, Rapid7 ha pubblicato l’analisi tecnica completa e un proof-of-concept. Entro 24 ore, GreyNoise ha rilevato attività di ricognizione e sfruttamento diretta contro istanze BeyondTrust. Il 12 febbraio, il responsabile threat intelligence di watchTowr, Ryan Dewhurst, ha confermato il primo sfruttamento in-the-wild, avvertendo che le istanze non patchate dovessero essere considerate compromesse. Il 13 febbraio, CISA ha aggiunto la CVE al catalogo KEV, con scadenza per le agenzie federali fissata al 16 febbraio. Lo stesso giorno, Arctic Wolf ha rilevato tentativi di deploy dello strumento SimpleHelp RMM per la persistenza e il movimento laterale.

Il contesto storico rende la situazione ancora più grave. BeyondTrust è lo stesso vendor le cui vulnerabilità zero-day (CVE-2024-12356 e CVE-2024-12686) erano state sfruttate dal gruppo cinese Silk Typhoon per violare il Dipartimento del Tesoro statunitense nel 2024, ottenendo accesso a documenti non classificati relativi a sanzioni. L’analisi tecnica ha definito CVE-2026-1731 una “variante” della stessa classe di vulnerabilità utilizzata in quell’attacco. Lo schema si ripete: vendor di accesso privilegiato compromesso, sfruttamento rapido, impatto su infrastrutture sensibili.

Microsoft Patch Tuesday: sei zero-day in un colpo solo

L’11 febbraio, Microsoft ha rilasciato il Patch Tuesday di febbraio con correzioni per 59 vulnerabilità, di cui sei zero-day attivamente sfruttati – tre dei quali erano anche stati divulgati pubblicamente prima della disponibilità delle patch. Come ha osservato Petri IT, sei bug sfruttati rappresentano un numero insolitamente elevato, soprattutto confrontato con il gennaio 2026 che ne aveva solo uno su quasi il doppio delle CVE.

I sei zero-day coprono uno spettro preoccupante di componenti core:

• CVE-2026-21510 (CVSS 8.8): bypass delle protezioni SmartScreen e Windows Shell, sfruttabile convincendo l’utente ad aprire un link o un file shortcut malevolo. In pratica, sopprime i dialoghi di sicurezza per i contenuti non affidabili, facilitando l’esecuzione di payload senza avvisi.
• CVE-2026-21513: bypass dei controlli di sicurezza nel motore MSHTML/Trident di Internet Explorer, sfruttabile via file HTML o LNK malevoli.
• CVE-2026-21514 (CVSS 5.5 secondo l’advisory Microsoft): bypass delle mitigazioni OLE in Microsoft Word, attivabile con un documento Office malevolo.
• CVE-2026-21519 (CVSS 7.8): escalation di privilegi a SYSTEM nel Desktop Window Manager tramite type confusion. DWM era già apparso tra le vulnerabilità sfruttate nel Patch Tuesday precedente, confermando il suo status di bersaglio ricorrente.
• CVE-2026-21533: escalation di privilegi a SYSTEM in Windows Remote Desktop Services. CrowdStrike ha avvertito che la pubblicazione del dettaglio tecnico “quasi certamente incoraggia i threat actor in possesso dei binari exploit a utilizzarli o monetizzarli nel breve termine”.
• CVE-2026-21525 (CVSS 6.2): denial-of-service nel Remote Access Connection Manager, capace di interrompere le connessioni VPN. Un attaccante con accesso di utente standard può mandare in crash il servizio RAS, e le organizzazioni che dipendono da connessioni VPN always-on rischiano la perdita di accesso alla rete.

Tutte e sei le vulnerabilità sono state aggiunte da CISA al catalogo KEV. Il fatto che Google Threat Intelligence Group, Microsoft Threat Intelligence Center, Microsoft Security Response Center e il team sicurezza di Office Product Group abbiano tutti contribuito alla scoperta suggerisce campagne di attacco coordinate e sofisticate, già in corso al momento del rilascio delle patch.

A questo si aggiunge il contesto del gennaio 2026, che aveva già registrato 114 vulnerabilità patchate – uno dei rilasci di gennaio più massicci della storia recente – con otto vulnerabilità critiche e tre zero-day. Il febbraio non è arrivato in un momento di tregua: è arrivato dopo che i SOC erano già in affanno.

Apple: lo zero-day “estremamente sofisticato”

Il 12 febbraio, Apple ha rilasciato aggiornamenti per iOS 26.3, iPadOS 26.3, macOS Tahoe 26.3, watchOS 26.3, tvOS 26.3 e visionOS 26.3, correggendo CVE-2026-20700 – una vulnerabilità di corruzione della memoria nel componente dyld (Dynamic Link Editor), il sistema che carica le librerie dinamiche in memoria e collega il codice delle applicazioni ai framework di sistema.

Apple ha utilizzato una formulazione specifica: “un attacco estremamente sofisticato contro individui specificamente selezionati su versioni di iOS precedenti a iOS 26”. La terminologia – “sofisticato” e “mirato” – è convenzionalmente impiegata per indicare attività di sorveglianza sponsorizzata da Stati o condotta tramite spyware commerciale. La scoperta è stata attribuita al Google Threat Analysis Group, il team specializzato nel tracciamento di gruppi hacking governativi e venditori di sorveglianza.

La vulnerabilità è collegata a due CVE precedenti – CVE-2025-14174 e CVE-2025-43529, corrette nel dicembre 2025 – suggerendo una catena di exploit multipla in cui gli attaccanti hanno combinato diverse falle per aggirare le difese moderne dei dispositivi mobili.

L’ecosistema browser sotto assedio: estensioni Chrome e add-in Outlook

Nella stessa settimana, LayerX ha pubblicato i risultati della ricerca sulla campagna “AiFrame”: 30 estensioni Chrome mascherate da assistenti AI che hanno compromesso oltre 260.000 utenti. Le estensioni si presentavano come strumenti di produttività – riassuntori, chatbot, assistenti Gmail – ma condividevano lo stesso codice, le stesse permission, la stessa infrastruttura backend sotto il dominio tapnetic.pro.

Invece di implementare funzionalità localmente, le estensioni caricavano un iframe a schermo intero da domini remoti controllati dagli attaccanti, trasformandosi in proxy privilegiati che concedevano all’infrastruttura esterna accesso alle API sensibili del browser. Quindici delle trenta estensioni prendevano di mira specificamente i dati Gmail con content script dedicati. BleepingComputer ha confermato che alcune estensioni erano ancora presenti nel Chrome Web Store con decine di migliaia di installazioni al momento della pubblicazione.

Parallelamente, la settimana precedente aveva visto la scoperta del primo add-in Outlook malevolo, documentato da Koi Security: il dominio abbandonato di un add-in legittimo (AgreeTo, un tool di scheduling ospitato su Vercel all’indirizzo outlook-one.vercel[.]app ) era stato rilevato e utilizzato per servire una pagina di login Microsoft falsificata, rubando oltre 4.000 credenziali – incluse credenziali Microsoft, numeri di carte di credito e risposte a domande di sicurezza bancarie. I dati venivano esfiltrati tramite Telegram Bot API. Microsoft ha rimosso l’add-in dal Marketplace tra il 12 e il 14 febbraio 2026.

ClickFix: il DNS come canale di distribuzione del malware

Il 13 febbraio, Microsoft Threat Intelligence ha divulgato una nuova variante della tecnica ClickFix che utilizza il comando nslookup per eseguire query DNS verso server controllati dagli attaccanti, ricevendo in risposta script PowerShell malevoli che vengono poi eseguiti sulla macchina della vittima. È il primo uso documentato del DNS come canale di staging in campagne ClickFix.

La tecnica è particolarmente insidiosa perché il traffico DNS si mescola con l’attività di rete normale, riducendo la dipendenza dalle richieste web tradizionali e sfuggendo ai sistemi di rilevamento basati sull’analisi del traffico HTTP. Malwarebytes ha spiegato che i criminali hanno sviluppato questo metodo dopo che i comandi mshta e PowerShell sono stati sempre più bloccati dai software di sicurezza. Il payload finale identificato è ModeloRAT, un trojan ad accesso remoto basato su Python.

Supply chain poisoning: Lazarus Group su npm e PyPI

Nella stessa settimana, ReversingLabs ha pubblicato i risultati della ricerca sulla campagna “graphalgo”: un’operazione coordinata collegata a Lazarus Group che ha distribuito pacchetti malevoli sia su npm che su PyPI, mascherandoli da strumenti legittimi nell’ambito di una falsa campagna di reclutamento legata a blockchain e criptovalute. Gli sviluppatori venivano avvicinati tramite LinkedIn, Facebook e Reddit con offerte di lavoro fittizie per la società “Veltrix Capital”, e indotti a scaricare codice contenente dipendenze malevole. I pacchetti fungevano da loader di primo stadio per un RAT (Remote Access Trojan) in grado di esfiltrare dati e manipolare file.

Un esempio significativo: il pacchetto npm bigmathutils ha raggiunto oltre 10.000 download nella versione benigna prima che fosse pubblicata la versione malevola. La campagna, attiva dal maggio 2025, è stata resa pubblica il 12 febbraio 2026.

Il punto di rottura: perché questa settimana è diversa

I professionisti della sicurezza sono abituati a settimane impegnative. Il Patch Tuesday è un evento mensile, gli zero-day sono una costante, le campagne di phishing non si fermano mai. Ma la settimana dell’11-17 febbraio 2026 è qualitativamente diversa per ragioni strutturali, non solo quantitative.

La capacità operativa ha un limite fisico

Un SOC medio dispone di risorse finite: analisti, ore-uomo, finestre di manutenzione, capacità di test. Consideriamo cosa dovrebbe fare simultaneamente un team di sicurezza competente nella settimana in questione: patchare Ivanti EPMM assumendo che tutte le istanze esposte siano compromesse, avviando indagini forensi e cercando web shell dormienti al percorso /mifs/403.jsp; aggiornare BeyondTrust Remote Support e PRA,.

Considerando che lo sfruttamento è iniziato entro 24 ore dal PoC e che CISA ha fissato la scadenza al 16 febbraio; distribuire 59 patch Microsoft con priorità accelerata per i sei zero-day attivi, testando la compatibilità in ambienti complessi; aggiornare l’intero parco Apple a iOS 26.3, macOS Tahoe 26.3 e versioni correlate; auditare le estensioni Chrome installate nell’organizzazione confrontandole con gli IoC della campagna AiFrame, revocando le sessioni compromesse; verificare gli add-in Outlook per individuare quelli potenzialmente malevoli; monitorare la supply chain npm/PyPI per pacchetti malevoli collegati alla campagna graphalgo di Lazarus; aggiornare le regole di detection per la variante ClickFix basata su DNS.

Nessun SOC al mondo – nemmeno quello di una Fortune 500 con budget illimitato – è progettato per eseguire tutte queste operazioni simultaneamente mantenendo la qualità necessaria. Il risultato inevitabile è la prioritizzazione, e la prioritizzazione implica che qualcosa resta scoperto. Quella copertura mancante diventa la superficie d’attacco che gli avversari sfruttano.

Il fallimento del modello reattivo

La patch management tradizionale si basa su un assunto implicito: che il ritmo di scoperta delle vulnerabilità attivamente sfruttate sia compatibile con la capacità operativa di applicare le correzioni. Per anni questo assunto ha retto – a malapena, con frequenti violazioni, ma ha retto. Febbraio 2026 dimostra che l’assunto è crollato.

Il problema non è la singola vulnerabilità critica. È la combinazione simultanea di: vulnerabilità critiche in vendor diversi (Ivanti, BeyondTrust, Microsoft, Apple) che richiedono processi di patch separati; sfruttamento attivo confermato per molte di esse, che trasforma il patching da manutenzione programmata a risposta d’emergenza; supply chain attack su ecosistemi diversi (browser extension, npm/PyPI, add-in Outlook) che richiedono attività di audit completamente distinte dal vulnerability management; nuove tecniche di attacco (ClickFix DNS) che richiedono aggiornamento delle regole di detection e della formazione.

Tyler Reguly di Fortra ha colto il punto con precisione, commentando il solo Patch Tuesday Microsoft: “A prima vista, questo mese sembra ragionevole – 60 CVE. Quando si guarda più da vicino, ci si rende conto che c’è molto in ballo. Il 10% delle vulnerabilità di questo mese è indicato da Microsoft come exploit detected“.

Il 10% non sarebbe allarmante in isolamento. Ma quando si somma al 100% delle CVE Ivanti sfruttate, al 100% della CVE BeyondTrust sfruttata, allo zero-day Apple sfruttato e a tutto il resto, il carico complessivo supera qualsiasi capacità ragionevole di risposta.

Il debito strutturale: come siamo arrivati qui

La settimana nera di febbraio 2026 non è un evento casuale. È il risultato di tendenze strutturali che si accumulano da anni e che hanno raggiunto simultaneamente il punto di rottura.

La proliferazione dei dispositivi edge

La concentrazione di vulnerabilità in Ivanti EPMM e BeyondTrust PRA riflette un problema architetturale fondamentale: le organizzazioni hanno accumulato dispositivi edge – VPN, MDM, accesso remoto privilegiato – che sono esposti a internet by design, contengono funzionalità critiche e sono gestiti da vendor con track record di sicurezza discutibile.

Come ha osservato l’NHS britannico nel suo avviso sulle vulnerabilità Ivanti: “I dispositivi edge come EPMM sono esposti a internet per progettazione e sono bersagli altamente attraenti per gli attaccanti. Il numero di vulnerabilità in dispositivi edge divulgate ogni anno è in aumento e vengono rapidamente sfruttate”. CISA ha emesso una nuova direttiva operativa vincolante in concomitanza con il Patch Tuesday di febbraio, richiedendo alle agenzie federali di rimuovere i dispositivi di rete che hanno raggiunto la fine del supporto. Ma la direttiva, pur necessaria, arriva dopo che il danno è stato fatto.

Il vendor ricorrentemente vulnerabile

Ivanti merita una riflessione a parte perché il suo caso illustra un fallimento del modello di gestione del rischio. Un vendor il cui prodotto viene compromesso una volta è un incidente. Un vendor il cui stesso prodotto viene colpito da vulnerabilità critiche di RCE non autenticata nel 2023, nel 2025 e nel 2026 – sempre con governi europei tra le vittime – è un pattern architetturale.

watchTowr ha osservato che i dispositivi EPMM sono spesso utilizzati da organizzazioni di alto valore, e che le organizzazioni che esponevano istanze vulnerabili al momento della disclosure dovrebbero considerarle compromesse, smontare l’infrastruttura e ricostruirla da zero. Ma la realtà è che molte organizzazioni non possono “smontare l’infrastruttura” di gestione dei dispositivi mobili nel mezzo di una settimana in cui devono anche patchare tutto il resto.

La domanda che NIS2 e DORA pongono implicitamente, ma che poche organizzazioni si stanno ponendo esplicitamente, è: quando un vendor diventa una liability? Qual è la soglia di vulnerabilità ricorrenti oltre la quale la dipendenza da un singolo prodotto diventa un rischio inaccettabile?

La velocità di weaponization

Il caso BeyondTrust illustra un secondo trend strutturale: il tempo tra la divulgazione di una vulnerabilità e il suo sfruttamento attivo si è compresso al punto da essere incompatibile con i cicli di patching tradizionali.

CVE-2026-1731 è stata divulgata il 6 febbraio. Il PoC è stato pubblicato il 10 febbraio. Lo sfruttamento attivo è stato rilevato l’11 febbraio – meno di 24 ore dopo il PoC, cinque giorni dopo la disclosure. GreyNoise ha osservato che gli IP che effettuavano ricognizione per CVE-2026-1731 non erano single-purpose: contemporaneamente conducevano tentativi di exploitation attiva contro SonicWall, MOVEit Transfer, Log4j, firewall Sophos, brute-forcing SSH e testing di credenziali IoT di default. Gli attaccanti moderni sono poliattaccanti: ogni IP di scansione è un hub multiprotocollo che testa simultaneamente decine di vulnerabilità su superfici d’attacco diverse.

Questo significa che la finestra temporale per il patching non è più misurata in settimane o giorni. È misurata in ore. E le ore disponibili sono le stesse in cui il SOC sta gestendo Ivanti, Microsoft, Apple e tutto il resto.

Dall’emergenza alla strategia: cosa deve cambiare

Se febbraio 2026 è il momento in cui il modello patch-and-pray si è rotto, la domanda operativa è: con cosa lo sostituiamo?

Prioritizzazione basata su intelligence, non su CVSS

Il CVSS è uno strumento utile per classificare la severità tecnica di una vulnerabilità, ma è insufficiente per guidare le decisioni operative quando tutto è critico. Quando Ivanti è 9.8, BeyondTrust è 9.9 e Microsoft ha sei zero-day attivi, il CVSS non discrimina.

La risposta è l’integrazione di metriche di sfruttamento reale: l’Exploit Prediction Scoring System (EPSS) di FIRST, che stima la probabilità che una vulnerabilità venga sfruttata nei prossimi 30 giorni, e il catalogo Known Exploited Vulnerabilities di CISA, che conferma lo sfruttamento in-the-wild. L’approccio combinato EPSS + CISA KEV + contesto ambientale (l’asset è esposto a internet? Contiene dati critici? È nella kill chain di un attacco noto?) produce una prioritizzazione che riflette il rischio reale, non quello teorico.

Riduzione della superficie d’attacco, non rincorsa delle patch

La lezione strategica di febbraio 2026 è che la rincorsa infinita delle patch è una partita persa in partenza quando il volume degli exploit attivi supera la capacità operativa. L’alternativa non è smettere di patchare – il patching resta fondamentale – ma integrarlo con la riduzione strutturale della superficie d’attacco.

Questo significa: rimuovere dall’esposizione internet tutto ciò che non deve essere esposto (quante istanze Ivanti EPMM erano esposte senza necessità operativa?); segmentare la rete in modo che la compromissione di un dispositivo edge non equivalga alla compromissione dell’intero ambiente; implementare policy di allowlisting per le estensioni browser, riducendo la dipendenza dalla velocità con cui Google rimuove le estensioni malevole dal Web Store; adottare architetture zero trust dove l’accesso è verificato continuamente, non concesso una tantum al momento dell’autenticazione.

Automazione del patching con test integrati

Il collo di bottiglia del patching non è il download della patch. È il test di compatibilità. Le organizzazioni ritardano il deployment perché temono – legittimamente – che una patch critica possa rompere un’applicazione di business. La risposta è l’automazione del ciclo test-deploy con ambienti di staging che replicano la produzione e pipeline CI/CD per le patch di sicurezza, con rollback automatico in caso di problemi.

Il modello assume breach applicato al vulnerability management

La campagna Ivanti con le web shell dormienti illustra un principio che i SOC dovrebbero applicare universalmente: quando una vulnerabilità critica in un sistema esposto viene divulgata, non si parte dalla domanda “siamo stati compromessi?” ma dall’assunto “siamo stati compromessi”, e si lavora per confermare o escludere. L’NCSC olandese ha raccomandato esplicitamente che tutte le organizzazioni che utilizzano Ivanti EPMM dovrebbero assumere la compromissione e condurre un’indagine forense. Questo approccio, applicato sistematicamente, cambia radicalmente la postura difensiva.

Zero-day febbraio 2026 e il futuro della patch management

La settimana nera di febbraio 2026 non è un’anomalia statistica. È un segnale direzionale. Il numero di vulnerabilità attivamente sfruttate è in crescita strutturale: il solo gennaio 2026 aveva registrato 114 CVE Microsoft (con tre zero-day), e il febbraio ha aggiunto 59 CVE (con sei zero-day). Se il trend prosegue, il 2026 batterà ogni record precedente.

Tre dinamiche convergenti alimentano questa escalation. La prima è la crescente complessità delle infrastrutture IT: più prodotti, più integrazioni, più superfici d’attacco. La seconda è la professionalizzazione dell’offensiva: gli initial access broker che piantano web shell dormienti in Ivanti operano con la stessa logica di business di un fornitore SaaS. La terza è l’accelerazione della weaponization assistita dall’AI: CVE-2026-1731 in BeyondTrust è stata scoperta tramite “analisi di varianti assistita dall’intelligenza artificiale”, e la stessa tecnologia è disponibile anche per gli attaccanti.

Per le organizzazioni soggette a NIS2 e DORA, la settimana di febbraio 2026 ha implicazioni dirette. NIS2 richiede misure di gestione del rischio proporzionate, inclusa la sicurezza della supply chain e la gestione delle vulnerabilità. Un ambiente in cui vulnerabilità critiche in vendor diversi vengono sfruttate contemporaneamente e il SOC non riesce a gestirle tutte richiede una rivalutazione esplicita del risk assessment. DORA, per le entità finanziarie, richiede test di resilienza operativa digitale: gli scenari di test dovrebbero includere la simulazione di settimane come questa, per validare che l’organizzazione possa sostenere un carico multiplo di emergenze simultanee.

La domanda che ogni CISO dovrebbe porsi dopo febbraio 2026 non è “abbiamo patchato tutto in tempo?” – una domanda retrospettiva e in gran parte retorica. La domanda è: “Se la prossima settimana fosse identica a questa, il nostro SOC reggerebbe?”. Se la risposta è no, l’architettura difensiva ha un problema strutturale che nessun aumento del budget per il patching potrà risolvere. La crisi degli zero-day di febbraio 2026 non si risolve patchando più velocemente. Si risolve costruendo infrastrutture che necessitino di meno patch per restare sicure.

Checklist operativa per SOC e vulnerability management

1. Verificare lo stato di patching per Ivanti EPMM (CVE-2026-1281, CVE-2026-1340), BeyondTrust RS/PRA (CVE-2026-1731), Microsoft Patch Tuesday febbraio 2026 (59 CVE, 6 zero-day), Apple (CVE-2026-20700). Trattare le istanze non patchate ed esposte come compromesse.
2. Ricercare indicatori di compromissione Ivanti: controllare il percorso /mifs/403.jsp per web shell dormienti, verificare i log DNS per callback OAST (sottodomini ad alta entropia verso infrastruttura di interazione nota), bloccare AS200593 (PROSPERO OOO) al perimetro di rete.
3. Auditare le estensioni Chrome nell’organizzazione confrontandole con gli IoC della campagna AiFrame (dominio tapnetic.pro). Implementare policy di allowlisting per le estensioni browser.
4. Implementare prioritizzazione EPSS + CISA KEV nel processo di vulnerability management, sostituendo o integrando la prioritizzazione basata esclusivamente su CVSS.
5. Aggiornare le regole di detection per la variante ClickFix basata su DNS: monitorare query nslookup verso server DNS esterni non standard, filtrare la risposta Name: per contenuto eseguibile.
6. Monitorare la supply chain npm/PyPI per pacchetti collegati alla campagna graphalgo di Lazarus Group, verificando le dipendenze nei progetti di sviluppo interni.
7. Simulare lo scenario “settimana nera” nei prossimi esercizi di incident response e TLPT: cosa succede quando il SOC deve gestire quattro emergenze critiche di vendor diversi contemporaneamente?
8. Rivalutare la dipendenza da vendor ricorrentemente vulnerabili: inserire nel risk assessment un indicatore di “frequenza di vulnerabilità critiche” per vendor e definire soglie oltre le quali si avvia un piano di migrazione.