Il bug che non muore mai: perché il Buffer Overflow è ancora ovunque nel 2026

Il buffer overflow è ancora oggi una vulnerabilità nella sicurezza informatica che permette agli attaccanti di accedere a sistemi e dati sensibili. Soprattutto all'interno dei software legacy/EoL possono stratificarsi vulnerabilità che possono portare a questo pericoloso bug di sicurezza che spesso cela Remote Code Execution (RCE) o Code Injection.

E’ da tempo che faccio questo mestiere e in tutte le reti che visito per delle analisi di sicurezza , trovo problemi simili. Un server dimenticato, una serie di programmi che nessuno elimina per pigrizia e una versione di Windows obsoleta dai tempi di Internet Explorer.

Tutto è utile, ma mai come un exploit che sfrutta un buffer overflow.

A febbraio 2025, FBI e CISA hanno evidenziato in modo diretto quanto questa minaccia sia ancora attuale come in molti pensano. Dobbiamo sottolineare che se il codice non è in grado di controllare i limiti della memoria, la responsabilità purtroppo è da attribuire allo sviluppatore.

L’invio di una quantità di dati superiore a quella gestibile dal programma, spesso provoca un buffer overflow, che consente la sovrascrittura dell’indirizzo di ritorno memorizzato nello stack. Quando la funzione termina, l’indirizzo viene caricato nel registro EIP (o RIP nei sistemi a 64 bit), permettendo all’attaccante di reindirizzare il flusso verso un indirizzo scelto e ottenere il controllo del programma.

È chiaro che il controllo della macchina sia ormai preso. Le difese moderne, come ASLR, rendono questi attacchi più difficili, ma non li eliminano del tutto e in questo articolo ne parliamo approfonditamente.

Ma nonostante tutto perché dopo decenni esiste ancora?

Ebbene, la risposta è più semplice di quello che sembra. Nella maggioranza dei casi, il software viene scritto in C o in C++ che sono da un lato linguaggi potenti, efficienti, ma dall’altro sono sprovvisti di protezioni native per gli errori di gestione della memoria.

Col passare del tempo, i membri del team cambiano, un po’ per pigrizia e un po’ per la complessità del software e lo sforzo necessario per mantenerlo aggiornato, molte applicazioni finiscono lentamente per essere lasciate a se stesse.

Se persino Google e Microsoft, analizzando le proprie codebase, hanno scoperto che circa il 70% delle vulnerabilità deriva da problemi di gestione della memoria, non serve scomodare altre aziende per capire quanto sia difficile affrontare questo specifico problema.

Sulla carta, tutti vorrebbero software sicuri, ma nella pratica vuol dire riscrivere milioni di righe di codice legacy che non è affatto qualcosa che si fa in qualche settimana. È un lavoro enorme, costoso e che spesso richiede anni. Si potrebbe velocizzare con le AI? Certo, ma il collaudo che ne deriva è un prezzo da pagare importante.

Basta guardare cosa succede in molte PMI italiane. Nel tentativo di risparmiare, non è raro ritrovarsi con un gestionale del 2009, sviluppato da un fornitore che nel frattempo ha chiuso, cambiato attività o semplicemente non risponde più al telefono.

Lo stesso vale per molti ambienti industriali. Ci sono ancora impianti SCADA che girano su vecchie versioni di Windows Embedded e che nessuno osa più toccare. Aggiornare questi sistemi significa in molti casi fermare la produzione, con costi e rischi che l’azienda spesso non è disposta ad accettare oltre ai rischi di sicurezza nazionale.

Queste non sono situazioni eccezionali o casi limite. Sono spesso scenari che emergono durante le attività sul campo e purtroppo. chi lavora in questo settore li incontra continuamente.

Quando il problema diventa reale:

L’alert FBI-CISA del 2025 non riguardavava solo i software marginali o usati saltuariamente, ma strumenti di uso quotidiano: prodotti presenti in quasi tutte le organizzazioni, comprese piccole e grandi aziende, spesso senza che ci si renda conto del rischio che possono rappresentare.

Il CVE-2025-0282 su Ivanti Connect Secure: stack-based buffer overflow, CVSS 9.0, da remoto e senza autenticazione. Ivanti Connect Secure è il portone d’ingresso e la VPN enterprise per migliaia di organizzazioni è il varco obbligato dei dipendenti. Chi sfrutta questo bug entra nella rete senza credenziali, spesso senza lasciar traccia nei log.

