ExifTool macOS: nuova RCE via metadata, sistemi a rischio

ExifTool macOS: nuova RCE via metadata, sistemi a rischio

Nel febbraio 2026 il team GReAT di Kaspersky ha identificato e segnalato CVE-2026-3102, una vulnerabilità di esecuzione remota comandi in ExifTool su macOS che colpisce versioni 13.49 e precedenti. Il difetto risiede in una funzione adiacente a quella già compromessa dalla CVE-2021-22204: stesso software, stessa superficie di attacco — metadata immagine — ma sink diverso e vettore di consegna mutato. Perché conta ora: ExifTool è standard de facto nei workflow fotografici, forensi e nelle pipeline CI/CD che processano media non attendibili. Una sola immagine appositamente confezionata, copiata con il flag sbagliato, apre un terminale sotto il naso dell'utente.

La scoperta: audit adiacente a una vulnerabilità storica

La ricerca è partita da una revisione sistematica della CVE-2021-22204, la vulnerabilità ExifTool che nel 2021 ha esposto milioni di sistemi a RCE tramite eval() su metadata DjVu. I ricercatori GReAT hanno esteso l'analisi alle routine di validazione circostanti, ipotizzando che difetti simili potessero persistere in branch parallele del codebase. La supposizione si è rivelata corretta: in SetMacOSTags, funzione dedicata alla gestione dei tag macOS-specifici, il sink non è eval() ma system() — una variazione che altera il profilo di attacco ma non la gravità.

La scoperta di vulnerabilità "vicine di casa" di flaw noti è un pattern ricorrente nella storia della sicurezza software. Quando un bug ottiene visibilità pubblica, le patch tendono a circoscrivere il perimetro esatto della falla, lasciando intatte routine speculari che condividono logiche di input handling. Il caso CVE-2026-3102 conferma la regola: la sanificazione applicata a CVE-2021-22204 non si è propagata a SetMacOSTags, pur operando su dati analoghi.

Il meccanismo: come $val raggiunge system() senza filtri

La funzione SetMacOSTags gestisce la traduzione dei metadata Exif in attributi estesi del filesystem macOS. Quando l'utente invoca ExifTool con -tagsFromFile per copiare metadati da un file sorgente a uno destinazione, e specifica il flag -n per ottenere output machine-readable senza conversione, il codice segue un percorso particolare. Se il tag di destinazione corrisponde a MDItemFSCreationDate o $FileCreateDate, la funzione costruisce un comando shell per invocare SetFile o utility equivalenti.

Nella costruzione di questo comando, il nome file ($file) è sottoposto a escaping corretto. Il valore della data ($val), estratto direttamente dal campo metadata del file sorgente, non riceve lo stesso trattamento. Questa asimmetria è il cuore della vulnerabilità: un attaccante può confezionare un'immagine con un campo data contenente virgolette e sequenze shell, e quando ExifTool processa la copia con -tagsFromFile -n, il comando system() esegue il payload. Non è buffer overflow, non è use-after-free: è command injection classica, favorita da una distinzione tra "input sensibile" e "input fidato" che i metadati non meritano.

Il vincolo del vettore: perché non tutte le operazioni sono pericolose

Un dato tecnicamente rilevante limita la superficie di attacco: il percorso vulnerabile si attiva solo con la copia metadata via -tagsFromFile, non con la scrittura diretta di FileCreateDate. Se l'utente imposta manualmente la data con -FileCreateDate="...", ExifTool non attraversa SetMacOSTags nello stesso modo. Il flag -n (-printConv) è inoltre requisito obbligatorio: senza di esso, i dati subiscono conversione e formattazione che interferiscono con la struttura del payload.

Questi vincoli non mitigano il rischio, lo canalizzano. Le pipeline automatizzate — script di importazione foto, tool forensi batch, servizi web che accettano upload e generano thumbnail con metadata — sono configurazioni tipiche dove -tagsFromFile e -n compaiono insieme. Un servizio che riceve immagini da fonti esterne e normalizza i metadata prima dell'archiviazione può eseguire codice malevolo senza interazione umana, con i privilegi dell'account del servizio.

