Grave vulnerabilità in libheif consente alle immagini HEIC di eseguire codice sui server
Il 1° settembre 2026, il progetto libheif ha rilasciato la versione 1.23.3 per correggere un grave overflow del buffer heap nella diffusa libreria di immagini. La falla è stata scoperta e segnalata quattro giorni prima dal team Wordfence Threat Intelligence utilizzando Wordfence Argus, e il manutentore di libheif Dirk Farin l'ha valutata 9,8 su 10 sulla scala CVSS. In parole povere, un'immagine HEIC appositamente creata può scrivere byte controllati dall'attaccante oltre la fine di un buffer di memoria, e su un server vulnerabile ciò può portare alla lettura di file protetti dal worker di elaborazione delle immagini o all'esecuzione di codice con i suoi permessi. Le versioni interessate sono dalla 1.18.0 alla 1.23.2 quando la libreria è compilata con il codec non compresso abilitato, e la correzione è nella 1.23.3; la 1.23.4 è l'attuale release di sicurezza upstream. Questa non è una vulnerabilità solo di WordPress.
Per capire perché questo è importante per un sito WordPress, è utile sapere cosa fa effettivamente libheif. I possessori di iPhone creano file HEIC da quando iOS 11 lo ha reso il formato foto predefinito nel 2017, perché HEIC memorizza un'immagine di qualità migliore in circa la metà dello spazio di un JPEG. HEIC è un formato contenitore, essenzialmente una scatola con una lista di imballaggio che descrive cosa c'è dentro e come è stato codificato. Quasi nessuno scrive il proprio codice per aprirlo; la maggior parte dei sistemi Linux si affida a libheif. WordPress stesso non decodifica le immagini. Quando un utente carica una foto, WordPress passa il file a un editor di immagini per creare le miniature ed estrarre i metadati. Sui server interessati, l'estensione PHP Imagick chiama ImageMagick, che riconosce HEIF e passa il file a libheif. Ciò significa che una libreria C++ si trova dentro il worker PHP di elaborazione delle immagini, analizzando byte arrivati da Internet con i permessi di quel worker. La stessa libreria è anche sotto visualizzatori di immagini desktop, gallerie fotografiche, server multimediali self-hosted e generatori di miniature, quindi qualsiasi software che apre file HEIC da altre persone è potenzialmente esposto.
Un proprietario di sito dovrebbe preoccuparsi? Un punteggio CVSS di 9,8 è vicino al massimo e indica che quando un'applicazione espone questa libreria a immagini non fidate sulla rete senza richiedere un login, il risultato peggiore è una compromissione completa del server. Non significa che ogni sito WordPress permetta agli estranei di caricare file HEIC. La dimostrazione di Wordfence contro un'installazione WordPress pulita ha utilizzato un normale account Author, che è il primo ruolo autorizzato a caricare media in un sito WordPress standard. I sistemi moderni rendono anche più difficili da sfruttare i bug di corruzione della memoria: ASLR mescola dove finiscono codice e dati in memoria, e RELRO rende alcune tabelle interne di sola lettura. Tuttavia, Wordfence ha dimostrato che il bug può andare oltre. Su una specifica configurazione WordPress con Debian e glibc, un file HEIC creato ad hoc ha permesso ai ricercatori di leggere un file protetto ed eseguire codice. Un test più ristretto che copiava un'immagine caricata in un'altra posizione ha funzionato in 29 tentativi su 30 contro un server Apache già in esecuzione e che riutilizzava i processi worker. Questa è una forte evidenza di impatto reale ma non un exploit universale; il payload dipende dall'esatta build di libheif, da come il server gestisce la memoria e dalle richieste che raggiungono un worker con lo stato giusto. Un attaccante potrebbe aver bisogno di un file diverso per un ambiente diverso. Se centinaia o migliaia di siti usano la stessa immagine di hosting, tuttavia, il lavoro fatto per uno può essere trasferito agli altri. I bersagli di alto valore e le flotte di hosting costruite da un'immagine condivisa meritano particolare attenzione.
La scoperta non dovrebbe essere liquidata solo perché un exploit deve essere adattato. HEIF Heist, ricerca di Hacktron che ha trasformato diverse altre vulnerabilità di libheif in attacchi funzionanti contro servizi reali di elaborazione delle immagini, mostra quanto rapidamente possa avvenire l'adattamento. Discourse ha confermato l'esecuzione di codice attraverso un upload di immagine compromessa, e Vercel ha confermato l'esecuzione di codice non autenticata quando applicazioni Next.js interessate elaboravano un'immagine AVIF creata ad hoc. La scoperta di Wordfence Argus è un bug più recente, separato, con una causa radice diversa ed è stato corretto successivamente; libheif 1.23.2 ha risolto due vulnerabilità critiche presenti in HEIF Heist, ma questa è rimasta fino alla 1.23.3. Hacktron afferma che adattare i suoi exploit a un nuovo bersaglio richiedeva generalmente circa uno o due giorni. In altre parole, "deve essere adattato" è un rallentamento piuttosto che un controllo di sicurezza, e l'applicazione delle patch dovrebbe essere la priorità per qualsiasi applicazione che accetti file HEIC o HEIF da persone di cui non ti fidi.
Per i siti WordPress in particolare, il percorso di elaborazione delle immagini usuale è esposto solo se tutte queste condizioni sono vere contemporaneamente: il server ha l'estensione PHP Imagick, perché l'altro editor di immagini di WordPress non può leggere affatto HEIC; l'installazione di ImageMagick è stata pacchettizzata con il supporto HEIF; la versione di libheif è tra 1.18.0 e 1.23.2; e quel libheif è stato compilato con il codec non compresso abilitato. Quest'ultima condizione significa che il solo numero di versione non può dirti se sei vulnerabile. Wordfence ha testato nove configurazioni reali il 5 settembre chiedendo a ciascuna di decodificare un file HEIF non compresso valido. L'insieme vulnerabile includeva l'immagine Docker ufficiale di WordPress (libheif 1.19.8), Debian 13 trixie (1.19.8), Ubuntu 26.04 (1.21.2) e Fedora 44 (1.21.2). L'insieme non vulnerabile includeva Ubuntu 24.04 LTS (1.17.6), Debian 12 bookworm (1.15.1), Alpine 3.22 (1.19.8), Alpine 3.23 (1.23.0) e AlmaLinux 10 (1.17.6). Debian 13 e Alpine 3.22 forniscono entrambi libheif 1.19.8, eppure uno è vulnerabile e l'altro no, perché uno abilita il codec non compresso in fase di compilazione e l'altro no. L'immagine Docker ufficiale di WordPress era esposta di default: costruita su Debian 13, includeva l'estensione Imagick, riportava il supporto HEIC e il suo libheif decodificava il formato vulnerabile, con ogni condizione soddisfatta e nessuna azione da parte dell'operatore. Per controllare il tuo sito, apri Strumenti, Salute del sito, Info, Gestione media, che elenca i formati di file supportati da ImageMagick. Se HEIC non è elencato, questo particolare percorso Imagick di WordPress non è esposto, anche se altri software sul server potrebbero ancora usare libheif. Se non puoi ancora applicare le patch, smetti di accettare questi file rimuovendo tutti e quattro i tipi HEIF accettati da WordPress (heic, heif, heics, heifs) dai tuoi tipi di upload consentiti. Disabilitare l'esecuzione PHP nella directory degli upload è anche una buona idea in generale. Se usi l'immagine ufficiale, scarica una base aggiornata, ricostruisci la tua immagine senza fare affidamento su un layer in cache e ridistribuiscila.
Come funziona esattamente il bug? Una foto a colori è memorizzata come tre immagini separate: una contiene la luminosità, e le altre due contengono il colore, una per quanto è blu ogni parte dell'immagine e una per quanto è rossa. Gli occhi umani notano i dettagli nella luminosità molto più dei dettagli nel colore, quindi le due immagini a colori possono essere memorizzate a risoluzione inferiore e nessuno vede la differenza. Nel vocabolario del file, ciascuna di queste è chiamata piano. Ogni piano dichiara quanto spazio richiedono i suoi punti, chiamato profondità di bit. Otto bit per punto è ordinario e occupa un byte di memoria; sedici bit dà gradazioni più fini e occupa due byte. Il formato permette a ciascun piano di dichiarare la propria profondità, una caratteristica ragionevole perché lo stesso formato trasporta immagini scientifiche e di sensori dove le parti differiscono davvero in precisione. Un programma che legge un'immagine chiede al sistema un blocco di memoria abbastanza grande da contenerla, chiamato buffer. Se il programma scrive più dati di quanti il buffer possa contenere, l'eccesso si riversa nella memoria oltre il buffer, che può contenere altri dati o annotazioni usate dal programma. Questo è un overflow del buffer, e se un attaccante controlla cosa viene scritto potrebbe essere in grado di indirizzare il programma a eseguire codice di sua scelta. In libheif 1.23.2, il buffer di ciascun piano è dimensionato in base alla profondità dichiarata di quel piano, che è corretto. Il problema sta nel modo in cui l'immagine viene scritta. I due piani di colore sono memorizzati intrecciati nel file, un punto di ciascuno, alternati lungo la riga, quindi un singolo ciclo riempie entrambi i buffer contemporaneamente. Quel ciclo cerca quanto è largo un punto solo una volta, dal piano di colore che il file elenca per primo. Se il blu a sedici bit è elencato per primo, il ciclo prende due byte come larghezza e scrive punti a due byte in entrambi i buffer. Il buffer del blu può contenerli, ma il buffer del rosso è dimensionato per punti a un byte, quindi ogni punto scritto in esso è il doppio della dimensione che dovrebbe essere e atterra due volte più lontano. Ogni riga trabocca nella riga sottostante, e l'ultima riga supera la fine del buffer finendo nella memoria appartenente a qualcos'altro. I byte che fuoriescono provengono dal file immagine, quindi chi ha creato il file sceglie cosa viene scritto lì, e la quantità che trabocca cresce con le dimensioni dichiarate dell'immagine. Nelle parole del manutentore Dirk Farin, "sia i byte scritti che la lunghezza dell'overflow sono controllati dal file". L'errore è visibile nel record che libheif tiene per ogni piano: due puntatori, due lunghezze di riga, ma solo un campo bytes_per_component_sample, quindi il codice presume che entrambi i piani di colore usino la stessa profondità anche se il file è autorizzato a dichiarare che non è così. Direttamente sopra questo ciclo c'è un commento che descrive una diversa scrittura fuori dai limiti nella stessa funzione che era stata corretta pochi mesi prima, quindi lo stesso codice era già stato patchato una volta per aver scritto oltre la fine di un piano di colore.
Wordfence Argus ha scoperto la vulnerabilità il 28 agosto 2026 durante una valutazione di sicurezza di WordPress 7.1. Il team l'ha riprodotta contro libheif 1.23.2 ufficiale con una build sanitizer e un file di controllo abbinato, ha confermato una seconda build interessata, ha dimostrato l'impatto su un'installazione WordPress pulita e l'ha segnalata al manutentore di libheif tramite il reporting privato delle vulnerabilità di GitHub. Il 31 agosto il manutentore ha committato una correzione, e il 1° settembre è stata rilasciata libheif 1.23.3 e pubblicato l'advisory. La ricerca di follow-up del 2 settembre ha misurato l'affidabilità tra versioni e configurazioni di build. Per i proprietari di siti su hosting WordPress gestito come AEU Hosting, il passo pratico è chiedere direttamente al proprio provider se il libheif del server è patchato e se gli upload HEIC sono accettati, poiché un servizio gestito dovrebbe essere in grado di aggiornare le librerie di sistema e ricostruire i container per tuo conto. La stessa domanda si applica ovunque venga usato libheif: questo software decodifica file HEIC provenienti da qualcun altro? Se elabori file da fonti non fidate, che si tratti di un servizio di condivisione foto, una pipeline di documenti, un'applicazione di chat che genera anteprime o un server multimediale self-hosted, sposta questa voce in cima alla tua lista di patch. Controlla sia la versione di libheif installata sia se è stata compilata con il codec non compresso abilitato, installa il pacchetto corretto del tuo fornitore, isola o sandboxa l'elaborazione delle immagini dove possibile e disabilita il supporto HEIF se non ti serve. La lezione più profonda è che le vulnerabilità che colpiscono i siti WordPress non vivono sempre in WordPress stesso; alcune vivono diversi strati più in basso nelle librerie condivise, raggiunte da una funzionalità banale come caricare una foto delle vacanze.