luigigubello/cve-2025-64512-polyglot-pocUna Proof-of-Concept per CVE-2025-64512 che utilizza un file poliglotta.
Nelle ultime settimane (a novembre 2025), è stata divulgata una vulnerabilità interessante (CVE-2025-64512) in pdfminer.six, un popolare progetto Python per l'elaborazione di file PDF, utilizzato in particolare nelle pipeline di intelligenza artificiale. La vulnerabilità consente l'esecuzione remota di codice tramite deserializzazione di dati non attendibili via pickle.loads(), utilizzando un file PDF come vettore d'attacco. Fin qui, tutto bene: è una vulnerabilità importante in un pacchetto Python popolare. Ciò che ha attirato la mia attenzione è stata la sfruttabilità 👀.
Sui sistemi di tipo Linux, solo i file presenti nel filesystem possono essere risolti. Un attaccante dovrebbe fornire il PDF malevolo per l'elaborazione e il file pickle malevolo dovrebbe essere presente sul sistema target in una posizione già nota all'attaccante, poiché deve essere impostata nel PDF stesso. In molti casi sarà difficile da sfruttare perché, anche se l'attaccante fornisce sia il PDF che il file pickle insieme, non ci sarebbe modo di sapere in anticipo quale percorso completo specificare per il file pickle. [...] In generale, su un sistema Linux o simile a Linux il rischio è complessivamente minore.
Quindi, apparentemente, per sfruttare questa vulnerabilità su un sistema di tipo Linux, l'attaccante dovrebbe:
Possiamo creare un file PDF valido che inneschi la vulnerabilità senza conoscere il percorso del file pickle malevolo?
"Valido" significa che pdfminer.six non rifiuta il file e inizia a elaborarlo (perché un file PDF è ciò che un lettore PDF apre).
La risposta è Sì, creando un payload poliglotta (una sorta di). L'idea è creare un file che sia sia un pickle.gz valido sia un file PDF valido, così che pdf2txt.py possa iniziare a elaborare un file PDF e poi puntare a esso per caricare il codice pickle in formato GZIP.
Spesso - ma non sempre 🥲 - un file è un file PDF se contiene %PDF- da qualche parte, in generale nei primi 1024 byte (1 - 2). Per pdfminer.six, un file PDF valido deve semplicemente avere un oggetto /Root (pdfdocument.py#L752).
Un file GZIP ha byte iniziali specifici (RFC 1952 - Sez. 2.3.1), ma supporta i commenti (FCOMMENT, RFC 1952 - Sez. 2.3.1).
Quindi, questo è il progetto del file poliglotta: creare un GZIP valido contenente il payload pickle malevolo e incorporare un file PDF valido nel flag FCOMMENT del GZIP. Poi usare questo file come PDF valido con pdf2txt.py per innescare la vulnerabilità e usare lo stesso file per eseguire il pickle malevolo.
(2025.12.12) EDIT:
L'unico vincolo che abbiamo è il nome del file: deve terminare con .pickle.gz (questo è incorporato nel codice di .pdfminer.six, cmapdb.py#L235)
I due vincoli che abbiamo sono:
pdfminer.six, cmapdb.py#L235);Sono un po' sorpreso che questa CVE sia così sottovalutata, considerando la popolarità di questo progetto (6k ⭐️ su GitHub, ma usato da 34k progetti, secondo le statistiche di GitHub) e i casi d'uso (strumenti a riga di comando, workflow di IA, pipeline, in breve, tutti i tipi di infrastruttura che non vuoi aggiornare se funziona).
Ad esempio, lo strumento Microsoft markitdown 0.1.3 (microsoft/markitdown, 84k ⭐️ su GitHub e usato da 2k progetti), installato prima del 1° dicembre, è vulnerabile all'esecuzione arbitraria di codice tramite pdfminer.six. Il team Microsoft ha rilasciato una patch il 1° dicembre, 0.1.4, ma nessun avviso di sicurezza, quindi non credo che l'aggiornamento sia stato prioritizzato da altri team di ingegneria.
Altri progetti potrebbero essere affetti da CVE-2025-64512 ed è abbastanza facile da sfruttare.
Un elenco (incompleto) di progetti vulnerabili:
docker build -t cve-2025-64512-poc .
docker run --rm -it cve-2025-64512-poc
pdf2txt.py payload.pickle.gz
docker build -t cve-2025-64512-poc .
docker run --rm -it cve-2025-64512-poc
markitdown markitdown-payload.pickle.gz -x pdf -o output.md
