Pillow 13.0.0 corregge RCE: il filename, non il file, era la minaccia

Pillow, la libreria Python per l'elaborazione di immagini con quasi 436 milioni di download mensili da PyPI, ha rilasciato il 16 ottobre 2026 la versione 13.0.0 che corregge una vulnerabilità critica persistita per circa dodici anni. Il problema non sta nel formato EPS né nel suo contenuto PostScript, ma nel modo in cui Pillow passa il nome del file a Ghostscript: un filename controllato dall'utente viene inserito come argomento -f senza normalizzazione, permettendo injection di comandi arbitrari. Il Common Vulnerabilities and Exposures CVE-2026-112900 assegnato da GitHub registra un punteggio CVSS 4.0 di 9.2, livello CRITICAL.

Il meccanismo: quando il parser degli argomenti diviene l'arma

L'analisi del codice sorgente in EpsImagePlugin.py mostra la catena esatta della vulnerabilità. Pillow estrae fp.name dal file object e lo inserisce in una lista di comando passata a subprocess.check_call(): l'elemento '-f' precede il filename senza alcuna validazione intermedia. Questo pattern, classificato come CWE-88 (Argument Injection), si trasforma in esecuzione remota perché Ghostscript non tratta il valore successivo a -f come stringa opaca ma lo sottopone al proprio parser di argomenti.

Il comportamento di Ghostscript è documentato e coerente: un filename che inizia con - o -- viene letto come opzione, uno che inizia con @ come riferimento a file contenente argomenti aggiuntivi. La proof-of-concept pubblicata nell'advisory GitHub GHSA-w889-685w-c8fh dimostra l'esecuzione del comando id tramite un filename @arguments.txt che punta a un file esterno con parametri Ghostscript manipolati. Il test riproduce su Ghostscript 10.02.1 e 10.07.1.

"The flaw is triggered by the filename, not by anything in the PostScript document. A completely benign EPS file still results in Ghostscript argument injection whenever the filename passed to Image.open() is attacker-influenced."
— GitHub Security Advisory GHSA-w889-685w-c8fh

Il fallimento del sandbox: -dSAFER non era sufficiente

Un elemento che rende questa vulnerabilità particolarmente insidiosa è la neutralizzazione del sandbox -dSAFER, attivo per default nelle invocazioni Pillow. Questa opzione di Ghostscript limita le operazioni PostScript pericolose — accesso al filesystem arbitrario, esecuzione di comandi shell dal linguaggio — ma opera a valle del parsing degli argomenti da riga di comando. Il filename malevolo non aggira -dSAFER attraverso il contenuto EPS; lo precede, manipolando la stessa linea di comando che attiva il processo.

La documentazione ufficiale di Pillow sul modello di minaccia riconosce esplicitamente questa lacuna: il passaggio via subprocess con argomenti utente-controllati costituisce una superficie d'attacco distinta dal parsing del linguaggio PostScript. L'advisory GitHub sottolinea che la responsabilità della sanitizzazione ricade su Pillow come costruttore della riga di comando, non sui chiamanti downstream.

La trappola del filename: quando i controlli di contenuto falliscono

Il vettore filename-based elude le difese convenzionali basate su contenuto e tipo MIME. Un servizio web che verifichi magic number, intestazione EPS o corrispondenza estensione/contenuto resta vulnerabile se il nome del file caricato — spesso derivato dall'input utente o generato con prefisso controllato — attraversa il percorso filesystem fino a Image.open(). Le condizioni di exploit sono tre: Ghostscript installato nel sistema, elaborazione di file EPS via path filesystem (non oggetto file già aperto), e influenza dell'attaccante sul filename.

La fonte pk-sharma.com calcola una finestra di esposizione di dodici anni dalla release 2.6.0, con il commit di correzione individuato in a2c363141da31a265dd536c945677db4b64f3ec9. La modifica è minimalista: una sola riga sostituisce infile = fp.name con infile = os.path.abspath(fp.name). La funzione os.path.abspath() garantisce che il path inizi con il separatore di directory del sistema operativo, rendendo impossibile che un prefisso - o @ raggiunga il parser di Ghostscript.

Cosa fare adesso

Per gli amministratori di sistema e i maintainer di applicazioni che processano upload di immagini tramite Pillow, le azioni prioritarie sono le seguenti. Verificare se l'applicazione apre file EPS con Image.open() passando un path filesystem; se il filename deriva dall'utente, l'esposizione è confermata.

Aggiornare a Pillow 13.0.0 o superiore, con la consapevolezza che questo richiede Python 3.11 o versioni successive; gli ambienti bloccati su Python 3.10 devono valutare la compatibilità del runtime. Verificare la presenza di Ghostscript nel sistema operativo o nei container di deploy, poiché la vulnerabilità si attiva solo se il binario gs è disponibile e invocabile da Pillow.

In assenza di upgrade immediato, valutare se l'applicazione effettivamente processa formati EPS: la maggior parte dei flussi di thumbnail e conversione si limita a JPEG, PNG e WebP, formati che non attivano il percorso EpsImagePlugin.

Non è emersa exploitation in-the-wild al momento della pubblicazione, secondo quanto riportato da The Hacker News e da pk-sharma.com. Questo intervallo di grazia non elimina la priorità dell'intervento: la semplicità del vettore e la disponibilità del codice di proof-of-concept riducono significativamente la barriera all'adozione da parte di attori malevoli.

Perché questa vulnerabilità ricalibra il threat model

Il caso CVE-2026-112900 inverte la logica convenzionale della sicurezza dei file: il contenuto è innocuo, il contenitore — inteso come nome del file — è il pericolo. Questo pattern assume qui una forma tecnica precisa perché il nome attraversa un confine tra applicazione e tool esterno senza adeguata delimitazione. La lezione strutturale va oltre Pillow: ogni interfaccia che passa dati utente a processi esterni tramite argomenti di riga di comando deve considerare il parsing del destinatario, non solo la propria intendita semantica.

Il fix con os.path.abspath() è tecnicamente elegante ma anche indicativo: la soluzione non richiede una nuova architettura di sandboxing, solo il riconoscimento che un path e una stringa opaca sono entità diverse quando entrano in un parser esterno. Dodici anni di esposizione suggeriscono che questa distinzione non fosse evidente ai maintainer, nonostante Ghostscript documenti da tempo il comportamento dei prefissi speciali.

FAQ

Il mio applicativo converte solo JPEG/PNG, è vulnerabile?

No. La vulnerabilità è confinata al percorso di elaborazione EPS in EpsImagePlugin.py. Se l'applicazione non chiama Image.open() su file EPS o non ha Ghostscript installato, il vettore non si attiva.

Perché -dSAFER non ha protetto?

-dSAFER sandboxa l'esecuzione PostScript, non il parsing degli argomenti da riga di comando. Il filename malevolo agisce prima che il contenuto EPS venga valutato, manipolando la costruzione stessa del processo Ghostscript.

Posso mitigare senza aggiornare Pillow?

Le fonti disponibili non indicano mitigazioni alternative documentate. L'upgrade a Pillow 13.0.0 resta l'intervento confermato per questa vulnerabilità.

Fonti

• thehackernews.com
• pk-sharma.com
• cve.org
• pillow.readthedocs.io
• github.com