Patch urgenti per 7-Zip (archivi XZ) e WordPress (wp2shell). Ecco cosa aggiornare subito

🛡️ Executive Summary

• Un archivio XZ manipolato può sfruttare un heap buffer overflow in 7-Zip ed eseguire codice con i privilegi dell’utente.
• WP2Shell concatena una SQL injection e un errore nella REST API per raggiungere la RCE senza autenticazione su WordPress.
• 7-Zip 26.02, WordPress 6.9.5 e 7.0.2 contengono le correzioni; exploit pubblici e tentativi reali rendono urgente l’aggiornamento.

7-Zip e WordPress hanno corretto vulnerabilità capaci di portare all’esecuzione remota di codice, ma la disponibilità delle patch non elimina automaticamente il rischio. Nel primo caso, un archivio XZ appositamente costruito può provocare un overflow della memoria durante la decompressione. Nel secondo, la catena denominata WP2Shell combina due errori del core WordPress e può compromettere un’installazione predefinita senza credenziali o plugin vulnerabili. Gli exploit pubblici e i primi tentativi di sfruttamento riducono la finestra disponibile per intervenire. Utenti, amministratori e organizzazioni devono aggiornare i programmi, verificare le versioni realmente distribuite e cercare eventuali tracce di compromissione già avvenuta.

7-Zip esegue codice durante l’apertura di archivi XZ malevoli

La vulnerabilità di 7-Zip risiede nel codice utilizzato per elaborare dati compressi nel formato XZ. Un archivio manipolato può indurre il decoder a scrivere oltre i limiti del buffer di output allocato nell’heap, corrompendo la memoria del processo. Se l’attaccante controlla con precisione il contenuto e la struttura dei dati, la corruzione può essere trasformata in esecuzione di codice arbitrario. L’attacco richiede normalmente che la vittima scarichi e apra l’archivio, condizione facilmente ottenibile attraverso phishing, falsi documenti, pacchetti software contraffatti o file presentati come materiale professionale. Il codice viene eseguito con i privilegi dell’utente che utilizza 7-Zip: su una workstation aziendale può quindi leggere documenti, installare malware, sottrarre credenziali o sfruttare una seconda falla per elevare i privilegi. Il rischio è amplificato dalla diffusione del programma e dal fatto che gli archivi compressi vengono trattati quotidianamente come contenitori ordinari. Matrice Digitale aveva già documentato una precedente esposizione critica del software nell’approfondimento sulla CVE-2026-48095 di 7-Zip e il rischio di esecuzione remota, confermando come i parser dei formati compressi rimangano una superficie d’attacco ad alto rendimento.

La versione 26.02 introduce i controlli mancanti sul buffer

La falla è stata individuata dal ricercatore Landon Peng di Lunbun e corretta in 7-Zip 26.02. La nuova versione impedisce al decoder di superare lo spazio effettivamente disponibile nel buffer di destinazione, bloccando la condizione che permetteva la corruzione dell’heap. L’aggiornamento deve essere installato manualmente perché la distribuzione standard di 7-Zip non dispone di un sistema integrato capace di aggiornare automaticamente tutte le installazioni. Questa caratteristica crea un problema soprattutto nelle organizzazioni: copie del programma possono essere presenti su workstation, server amministrativi, immagini virtuali, strumenti portabili e directory utilizzate da script senza comparire sempre negli inventari software tradizionali. I responsabili IT devono cercare gli eseguibili distribuiti, controllarne la versione e sostituire anche le copie non installate attraverso un normale pacchetto MSI. Fino al completamento dell’aggiornamento, gli archivi XZ provenienti da fonti esterne devono essere trattati come contenuto potenzialmente eseguibile e aperti soltanto in ambienti isolati. Filtri email e sandbox possono ridurre l’esposizione, ma un archivio progettato per sfruttare il decoder potrebbe superare analisi che non utilizzano la stessa versione vulnerabile del programma.

WP2Shell colpisce direttamente il core di WordPress

La seconda emergenza interessa WordPress, senza dipendere da plugin o temi di terze parti. WP2Shell concatena CVE-2026-60137, un’iniezione SQL nel parametro author__not_in di WP_Query, e CVE-2026-63030, una confusione nella gestione delle richieste batch della REST API. Il primo problema si verifica perché un parametro previsto come array può ricevere una stringa appositamente costruita e introdurla nella query generata dal CMS. Il secondo deriva da un disallineamento interno quando una sotto-richiesta del batch produce un errore, alterando l’associazione tra richieste, risposte e controlli applicati. Utilizzate insieme, le due falle consentono a un attaccante non autenticato di superare i confini previsti dal sistema e raggiungere l’esecuzione di codice sul server. La rilevanza della catena sta proprio nell’assenza di prerequisiti applicativi particolari: un sito WordPress essenziale può risultare vulnerabile anche senza componenti aggiuntivi. È un cambio di prospettiva rispetto alle campagne che normalmente colpiscono l’ecosistema attraverso estensioni obsolete, come quella analizzata nell’articolo su WordPress, Joomla e la distribuzione globale di webshell.

Gli exploit pubblici accelerano il passaggio dalla ricerca agli attacchi