Il CVE-2024-38812 su VMware vCenter Server: heap-based buffer overflow, CVSS 9.8. Un pacchetto di rete malformato che ci rende amministratore del server che comanda tutta l’infrastruttura virtuale. E chi controlla vCenter e le macchine virtuali, controlla tutta l’azienda.

E il CVE-2025-43300 su Apple iOS e iPadOS è quello che mi ha fatto pensare di più. Out-of-bounds write in ImageIO, il componente che si occupa d’immagini. Apple conferma exploitation attiva in attacchi di straordinaria sofisticatezza contro individui specifici — l’espressione, da parte di Apple, è già conclamata: dietro quella frase c’è quasi certamente uno stato o un suo contractor. Memory corruption su un iPhone, dimostrando quanto questi attacchi siano ancora reali e pericolosi al giorno d’oggi.

Come affrontare il problema e quali precauzioni adottare:

FBI e CISA, oltre alla diagnosi, danno anche molti consigli per evitare che possano accadere spiacevoli inconvenienti. Prima di tutto è buona prassi pensare a come difendersi. Sembra una banalità, eppure è proprio qui che moltissime organizzazioni inciampano. Tante aziende non dispongono nemmeno di un inventario aggiornato del software che hanno in produzione (e quì andiamo sul primo requisito del NIST Cybersecurity framework, ovvero l’occhio buono), figuriamoci di una valutazione concreta dei rischi legati alle vulnerabilità di memoria.

Se non sai cosa gira nei tuoi sistemi, come puoi pensare di proteggerti?

Chi attacca parte già avvantaggiato: trova componenti dimenticati, software mai censiti, versioni in EoL che nessuno controlla più. E quando la porta è già socchiusa, non serve nemmeno più forzarla, basta poco per entrare.

Pressione sui fornitori. Le agenzie statunitensi stanno esortando a richiedere ai propri fornitori un Software Bill of Materials — ovvero un elenco degli elementi costitutivi del software — insieme a garanzie formali riguardo alle prassi di sviluppo sicuro. In Europa, il Cyber Resilience Act segue una traiettoria simile. È entrato in vigore a partire da dicembre 2024, con i primi obblighi operativi da settembre 2026, prevedendo sanzioni che possono giungere fino a 15 milioni di euro o rappresentare il 2,5% del fatturato globale per coloro che non rispettano i requisiti lungo l’intero ciclo di vita del prodotto. Quello che fino a pochi anni fa era considerato semplicemente una buona pratica sta rapidamente diventando un obbligo di legge.

Transizione verso linguaggi più sicuri dal punto di vista della gestione della memoria. In questo contesto il nome che emerge più spesso è Rust, e non a caso. Il linguaggio sta trovando sempre più spazio nel kernel Linux e in diversi componenti di Windows proprio perché aiuta a prevenire un’intera categoria di vulnerabilità legate alla memoria. Non si tratta di riscrivere tutto da zero.

Osservazione Costante

Dal punto di vista di chi fa penetration testing, sfruttare un buffer overflow su software datato non è il vettore più raffinato che esista, anche se la ricerca di questo genere di bug risulta molto più complicata. Basta trovare software vecchio, non aggiornato, accessibile dall’esterno e con un semplice exploit sei dentro. Ed in molte aziende nel 2026 è più comune di quanto sembra.

Un firewall non può agire su un servizio con un overflow non patchato. Un EDR non monitora un componente che non sta in nessun inventory. Purtroppo oltre alla consapevolezza, gli strumenti servono, anche se non fanno miracoli: bisogna sempre proteggersi prima di affidarsi a qualcun altro.

Il messaggio di febbraio 2025 possiamo dirlo, non si trattava di una comunicazione tecnica per gli specialisti della sicurezza ma un avvertimento rivolto ai responsabili aziendali. Se la sicurezza viene trascurata per pigrizia oppure per risparmiare sui costi, state tranquilli che qualcuno vi presenterà il conto più avanti, e spesso questo conto è tanto salato.

Canio Campaniello

Penetration tester e fondatore di HackIta.it, blog italiano di riferimento per l'offensive security. Specializzato in Active Directory attack path, exploit development e web application security. Ha completato lab avanzati HackTheBox tra cui Offshore, Zephyr e RastaLabs. Attualmente in percorso verso la certificazione OSCE3.

Aree di competenza: Penetration Testing, Active Directory Security, Exploit Development, Web Application Security, Ethical Hacking