"The vulnerable code path is triggered only when $tag matches MDItemFSCreationDate or $FileCreateDate... the filename parameter is properly escaped, but the date value ($val) is not." — Kaspersky GReAT, Securelist

Cosa fare adesso

1. Aggiornare ExifTool oltre la versione 13.49, verificando il changelog ufficiale per conferma della patch: la fonte indica che gli sviluppatori hanno rilasciato correzione nel febbraio 2026, ma non specifica il numero esatto della build sicura.
2. Ispezionare script e pipeline che utilizzano -tagsFromFile con -n o -printConv: identificare i punti dove il file sorgente proviene da origine non attendibile e separare il processing in ambienti sandboxati.
3. Validare i metadata in ingresso prima del passaggio a ExifTool: tool come exiv2 in modalità di sola lettura, o parser dedicati, possono rilevare anomalie nei campi data prima che raggiungano il sink vulnerabile.
4. Monitorare i log di sistema per invocazioni anomale di SetFile o utility correlate da processi ExifTool: se l'esecuzione avviene con privilegi elevati, la compromissione si estende rapidamente al sistema.

L'ombra della CVE-2021-22204: pattern ricorrente, risposta frammentata

La relazione genealogica con CVE-2021-22204 non è curiosità storica ma indicatore di un problema strutturale. Quattro anni e mezzo separano i due flaw, entrambi in ExifTool, entrambi in funzioni che processano metadata immagine, entrambi causati da input non sanificati in sink di esecuzione. La differenza nei dettagli — eval() contro system(), scrittura diretta contro copia con -tagsFromFile — non cancella la somiglianza nel modello di minaccia.

Per gli utenti finali, la lezione è che i tool di linea comando ereditati dagli anni '90, per quanto indispensabili, portano con sé assunzioni sulla fiducia dei dati che il web moderno ha reso obsolete. Per gli sviluppatori, il caso sollecita audit di retrocompatibilità: quando si patcha una vulnerabilità ad alta visibilità, la revisione deve estendersi a tutte le funzioni che condividono la stessa logica di input, non solo al percorso di exploit documentato.

Le cose che non sappiamo

Il report Kaspersky si interrompe prima della dimostrazione completa della catena di exploit, lasciando aperta la questione della riproducibilità pratica senza accesso al codice. Non è dichiarato se la vulnerabilità sia stata osservata in-the-wild, né è disponibile un punteggio CVSS che ne quantifichi la severità. Manca inoltre la conferma del numero esatto della versione patch: "febbraio 2026" indica il mese del rilascio, ma non la build oltre cui il software è considerato sicuro. Questi limiti, annotati esplicitamente nella fonte, impediscono di tracciare un perimetro di rischio definitivo e raccomandano prudenza nell'aggiornamento.

FAQ

Posso essere attaccato se uso ExifTool solo per visualizzare i metadata di un'immagine?

No, secondo la fonte il percorso vulnerabile richiede l'uso di -tagsFromFile con copia in FileCreateDate e il flag -n. La sola lettura o visualizzazione non attiva SetMacOSTags nel modo compromesso.

Perché il nome file è escapato ma il valore data no?

La fonte non fornisce una motivazione esplicita; si può ipotizzare che il nome file sia stato oggetto di revisione sicurezza in passato (rischio path traversal noto), mentre i valori dei tag data non abbiano ricevuto la stessa attenzione. L'asimmetria è il bug.

La patch di febbraio 2026 è sufficiente anche per CVE-2021-22204?

CVE-2021-22204 fu patchata separatamente nel 2021. Non assumere che la correzione di CVE-2026-3102 copra retroattivamente flaw precedenti: ogni vulnerabilità richiede la propria verifica di stato.

Fonti

• https://securelist.com/exiftool-compromise-mac/119866/

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

Fonti

• https://securelist.com/exiftool-compromise-mac/119866/