Il codice proof-of-concept disponibile pubblicamente mostra diverse modalità di abuso della catena. Alcune implementazioni estraggono hash delle password dal database, tentano il cracking delle credenziali amministrative, caricano plugin malevoli o eseguono comandi sul sistema operativo. La pubblicazione non significa che ogni script sia affidabile o immediatamente applicabile a tutte le configurazioni, ma riduce drasticamente il lavoro necessario agli attaccanti per costruire scanner e payload automatizzati. Dopo la disclosure sono stati osservati tentativi di sfruttamento in ambienti reali, elemento che rende insufficiente programmare l’intervento nel normale ciclo mensile di manutenzione. Una volta ottenuta la RCE, l’aggressore può installare webshell, creare amministratori nascosti, modificare i file PHP, inserire redirect, sottrarre il database o utilizzare il server come punto di partenza per phishing e distribuzione di malware. Le recenti operazioni riunite sotto il nome WP-SHELLSTORM hanno mostrato quanto velocemente le vulnerabilità WordPress vengano trasformate in campagne operative. L’aggiornamento deve quindi essere accompagnato da verifiche forensi, soprattutto sui siti esposti durante la finestra precedente alla patch.

WordPress 6.9.5 e 7.0.2 chiudono la catena completa

Le versioni interessate dalla catena completa comprendono WordPress da 6.9.0 a 6.9.4 e da 7.0.0 a 7.0.1. Le correzioni sono state distribuite con WordPress 6.9.5 e 7.0.2, mentre il team del progetto ha attivato gli aggiornamenti automatici di sicurezza per i rami vulnerabili. Gli amministratori non devono però presumere che l’installazione sia avvenuta correttamente. Aggiornamenti disabilitati, permessi errati, spazio insufficiente, modifiche al core e sistemi di deployment personalizzati possono lasciare il sito sulla versione precedente. Occorre controllare direttamente la release in uso, verificare l’integrità dei file e riesaminare plugin o strumenti che potrebbero aver modificato il comportamento della REST API. L’SQL injection interessa anche il ramo 6.8 precedente alla catena completa e deve essere corretta con la release di sicurezza disponibile per quella linea. Il principio operativo resta semplice: ogni installazione supportata deve raggiungere l’ultima versione corretta del proprio ramo oppure essere aggiornata al ramo stabile più recente.

Le mitigazioni WAF riducono il rischio ma non sostituiscono la patch

Quando l’aggiornamento non può essere applicato immediatamente, è possibile bloccare l’accesso anonimo alle route batch della REST API, comprese /wp-json/batch/v1 e la variante basata su ?rest_route=/batch/v1. La restrizione può essere applicata attraverso il web server, un firewall applicativo o un plugin temporaneo progettato per impedire richieste non autenticate. Cloudflare ha distribuito regole WAF relative alle due vulnerabilità sui propri piani, offrendo una barriera aggiuntiva ai siti protetti dal servizio. Queste contromisure dipendono però dalla corretta interpretazione della richiesta e possono essere aggirate da varianti, percorsi alternativi o configurazioni che espongono direttamente il server di origine. Inoltre, bloccare completamente la REST API può interferire con editor, applicazioni mobili, integrazioni e plugin legittimi. La mitigazione deve quindi essere circoscritta alle route vulnerabili e accompagnata da test funzionali. Soltanto la patch elimina il difetto nel codice che genera la condizione di sfruttamento.

I log devono essere analizzati anche dopo l’aggiornamento

L’installazione delle nuove versioni impedisce ulteriori tentativi noti, ma non rimuove automaticamente una compromissione già avvenuta. Per WordPress occorre cercare richieste insolite verso le route batch, parametri author__not_in anomali, errori SQL, creazione di account amministrativi, caricamento di plugin non autorizzati e modifiche recenti ai file in wp-content, wp-admin e wp-includes. Devono essere controllati anche wp-config.php, attività pianificate, chiavi API, utenti del database e processi avviati dal web server. In caso di indicatori sospetti, la rotazione delle credenziali deve comprendere amministratori WordPress, database, pannello hosting, SFTP, SSH e secret keys del CMS. Per 7-Zip, la ricerca deve concentrarsi sull’apertura recente di archivi XZ provenienti da email o download esterni e sui processi figli generati dall’eseguibile subito dopo l’estrazione. Una correlazione tra 7z.exe, PowerShell, interpreti di script o connessioni di rete anomale richiede un’indagine approfondita.

Due falle differenti espongono lo stesso problema di fiducia nei dati

Le vulnerabilità colpiscono prodotti e scenari molto diversi, ma condividono un principio tecnico: dati controllati dall’esterno vengono elaborati con assunzioni non sufficientemente verificate. 7-Zip si fida delle dimensioni e della struttura dei dati compressi fino a corrompere il buffer; WordPress interpreta parametri e richieste batch in modo incompatibile con i controlli di sicurezza attesi. Nel primo caso serve l’apertura di un archivio, nel secondo basta raggiungere un endpoint web vulnerabile. Entrambi possono però concludersi con l’esecuzione di codice e la perdita del sistema interessato. L’urgenza non deve tradursi in un aggiornamento disordinato, ma in una procedura verificabile: inventario delle installazioni, distribuzione delle patch, controllo delle versioni, analisi dei log e ricerca di indicatori retrospettivi. Con exploit già disponibili, il tempo trascorso tra la pubblicazione della correzione e l’applicazione effettiva diventa parte integrante del rischio.