Home › Blog › Vulnerabilità ed exploit: la differenza spiegata semplice

Vulnerabilità ed exploit: la differenza spiegata semplice

La differenza è semplice: la vulnerabilità è una debolezza presente in un software, in un sistema o in un processo, mentre l'exploit è il codice o la tecnica che sfrutta quella debolezza per ottenere un risultato non autorizzato. Capire come si distinguono vulnerabilità ed exploit aiuta a ragionare sul rischio in modo concreto: la falla da sola è un'opportunità, l'exploit la trasforma in un attacco possibile.

Vulnerabilità ed exploit: le definizioni in breve

Cos'è una vulnerabilità

Una vulnerabilità è un difetto che permette di aggirare le protezioni previste. Può nascere da un errore di programmazione, da una configurazione sbagliata, da una password predefinita mai cambiata o da un componente obsoleto.

Esiste anche se nessuno l'ha notata. Una falla può restare nascosta per anni in un'applicazione e non causare alcun danno finché qualcuno non la scopre.

Cos'è un exploit

Un exploit è lo strumento che mette in pratica lo sfruttamento: può essere uno script, un programma, una sequenza di richieste costruite ad arte o una tecnica manuale. Senza una vulnerabilità da colpire, un exploit non ha nulla su cui funzionare.

Se vuoi capire nel dettaglio come è fatto e come agisce, trovi un approfondimento in come funziona un exploit informatico.

Qual è la differenza tra vulnerabilità ed exploit?

Il modo più utile per ricordarla è questo: la vulnerabilità è la condizione, l'exploit è l'azione. Una finestra lasciata socchiusa è la vulnerabilità; il piede di porco che serve a forzarla è l'exploit; l'ingresso in casa è l'attacco.

Ne deriva una conseguenza pratica: puoi avere molte vulnerabilità senza subire attacchi, ma ogni attacco riuscito di questo tipo parte sempre da una vulnerabilità. Per questo conta ridurre le falle, non solo reagire agli exploit.

Un esempio concreto nel codice PHP

Immagina una pagina PHP che cerca un prodotto in base a un parametro dell'URL e lo inserisce direttamente nella query al database, senza controlli. Quella è la vulnerabilità: l'applicazione tratta input non fidato come se fosse codice SQL.

L'exploit è la richiesta costruita per manipolare la query, per esempio per leggere dati che non dovrebbero essere visibili. L'attacco è l'uso di quella richiesta contro un sito reale, con il furto o la modifica di informazioni come possibile risultato.

La correzione sta nella causa, non nel sintomo: query parametrizzate (per esempio con PDO e prepared statement), validazione dell'input e account di database con privilegi minimi. Lo stesso schema vale per altri problemi, come il cross site scripting o il buffer overflow.

Capita spesso anche che la falla non sia nel tuo codice ma in un plugin, in un tema o in una libreria di terze parti. In questi casi la tua responsabilità è sapere cosa stai usando e tenerlo aggiornato.

Come leggere CVE e CVSS

Quando una vulnerabilità viene resa pubblica, spesso riceve un identificatore CVE (Common Vulnerabilities and Exposures), con formato del tipo CVE-anno-numero. Serve a far parlare tutti della stessa falla: produttori, scanner, bollettini di sicurezza e team IT.

Accanto al CVE si trova di solito un punteggio CVSS, che va da 0 a 10 e indica la gravità tecnica: più è alto, più la falla è seria. Le fasce usate comunemente sono bassa, media, alta e critica.

Cosa il CVSS non ti dice

Il punteggio descrive la vulnerabilità, non il tuo rischio reale. Non ti dice se esiste un exploit funzionante, se il sistema è raggiungibile da Internet o quanto sia importante per la tua attività.

Per questo, nella scelta delle priorità conviene incrociare il CVSS con altre informazioni:

• Exploit disponibile: esiste una dimostrazione pubblica o uno sfruttamento già osservato? Il catalogo KEV della statunitense CISA elenca le vulnerabilità note come attivamente sfruttate.
• Esposizione: il sistema è visibile da Internet o solo dalla rete interna?
• Criticità del bene: quali dati e quali processi dipendono da quel sistema?
• Controlli compensativi: ci sono segmentazione, filtri o autenticazione forte che riducono l'impatto?

Dalla vulnerabilità all'attacco: perché il tempo conta

Tra la scoperta di una falla e la comparsa di un exploit può passare molto tempo o pochissimo. Quando la correzione è già disponibile ma non è stata installata, chi attacca ha un vantaggio: sa che esistono sistemi non aggiornati.

Questo schema è alla base di molti attacchi ransomware: i criminali cercano sistemi con falle note, entrano, aumentano i privilegi e poi cifrano i dati. Un caso noto è WannaCry, che nel 2017 sfruttò una vulnerabilità di Windows per cui una correzione era già stata rilasciata.

Un caso diverso è lo zero day, in cui l'exploit compare prima che esista una patch. Qui la difesa passa soprattutto da monitoraggio, segmentazione e riduzione della superficie esposta.

Non tutto parte dal codice: anche il social engineering sfrutta "vulnerabilità" umane, come la fretta o la fiducia, con tecniche che non richiedono alcun exploit software.

Dispositivi IoT: cosa succede quando finisce il supporto

Telecamere, router, stampanti e sensori sono un buon esempio. Quando il produttore smette di supportare un dispositivo, non rilascia più aggiornamenti: le nuove vulnerabilità scoperte restano aperte, mentre gli exploit possono circolare.

Le conseguenze non sono "nessuna", come a volte si pensa. Il dispositivo spesso continua a funzionare normalmente, ed è proprio questo il problema: nessun segnale evidente avverte che il rischio sta crescendo.

Gli aggiornamenti sono fondamentali perché chiudono vulnerabilità di sicurezza note e quindi riducono gli attacchi possibili. Possono migliorare anche stabilità e prestazioni, ma non sono il motivo principale per cui vanno installati. Per un quadro più ampio, leggi la guida su vulnerabilità IoT e attacchi ai dispositivi connessi.

Cosa fare in pratica per ridurre il rischio

Non puoi eliminare ogni falla, ma puoi ridurre il tempo in cui restano aperte. Un percorso realistico è questo:

1. Fai un inventario di server, applicazioni, plugin, librerie e dispositivi connessi: non si corregge ciò che non si conosce.
2. Cerca le vulnerabilità con scansioni periodiche e, per le applicazioni PHP, con revisione del codice e test mirati.
3. Assegna le priorità usando CVSS, esistenza di exploit, esposizione e criticità del sistema.
4. Correggi con metodo: definisci tempi e responsabilità, come descritto nella guida al patch management.
5. Isola ciò che non puoi aggiornare, per esempio i dispositivi fuori supporto, in reti separate e con accessi minimi.
6. Verifica che funzioni: un test di sicurezza controlla se una falla è davvero sfruttabile, e questo distingue il rischio teorico da quello concreto.

Per un'azienda di Milano con più sedi, fornitori e sistemi esposti, questa distinzione cambia il modo di spendere tempo e budget: meglio correggere subito la falla con exploit attivo che inseguire decine di avvisi poco rilevanti.

Conclusione

Ricordare la differenza tra falla ed exploit aiuta a decidere meglio: la vulnerabilità si trova e si corregge, l'exploit mostra quanto sia urgente farlo. Se vuoi capire quali debolezze sono realmente sfruttabili nella tua infrastruttura, puoi approfondire come funziona il penetration test automatizzato di FRED e valutare con il team di Fred for Security un percorso adatto alla tua azienda.

Domande frequenti