Vulnerabilità informatiche sfruttate: come stabilire le priorità di remediation nel 2026

Ogni anno vengono pubblicate migliaia di nuove vulnerabilità, ma soltanto una parte viene realmente sfruttata dagli attaccanti. Per un’azienda il problema non è quindi “installare tutte le patch il prima possibile” in modo indiscriminato: è distinguere le vulnerabilità che rappresentano un rischio concreto per il proprio ambiente e correggerle con priorità coerenti con esposizione, sfruttamento osservato e impatto sul business.

Una lista statica delle “10 vulnerabilità più pericolose” diventa rapidamente obsoleta. Nel 2026 un processo maturo usa fonti dinamiche: il catalogo CISA Known Exploited Vulnerabilities per sapere quali CVE hanno evidenze di sfruttamento reale, EPSS per stimare la probabilità di exploit nel breve periodo, CVSS per descrivere la severità tecnica e soprattutto il contesto aziendale per capire se l’asset è presente, raggiungibile e critico.

Che cos’è una vulnerabilità informatica

Una vulnerabilità è una debolezza che può essere sfruttata per compromettere riservatezza, integrità o disponibilità di un sistema. Può derivare da un bug software, da una configurazione errata, da un controllo di autenticazione debole, da permessi eccessivi o da una combinazione di condizioni che crea un percorso di attacco.

Quando una vulnerabilità software viene pubblicamente identificata può ricevere un codice CVE, che consente a vendor, scanner e team di sicurezza di riferirsi allo stesso problema. Il CVE è però un identificatore, non una misura completa del rischio. Due aziende con la stessa CVE possono avere livelli di esposizione completamente diversi.

Perché il CVSS da solo non basta

Il CVSS descrive caratteristiche tecniche della vulnerabilità e fornisce un punteggio di severità. È utile per comprendere quanto una debolezza possa essere grave in condizioni standard, ma non dice se quella CVE è presente nel tuo ambiente, se l’asset è esposto a Internet, se esiste exploit attivo o quale conseguenza avrebbe la compromissione sul processo aziendale.

Per questo una vulnerabilità con punteggio elevato su un sistema isolato e non utilizzato può essere meno urgente di una vulnerabilità con punteggio inferiore presente su un gateway Internet-facing, su un sistema di identità o su un’applicazione critica. La priorità deve essere risk-based, non score-based.

CISA KEV: il segnale più forte di sfruttamento noto

Il catalogo Known Exploited Vulnerabilities di CISA raccoglie vulnerabilità per le quali esistono evidenze di sfruttamento in the wild. Per i difensori questo è un segnale molto forte: la vulnerabilità non è soltanto teoricamente sfruttabile, ma è già entrata nell’ecosistema reale degli attacchi.

La presenza nel KEV non significa automaticamente che ogni asset sia compromesso, ma dovrebbe far salire immediatamente la priorità di verifica: inventario, esposizione, versione, presenza della patch, controlli compensativi e telemetria disponibile. CISA raccomanda di usare il catalogo come input del processo di vulnerability management e di prioritizzare la remediation delle vulnerabilità note come sfruttate.

EPSS: stimare la probabilità di exploit nel breve periodo

EPSS, sviluppato dalla comunità FIRST, utilizza un modello data-driven per stimare la probabilità che una CVE venga sfruttata nel mondo reale nei successivi 30 giorni. Il punteggio viene aggiornato quotidianamente e aggiunge un’informazione diversa dal CVSS: non “quanto può essere grave?”, ma “quanto è probabile osservare attività di exploit nel breve periodo?”.

EPSS non è un risk score completo. Non conosce il tuo inventario, non sa se il sistema è esposto e non misura l’impatto sul business. Il suo valore emerge quando viene combinato con KEV, severità tecnica e contesto ambientale. Dal 15 giugno 2026 FIRST pubblica la versione 5 del modello EPSS, ulteriore motivo per evitare soglie statiche copiate da vecchie procedure.

Il modello di priorità consigliato

Un processo pratico può ordinare le vulnerabilità combinando cinque domande. Nessun singolo punteggio sostituisce questa valutazione:

• È sfruttata realmente? Presenza nel CISA KEV o altra threat intelligence affidabile.
• È presente e raggiungibile? L’asset esiste nell’inventario, è esposto a Internet o accessibile da segmenti compromettibili?
• Quanto è probabile l’exploit? EPSS e disponibilità di exploit pubblici aiutano a stimare l’urgenza.
• Qual è l’impatto? Identità, gateway, hypervisor, backup, ERP e sistemi produttivi hanno conseguenze diverse da asset marginali.
• Esistono mitigazioni o controlli compensativi? Segmentazione, WAF, EDR, hardening, MFA o disabilitazione della funzione possono ridurre temporaneamente il rischio.

