7-Zip CVE-2026-48095: il parser NTFS apre la strada al vtable hijacking

7-Zip 26.00: heap overflow NTFS con hijack vtable, fix disponibile

Il 22 maggio 2026 il GitHub Security Lab ha reso pubblica l'advisory GHSL-2026-140 su una vulnerabilità critica nel gestore NTFS di 7-Zip. Il ricercatore Jaroslav Lobačevski ha dimostrato come un errore di shift a 32 bit in C++ produca un under-allocation di un singolo byte su heap, aprendo la strada a un vtable hijack con esecuzione di codice arbitrario. La versione vulnerabile è la 26.00 e tutte le precedenti con supporto stream NTFS compressi; il fix è disponibile dalla 26.01 del 27 aprile 2026. La disclosure pubblica arriva quasi un mese dopo il rilascio della patch, lasciando una finestra di esposizione misurabile per chi non aggiorna automaticamente.

Il bug: quando 1 << 32 fa 1, non 4 miliardi

Il difetto risiede in NtfsHandler.cpp:687, nella funzione CInStream::GetCuSize(). Il codice calcola la dimensione del buffer con (UInt32)1 << (BlockSizeLog + CompressionUnit). Quando il parser NTFS accetta un boot sector con ClusterSizeLog >= 28 e un attributo compresso con CompressionUnit == 4, l'esponente diventa 32. In C++, (UInt32)1 << 32 è undefined behavior: su x86 il processore maschera a 5 bit producendo 1 << 0 = 1; su x64 lo stesso risultato colpisce _inBuf indipendentemente dal fatto che _outBuf tenti un'allocazione di 8 GB.

L'UBSan riportato nell'advisory è inequivocabile: "shift exponent 32 is too large for 32-bit type 'UInt32'". Il buffer _inBuf viene allocato come 1 byte. Poi ReadStream_FALSE scrive fino a 256 MB di dati controllati dall'attaccante — (size_t)numChunks << BlockSizeLog — in quel singolo byte, travolgendo tutto l'heap adiacente.

Dalla sovrascrittura heap al controllo dell'esecuzione

L'analisi con debugger nell'advisory mostra la geometria precisa dell'overflow. L'oggetto CInStream occupa 304 byte (0x130) ed è allocato immediatamente dopo _inBuf. La prima chiamata a Read() scrive 64 KB (kBlockSize) di dati craftati: dopo 304 byte sovrascrive il vtable pointer dell'oggetto stream. La seconda chiamata a Read() — quando il codice tenta di dispatchare attraverso il vtable — esegue l'indirizzo scelto dall'attaccante.

Il ricercatore ha denominato tecnicamente il meccanismo vtable hijack e lo ha documentato passo-passo: non è un crash casuale, ma una catena deterministica. Su sistemi x64 con almeno 16 GB di RAM, l'allocazione di 8 GB per _outBuf può riuscire, ma la vulnerabilità resta in _inBuf. Su sistemi con RAM insufficiente, il fallimento allocazione 8 GB genera eccezione — comportamento diverso, non mitigazione.

Il "file format chameleon": perché l'estensione non protegge

Il meccanismo di registrazione handler in 7-Zip, REGISTER_ARC_I a riga 2889 di NtfsHandler.cpp, configura il gestore NTFS per attivazione signature-based con firma NTFS a offset 3. Se l'utente rinomina un'immagine craftata come fattura.zip, backup.7z o documento.rar, il parser per estensione rifiuta inizialmente il file; poi il meccanismo di fallback per firma identifica NTFS e passa il file al gestore vulnerabile.

Questo comportamento ha conseguenze immediate per le pipeline di sicurezza automatiche. Sandbox, EDR, antivirus e servizi cloud di scanning che instradano i file per estensione — o che usano l'estensione come proxy di tipo MIME — processeranno il file nel parser sbagliato. L'attaccante non deve convincere la vittima a rinominare manualmente: qualsiasi upload, allegato email, o archivio scaricato con estensione comune scatena il percorso vulnerabile.

"A heap buffer overflow vulnerability exists in the NTFS archive handler in 7-Zip that can lead to code execution via vtable hijack" — GitHub Security Lab, advisory GHSL-2026-140

Cosa fare adesso

1. Aggiornare immediatamente a 7-Zip 26.01, rilasciato il 27 aprile 2026. Verificare la versione attuale tramite Help > About; i gestori pacchetti (winget, Chocolatey, apt) potrebbero avere lag di distribuzione non quantificato nell'advisory
2. Disabilitare l'apertura automatica di archivi estratti e configurare 7-Zip per estrazione in cartella temporanea isolata, riducendo la superficie di trigger accidentale
3. Rivisionare le pipeline di processing file aziendali: sandbox, gateway email, servizi cloud di antimalware che si affidano all'estensione per il routing devono essere testati contro file con firma NTFS e estensione falsa
4. Abilitare ASLR e Control Flow Guard su Windows dove applicabile; sebbene il vtable hijack sia dimostrato nell'advisory, queste mitigazioni aumentano la complessità dell'exploitation senza eliminare il rischio

Tempi di reazione e finestre di esposizione

La timeline nell'advisory mostra un intervallo di tre giorni tra report privato (24 aprile) e fix (27 aprile), tempo tecnicamente rapido. La disclosure pubblica del 22 maggio 2026, tuttavia, crea un'aritmetica di rischio diversa: chi ha aggiornato entro fine aprile è protetto; chi è rimasto sulla 26.00 — o su versioni precedenti — ha navigato quasi quattro settimane con patch disponibile ma non applicata. L'assenza di dati su exploit in-the-wild nel brief non equivale a assenza di rischio; la disponibilità del PoC Python completo abbassa la barriera tecnica per chi volesse sviluppare un exploit funzionale.

Il ricercatore Jaroslav Lobačevski, attivo nel GitHub Security Lab con handle @JarLob, ha costruito un proof-of-concept che genera immagini NTFS sparse: 512 MB apparenti, circa 8 KB su disco, boot sector e MFT records craftati manualmente. L'output poc_ntfs_sparse.ntfs è funzionante e verificato con UBSan e debugger, non un concetto teorico.

Perché il filtro estensione è una difesa incompleta

La lezione tecnica va oltre 7-Zip. L'incidente dimostra come il paradigma "blocca per estensione" — ancora radicato in gateway, DLP e sandbox — fallisca quando un formato contiene firma interna rilevabile indipendentemente dal contenitore. Il parser NTFS di 7-Zip non è il primo né sarà l'ultimo a implementare fallback signature-based, ma la combinazione di under-allocation deterministica, overflow controllato e hijack dell'esecuzione ne fa un caso limite per la progettazione di difese in profondità.

Per gli operatori di sicurezza, la priorità non è solo il patching ma la verifica del routing file nelle proprie pipeline: se un sistema decide "questo è .zip, uso il parser zip" senza considerare il fallback per firma, ha un cieco strutturale. La risposta non è rinunciare ai formati compressi, ma riconoscere che l'estensione è metadato, non identità.

Le informazioni sono basate sull'advisory citata e aggiornate al momento della pubblicazione.

Fonti

• https://securitylab.github.com/advisories/GHSL-2026-140_7-Zip/
• https://sourceforge.net/p/sevenzip/discussion/45797/thread/555e132ba4/
• https://sourceforge.net/p/sevenzip/discussion/45797/thread/a1f7e08417/
• https://github.com/JarLob

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

Fonti