HEIF Heist: una falla nel decoder di immagini arriva a Slack, Meta, GitHub e Next.js

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · sicurezza applicativa e cloud per team di prodotto negli Stati Uniti e in Europa

In breve

Che cosa ha pubblicato Hacktron?

Il 18 settembre 2026 la società di ricerca sulla sicurezza Hacktron ha pubblicato HEIF Heist, frutto di un’indagine durata mesi su come le applicazioni moderne decodificano le immagini. Il team – Harsh Jaiswal, Mohan SRK, Rahul Maini e Sudhanshu Rajbhar – richiama una celebre vignetta di xkcd: un’enorme pila di software che poggia su un piccolo componente oscuro che quasi nessuno mantiene. In questo caso il componente è libheif (con il suo decoder HEVC libde265), la libreria di fatto standard per leggere i formati HEIF, HEIC e AVIF che smartphone e browser oggi producono di default.

Il difetto principale è un classico bug di basso livello: durante l’elaborazione di un’immagine a griglia, un singolo calcolo sulla larghezza o sull’altezza provoca un integer overflow, che genera un buffer troppo piccolo, oltre il cui limite il decoder poi scrive – un heap buffer overflow. Da qui i ricercatori hanno costruito exploit funzionanti, sottolineando però che per fare danni non serve nemmeno l’esecuzione completa di codice. Secondo Hacktron, anche quando la RCE non è subito raggiungibile, le primitive di attacco possono consentire la lettura arbitraria dello heap: un attaccante può leggere la memoria adiacente, che può contenere token, chiavi o dati di altri utenti.

A dare peso alla pubblicazione è stato l’elenco dei bersagli. Hacktron ha dimostrato l’esecuzione di codice remoto su Slack, nei prodotti principali di Meta tramite caricamento di immagini, una RCE autenticata su GitHub Enterprise tracciata come CVE-2026-19118, una RCE autenticata in Discourse e una RCE senza autenticazione in Next.js tramite la funzione AVIF Image Optimization. Il team ha anche concatenato il bug delle immagini con una debolezza del single sign-on per compromettere account di dipendenti di OpenAI e raggiungere repository di codice interni – un’operazione che, secondo i ricercatori, ha richiesto meno di 72 ore. Le correzioni sono in libheif v1.23.2 e nell’ultima libde265, insieme a patch specifiche dei fornitori coinvolti.

Perché una libreria di immagini è ovunque?

HEIF Heist tocca così tanti prodotti diversi per via della forma del moderno grafo delle dipendenze. Quasi nessuna applicazione parla direttamente con libheif. I team usano strumenti di alto livello – ImageMagick per la conversione, libvips per miniature veloci, Sharp per le pipeline Node.js – e questi strumenti includono o collegano in silenzio libheif e libde265 per supportare i formati più recenti. Il decoder nativo gira diversi livelli sotto il codice scritto dallo sviluppatore, e di solito sotto il linguaggio sulla cui sicurezza della memoria si contava.

Per questo un normale audit dei pacchetti non se ne accorge. Un lockfile JavaScript o Python mostra con orgoglio «sharp» o «imagemagick», ma non la libreria C che sotto esegue il parsing rischioso. Il codice vulnerabile è reale, è raggiungibile da qualsiasi endpoint che accetti un’immagine, eppure resta invisibile agli strumenti sulle dipendenze di cui si fida la maggior parte dei team. È lo stesso punto cieco delle dipendenze native transitive che ha già colpito il settore con librerie come libwebp e libxml2: un singolo parser oscuro sotto una montagna di applicazioni.

La conseguenza pratica è che per proteggersi serve visibilità sulla build, non solo sul codice sorgente. I team che generano già una SBOM (software bill of materials) e analizzano le dipendenze native nella propria pipeline cloud e DevOps rispondono in pochi minuti alla domanda «dove distribuiamo libheif, e in quale versione?». Gli altri devono tirare a indovinare quali servizi decodificano l’immagine di un attaccante con codice vulnerabile – proprio la domanda che una finestra di risposta agli incidenti di 24 ore pretenderà.

Che cosa significa per i team italiani?

La prima lezione è che il caricamento di immagini è un confine di esecuzione del codice, non una funzione di archiviazione. Ovunque un utente, un partner o un’integrazione automatica possa passare un’immagine al vostro backend – avatar, scansioni di documenti per il KYC, allegati in chat, foto prodotto, pipeline da e-mail a ticket –, byte controllati da un attaccante raggiungono un parser nativo. Questo cambia il modo di progettare la funzione: le immagini vanno decodificate in un contesto isolato e con privilegi minimi, non nello stesso processo che custodisce le credenziali del database.

La seconda lezione riguarda la velocità di sfruttamento. Con gli assistenti di AI che riducono lo sviluppo di un exploit a pochi giorni, l’idea che i bug di memoria restino «teorici» finché qualcuno non ci dedica un mese non regge più. Per i settori regolamentati questo si somma a obblighi già esistenti: con gli obblighi di segnalazione del Cyber Resilience Act, in vigore dall’11 settembre 2026, e la regola delle 72 ore del GDPR, una falla sfruttata e confermata in un prodotto venduto nell’UE fa partire un orologio normativo molto stretto.

La terza lezione è che si tratta di un problema di supply chain gestibile solo con un inventario. Non si può correggere ciò che non si vede, e libheif è proprio il tipo di componente che si nasconde. Che sviluppiate internamente o con un team partner per realizzare software su misura, la soluzione duratura è un processo che censisca di continuo le dipendenze native in ogni container e in ogni artefatto di build, così che la prossima divulgazione di questo tipo si risolva con una patch in giornata e non con una caccia al tesoro di una settimana.

Che cosa fare adesso?

1. Aggiornate i decoder ovunque. Passate a libheif v1.23.2 o successiva e all’ultima libde265 – non solo nei pacchetti di sistema, ma in ogni copia inclusa o containerizzata di ImageMagick, libvips o Sharp che distribuite. Ricostruite le immagini e rifate il deploy: un pacchetto aggiornato sull’host non aiuta un container che porta con sé la propria copia.
2. Applicate gli advisory dei fornitori. Se usate GitHub Enterprise, Discourse o applicazioni self-hosted basate sull’ottimizzazione delle immagini di Next.js, aggiornate alle versioni corrette indicate in ciascun advisory. Il percorso Next.js non richiede autenticazione: date priorità alle istanze esposte su Internet.
3. Censite dove decodificate immagini. Elencate ogni endpoint e ogni job in background che legge input HEIF, HEIC o AVIF e generate una SBOM che mostri le librerie native, non solo i pacchetti del linguaggio. Dovete sapere quali servizi sono raggiungibili con un’immagine fornita da un attaccante.
4. Disattivate ciò che non serve. Se un servizio non ha mai bisogno di accettare HEIF o AVIF, disattivate quella decodifica per i caricamenti non attendibili. Limitare i formati in ingresso riduce subito la superficie d’attacco, prima ancora che arrivi una patch.
5. Isolate l’elaborazione delle immagini. Decodificate in una sandbox rinforzata, effimera e con privilegi minimi – un processo, container o worker separato, senza segreti e senza rete –, così che un crash del decoder resti contenuto invece di diventare esecuzione di codice nell’applicazione principale.

Domande frequenti

Fonti

HEIF Heist — pubblicazione di Hacktron
CyberScoop — Researchers use AI to find widespread software decoder flaw
Tom’s Hardware — Hackers breach OpenAI using Claude tools via image-parser flaw