1. Vulnerabilità su sistemi esposti a Internet

Gateway VPN, firewall, appliance di rete, portali e servizi Internet-facing sono obiettivi ad alta priorità perché possono essere raggiunti senza che l’attaccante abbia già compromesso la rete interna. Una vulnerabilità di remote code execution, authentication bypass o command injection su questi sistemi può diventare un punto di accesso iniziale particolarmente efficace.

La remediation deve partire dalla verifica dell’inventario esterno. Se l’azienda non sa quali asset sono pubblicamente raggiungibili, non può stabilire correttamente la propria esposizione. Dispositivi dimenticati, vecchi pannelli di amministrazione e servizi pubblicati temporaneamente sono spesso più critici della singola CVE.

2. Vulnerabilità di autenticazione e identity

Le vulnerabilità che permettono di bypassare autenticazione, rubare token, ottenere credenziali o elevare privilegi hanno un impatto particolarmente elevato perché possono trasformare un singolo accesso in movimento laterale e compromissione di account amministrativi. In ambienti Microsoft, la superficie di rischio comprende sia vulnerabilità software sia debolezze di configurazione e privilegi.

Per il sotto-intento specifico Active Directory, questa pagina non deve duplicare una guida verticale: l’approfondimento corretto è 8 vulnerabilità Active Directory comuni nel 2026, che tratta Kerberos, ACL, NTLM, tiering, LDAP e logging nel dominio.

3. Vulnerabilità su applicazioni enterprise e middleware

Applicazioni di gestione, collaboration platform, middleware e sistemi esposti alle reti aziendali possono contenere vulnerabilità che consentono esecuzione di codice, lettura di dati o bypass dei controlli di accesso. Questi prodotti sono interessanti per gli attaccanti perché spesso hanno privilegi elevati, connessioni verso database e identità aziendali e una presenza estesa nelle organizzazioni.

La criticità va valutata considerando non solo la CVE ma anche la funzione dell’applicazione. Un sistema con accesso a credenziali, file condivisi o dati regolamentati può avere un impatto maggiore rispetto a un servizio isolato con la stessa severità tecnica.

4. Vulnerabilità client-side e documenti malevoli

Browser, componenti di rendering, suite di produttività e visualizzatori di documenti restano superfici rilevanti perché possono essere raggiunti attraverso phishing, link o file. Una vulnerabilità client-side può richiedere interazione dell’utente, ma questa condizione non la rende automaticamente poco importante: nelle campagne reali l’ingegneria sociale viene usata proprio per ottenere l’interazione necessaria.

Qui patching e protezione endpoint devono lavorare insieme. Aggiornare il software riduce la superficie tecnica; Endpoint Protection aziendale ed EDR aiutano a rilevare comportamenti successivi anomali quando il vettore iniziale supera i controlli preventivi.

5. Privilege escalation e post-exploitation

Una vulnerabilità locale di privilege escalation può sembrare meno urgente di una RCE remota, ma diventa critica quando viene combinata con un accesso iniziale già ottenuto. Gli attaccanti lavorano per catene: una credenziale di basso livello, un endpoint compromesso e una vulnerabilità locale possono essere sufficienti per raggiungere privilegi amministrativi.

Questo è il motivo per cui la priorità deve considerare gli attack path e non soltanto il singolo host. Segmentazione, privilegi minimi, protezione delle identità e capacità di detection riducono l’effetto combinato delle vulnerabilità.

6. Vulnerabilità web e API

Applicazioni web e API introducono una superficie che non coincide sempre con le CVE tradizionali. Errori di autorizzazione, injection, esposizione di dati, gestione debole delle sessioni e business logic flaws possono essere specifici dell’applicazione e non comparire in un catalogo di vulnerabilità del prodotto.

Per questo vulnerability scanning e patch management non sostituiscono test applicativi e secure coding. Una CVE nota va corretta, ma una vulnerabilità logica custom può richiedere analisi manuale e remediation nel codice.

7. Vulnerabilità su hypervisor, backup e infrastruttura critica

Hypervisor, piattaforme di virtualizzazione, sistemi di backup e infrastrutture di gestione meritano priorità elevata perché concentrano privilegi e accesso a molti workload. La compromissione di un singolo piano di controllo può avere effetto su numerosi server, macchine virtuali o copie di backup.

In questi casi la remediation deve includere non soltanto patching, ma anche separazione delle credenziali amministrative, MFA quando supportata, management network dedicata, accesso ristretto e verifica dei log.

8. Vulnerabilità legacy e sistemi non più supportati

Un sistema end-of-life non è pericoloso soltanto perché “vecchio”: il problema è che nuove vulnerabilità possono non ricevere patch e che i controlli moderni potrebbero non essere disponibili. Se il componente non può essere aggiornato immediatamente, il rischio deve essere gestito con isolamento, segmentazione, restrizione degli accessi, monitoraggio e un piano di sostituzione con data e responsabilità definite.

Dalla CVE alla remediation: workflow operativo

• Inventario: associare CVE e prodotto agli asset reali, con owner e criticità.
• Esposizione: determinare raggiungibilità Internet, segmenti di rete e prerequisiti di attacco.
• Threat context: verificare KEV, EPSS e intelligence su exploit attivi.
• Priorità: combinare probabilità, impatto, criticità del servizio e controlli compensativi.
• Remediation: patch, upgrade, configurazione, disabilitazione della funzione o mitigazione temporanea.
• Validazione: confermare che la vulnerabilità non sia più presente e che il servizio funzioni correttamente.
• Monitoring: ricercare indicatori di sfruttamento quando la vulnerabilità è nota come attivamente sfruttata.
• Reporting: tracciare eccezioni, scadenze, rischio residuo e responsabilità.

Vulnerability assessment, penetration test e risk assessment: ruoli diversi

Questa guida non deve sovrapporsi alle pagine di servizio. Il vulnerability management stabilisce quali debolezze correggere e con quale priorità. Un penetration test verifica in modo controllato se determinate debolezze possono essere sfruttate e quale impatto concreto producono. Il risk assessment collega invece vulnerabilità, minacce, probabilità e impatto ai processi aziendali.

Per comprendere metodologia e differenze puoi consultare la guida al penetration test e il servizio di Risk Assessment aziendale. Quando serve validare la reale sfruttabilità delle debolezze su un perimetro autorizzato, il riferimento commerciale è il Penetration Test per aziende.

La regola per il 2026: patchare per rischio, non per rumore

Un programma efficace non insegue ogni CVE con la stessa urgenza. Mantiene un inventario attendibile, identifica gli asset critici, integra segnali di sfruttamento reale e probabilità di exploit, definisce SLA coerenti e misura il tempo che intercorre tra rilevazione e chiusura. Le eccezioni devono essere documentate e compensate, non semplicemente rinviate.

Il risultato è un processo più sostenibile: meno ticket generati soltanto da severity teorica e maggiore attenzione alle vulnerabilità che possono diventare realmente un incidente. È questo il passaggio da patch management a vulnerability management basato sul rischio.

FAQ sulle vulnerabilità informatiche

Che cosa significa vulnerabilità informatica?

È una debolezza di software, configurazione, autenticazione, permessi o architettura che può essere sfruttata per compromettere riservatezza, integrità o disponibilità di un sistema.

Quali vulnerabilità vanno corrette per prime?

In genere hanno priorità elevata le vulnerabilità note come attivamente sfruttate, presenti su asset esposti o critici e con impatto rilevante. CISA KEV, EPSS, CVSS e contesto aziendale devono essere valutati insieme.

Che cos’è il catalogo CISA KEV?

È un catalogo di vulnerabilità per le quali esistono evidenze di sfruttamento reale. È un input importante per prioritizzare la remediation nel vulnerability management.

Che cos’è EPSS?

EPSS è un modello data-driven mantenuto dalla comunità FIRST che stima la probabilità che una CVE venga sfruttata nel mondo reale nei successivi 30 giorni. Non sostituisce la valutazione del rischio dell’ambiente specifico.

Qual è la differenza tra vulnerability assessment e penetration test?

Il vulnerability assessment individua e classifica debolezze tecniche; il penetration test tenta, nel perimetro autorizzato, di verificarne la reale sfruttabilità e l’impatto. Sono attività complementari ma differenti.

Una vulnerabilità critica CVSS deve sempre essere la priorità numero uno?

No. Il CVSS misura severità tecnica, non esposizione e impatto nel tuo ambiente. Una vulnerabilità meno severa ma attivamente sfruttata su un asset Internet-facing può richiedere una remediation più urgente.