7-Zip 26.00: un file .zip qualsiasi può attivare l'heap overflow più

Il 27 aprile 2026, Igor Pavlov ha rilasciato 7-Zip 26.01 con un fix che risolve una vulnerabilità di heap buffer overflow nel parser NTFS. Il GitHub Security Lab, guidato dal ricercatore Jaroslav Lobačevski (@JarLob), aveva consegnato il report privato tre giorni prima, il 24 aprile 2026. La rapidità della risposta non deve far sottovalutare la gravità: il bug consente a un file archivio apparentemente innocuo di allocare un buffer di 1 byte e poi sovrascriverne fino a 256 MB con dati controllati dall'attaccante, con conseguente corruzione di memoria e potenziale esecuzione di codice tramite vtable hijack.

Il meccanismo: da uno shift C++ a 256 MB di corruzione controllata

La radice del bug è un'espressione di shift in C++ che entra in territorio di undefined behavior. Nella funzione CInStream::GetCuSize(), il codice calcola la dimensione del buffer di input come (UInt32)1 << (BlockSizeLog + CompressionUnit). Quando BlockSizeLog == 28 e CompressionUnit == 4, l'esponente diventa 32, ovvero pari alla larghezza del tipo UInt32. Secondo lo standard C++, uno shift di questa natura è undefined behavior: il compilatore non garantisce alcun risultato specifico.

Su architetture x86 e x64, l'hardware maschera il conteggio dello shift a 5 bit, producendo tipicamente il valore 1 invece del previsto 4.294.967.296. Questo 1 si propaga alla chiamata _inBuf.Alloc(1), che alloca esattamente un byte. La lettura successiva, tuttavia, calcola const size_t compressed = (size_t)numChunks << BlockSizeLog, dove numChunks può raggiungere valori che generano una scrittura di fino a 256 MB di dati controllati dall'attaccante nel buffer di 1 byte.

Il GitHub Security Lab ha documentato la catena di exploitabilità con precisione da manuale. In build release con ottimizzazione /O1, l'oggetto CInStream è allocato 304 byte (0x130) dopo _inBuf sul heap. La prima iterazione di Read() scrive 64 KB di dati controllati: dopo 304 byte, sovrascrive il vtable pointer dell'oggetto adiacente. La seconda iterazione di Read() effettua il dispatch attraverso il vtable corrotto, realizzando un classico vtable hijack. Questo non è un crash teorico: è un primitive di corruzione memoria concreta, con esecuzione di codice dimostrata nel contesto del report.

"A heap buffer overflow vulnerability (GHSL-2026-140) exists in 7-Zip version 26.00, caused by an under-allocation in the NTFS compressed stream buffer (`GetCuSize` shift UB), potentially allowing attackers to exploit this issue for arbitrary code execution or application crashes." — GitHub Security Lab, advisory GHSL-2026-140

L'illusione dell'estensione: perché .zip non ti protegge

La superficie di attacco supera ogni intuizione dell'utente medio, e gran parte degli amministratori di sistema, per un comportamento architetturale di 7-Zip che raramente riceve attenzione. L'handler NTFS non è attivato solo da file con estensione .ntfs o .img: il software utilizza un rilevamento basato su firma, con meccanismo di fallback quando l'handler associato all'estensione fallisce. La firma 'NTFS ' è cercata al byte offset 3.

Il risultato è che un'immagine NTFS craftata con estensione .7z, .zip, .rar, o persino senza estensione, viene aperta dall'handler NTFS dopo che l'handler iniziale rifiuta il formato. L'utente che riceve un allegato email con estensione familiare non ha, in questo caso, alcun indicatore visivo di pericolo. Il percorso di attacco richiede interazione umana (UI:R nel vettore CVSS), ma non richiede che la vittima intenzionalmente apra un file NTFS: basta un doppio clic su quello che appare essere un archivio ordinario.

Questa caratteristica amplifica il rischio operativo in modo sottovalutato. I gateway di sicurezza, le sandbox di analisi malware, le pipeline CI/CD che estraggono automaticamente archivi, e gli strumenti di endpoint management che incorporano 7-Zip come utility di decompressione possono tutti attivare il parser NTFS senza che l'estensione del file lo suggerisca. La logica di "estensione uguale parser" non è affidabile in questo caso specifico.

La discrepanza CVSS: 8.8 contro 7.8 e il significato dei contesti di attacco

I dati di scoring mostrano una divergenza che richiede esplicitazione. Il GitHub Security Lab e il National Vulnerability Database registrano un CVSS 3.1 base score di 8.8 con vettore AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, indicando attacco da rete. Amazon Linux, nell'advisory ALAS2023-2026-1820, assegna invece 7.8 con vettore AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, dove il parametro AV:L (Attack Vector: Local) riflette un contesto in cui l'attaccante deve già disporre di accesso locale al sistema target.

Entrambi i punteggi condividono la stessa severità qualitativa (High) e gli stessi impatti su confidenzialità, integrità e disponibilità. La differenza numerica non indica incertezza sul meccanismo tecnico — quello è convergente e documentato — ma piuttosto la variabilità del contesto operativo in cui il file dannoso viene consegnato e aperto. Per le organizzazioni con endpoint esposti a contenuti non attendibili da remoto (posta elettronica, download web, condivisione file), il profilo 8.8 è il riferimento più appropriato.

Cosa fare adesso

• Inventariare tutte le installazioni di 7-Zip in ambiente enterprise, con particolare attenzione alle versioni portable, ai template VM e agli strumenti forensi che incorporano binari statici: la versione 26.00 e precedenti sono vulnerabili, 26.01 risolve il bug
• Segmentare i flussi di file non attendibili: i gateway che decomprimono automaticamente allegati devono essere verificati per presenza di 7-Zip 26.00 o precedenti, indipendentemente dal tipo di file in transito
• Valutare la distribuzione della versione 26.02 (rilasciata il 25 giugno 2026) per i nuovi deployment, mantenendo 26.01 come minimo assoluto di sicurezza
• Verificare esplicitamente le build p7zip su sistemi Linux: Amazon Linux 2 ha marcato il pacchetto come "No Fix Planned", il che estende il rischio a fork e port non gestiti direttamente da Igor Pavlov

Perché questo bug è diverso dagli altri

La storia delle vulnerabilità in 7-Zip non è nuova: il dossier menziona ZDI-25-949 (CVE-2025-55188, directory traversal in ZIP) come contesto di classe di rischio storico, ma si tratta di advisory completamente distinti con meccanismi e timeline separati. Ciò che rende CVE-2026-48095 eccezionale è la convergenza di tre fattori: un primitive di corruzione memoria concreta e dimostrata, una superficie di attacco inaspettatamente ampia per via del fallback su firma, e un tempo di disclosure-to-fix di tre giorni che riflette la gravità percepita dal maintainer.

La velocità della risposta non compensa la persistenza del rischio residuo. Milioni di endpoint eseguono 7-Zip senza meccanismi di aggiornamento automatico. Le distribuzioni portable, i tool di imaging forense, le utility integrate in software di terze parti — tutti questi possono portare binari vulnerabili senza che l'amministratore ne abbia consapevolezza. Il PoC pubblico abbassa ulteriormente la soglia: non serve reverse engineering sofisticato per generare un file che attiva il crash.

L'incertezza che rimane è quantificata con precisione nel dossier. Non emergono evidenze di exploitation attiva al di là della disponibilità del PoC; CISA-ADP classifica lo stato come "poc" e l'automazione come "no". Non è documentato se le mitigazioni moderne di memoria su build Windows ufficiali (ASLR, CFG) rendano l'exploit praticamente irrealizzabile, e il dossier non specifica se il fix 26.01 risolva la logica generale dello shift UB o solo la combinazione ClusterSizeLog≥28 con CompressionUnit==4. Per le organizzazioni, questo significa che la patch è necessaria ma non sufficiente a garantire una comprensione completa del rischio: l'inventario e la segmentazione restano prioritarie.

FAQ

Devo preoccuparme se non apro mai file .ntfs o .img?

La preoccupazione è legittima indipendentemente dalle estensioni che eviti. Il parser NTFS di 7-Zip si attiva per firma, non per estensione: un file .zip, .7z o senza estensione che contiene la firma NTFS al byte offset 3 raggiungerà comunque il codice vulnerabile dopo il fallback dell'handler iniziale.

Perché Amazon Linux dà un CVSS più basso?

La differenza tra 8.8 (GitHub/NVD) e 7.8 (Amazon Linux) risiede esclusivamente nel parametro Attack Vector: Network contro Local. Entrambi indicano severità High. Il meccanismo tecnico è identico; il contesto di consegna del file dannoso cambia il profilo di rischio operativo.

7-Zip 26.01 è sufficiente o devo passare a 26.02?

La versione 26.01, rilasciata il 27 aprile 2026, contiene il fix documentato. La 26.02 del 25 giugno 2026 è la versione corrente consigliata per nuovi deployment. Se sei su 26.01, la vulnerabilità specifica di GHSL-2026-140 è risolta; il passaggio a 26.02 è raccomandabile ma non urgente per questo bug specifico.

Fonti

• https://socprime.com/it/blog/cve-2026-48095-vulnerabilita-di-overflow-del-buffer-heap-di-7-zip/
• https://www.penligent.ai/hackinglabs/cve-2026-48095/
• https://explore.alas.aws.amazon.com/CVE-2026-48095.html
• https://www.redhotcyber.com/post/7-zip-sotto-attacco-un-bug-di-heap-overflow-puo-portare-allesecuzione-di-codice-remoto/
• https://securitylab.github.com/advisories/GHSL-2026-140_7-Zip/
• https://www.zerodayinitiative.com/advisories/ZDI-25-949/?utm_source=chatgpt.com
• https://nvd.nist.gov/vuln/detail/CVE-2025-55188

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti