Pillow 13 corregge RCE, x402 espone i wallet degli agenti AI

🛡️ Executive Summary

• Pillow 13.0.0 corregge vulnerabilità critiche nei decoder di immagini, comprese tre CVE che possono provocare corruzione della memoria ed esecuzione di codice in particolari configurazioni.
• Il protocollo x402 espone gli agenti AI a pagamenti non autorizzati quando il client firma automaticamente richieste economiche senza limiti di spesa applicati dall’applicazione.
• Le versioni aggiornate dell’SDK x402 introducono un limite predefinito di un dollaro per pagamento, ma i controlli possono essere disabilitati e non sostituiscono un budget complessivo.

Pillow e x402 affrontano due problemi di sicurezza che colpiscono componenti sempre più utilizzati nelle infrastrutture digitali e nelle applicazioni di intelligenza artificiale. La libreria Python per l’elaborazione delle immagini ha distribuito Pillow 13.0.0, correggendo numerose vulnerabilità che possono provocare crash, divulgazione di informazioni ed esecuzione remota di codice quando un servizio elabora file manipolati. Il sistema di pagamenti x402, utilizzato anche dagli agenti AI per acquistare autonomamente servizi e interrogazioni API, ha invece dovuto introdurre limiti economici per impedire che un server malevolo induca un client automatizzato a firmare transazioni eccessive. I due casi mostrano come un input apparentemente ordinario possa attraversare un confine di fiducia e trasformarsi in un’operazione privilegiata: l’elaborazione di un’immagine nel primo caso, l’autorizzazione di un pagamento nel secondo.

Pillow 13 corregge tre vulnerabilità critiche nei decoder di immagini

Pillow 13.0.0, rilasciato il 16 ottobre 2026, contiene un aggiornamento di sicurezza particolarmente esteso che interessa diversi formati grafici, parser e componenti nativi. Le note ufficiali della versione 13.0.0 identificano tre vulnerabilità critiche: CVE-2026-96639, CVE-2026-112398 e CVE-2026-112403. La prima riguarda il riutilizzo improprio della memoria allocata per immagini composte da più fotogrammi, mentre le altre due coinvolgono il decoder JPEG e la gestione delle dimensioni dei buffer. I problemi interessano operazioni apparentemente ordinarie, come aprire un’immagine, generare un’anteprima oppure passare da un fotogramma a quello successivo. Il rischio nasce dal fatto che Pillow utilizza componenti nativi scritti in C per eseguire operazioni ad alte prestazioni: la sicurezza della memoria non è garantita automaticamente dal fatto che l’applicazione principale sia sviluppata in Python. Le vulnerabilità possono quindi compromettere servizi che utilizzano la libreria per gestire immagini caricate dagli utenti, incluse piattaforme web, applicazioni documentali e pipeline di conversione.

Il problema assume particolare rilevanza nelle architetture in cui il caricamento di un file determina immediatamente l’apertura e la conversione dell’immagine. In questi ambienti, l’attaccante non deve necessariamente disporre di un account amministrativo: può essere sufficiente riuscire a far elaborare un file controllato a un componente vulnerabile. L’effettiva possibilità di eseguire codice dipende tuttavia dal formato utilizzato, dalla libreria nativa sottostante e dal percorso di elaborazione raggiungibile. Il principio è lo stesso delle vulnerabilità RCE nei parser e nei componenti che trasformano dati non attendibili in istruzioni, dove il confine tra contenuto e comportamento eseguibile viene compromesso prima ancora che intervenga la logica applicativa.

Leggi anche: LiteLLM espone gateway AI a RCE root e furto di credenziali IAM

JPEG, FlashPix e immagini multi-frame possono corrompere la memoria

CVE-2026-112398 riguarda il decoder delle immagini FlashPix, formato basato su contenitori OLE2 che può incorporare dati JPEG. La vulnerabilità consiste nella scrittura di dati oltre il buffer allocato quando il decoder produce scanline più ampie dello spazio previsto. Il security advisory originale GHSA-5x8w-8jj5-q52h documenta un proof-of-concept capace di ottenere esecuzione di codice in una configurazione di test specifica. Il vettore richiede che l’applicazione utilizzi Pillow con la dipendenza opzionale olefile, necessaria per riconoscere i file FPX, e che elabori un documento opportunamente manipolato. Il riconoscimento avviene attraverso il contenuto del file e non soltanto attraverso la sua estensione, per cui un controllo limitato al nome del file non costituisce una difesa sufficiente.

CVE-2026-112403 riguarda invece il ridimensionamento di immagini JPEG attraverso funzioni come draft() e thumbnail(). Quando il decoder utilizza libjpeg-turbo 3.x per elaborare particolari immagini JPEG lossless, la libreria può ignorare la riduzione di scala richiesta e produrre una riga di pixel più ampia rispetto al buffer predisposto da Pillow. Il risultato è una scrittura fuori dai limiti della memoria. Le informazioni tecniche pubblicate dal progetto precisano che il problema richiede il percorso di ridimensionamento vulnerabile e non interessa indistintamente tutte le operazioni JPEG. Infine, CVE-2026-96639, classificata CVSS 9,8, interessa immagini multi-frame nei formati PSD, MPO, DCX e MIC: una modifica della modalità colore può provocare il riutilizzo di un buffer allocato per un’immagine con caratteristiche differenti, determinando scritture fuori limite e, in particolari ambienti di test, esecuzione di codice.

Pillow 13 risolve anche denial-of-service e perdite di memoria

L’aggiornamento non si limita alle vulnerabilità classificate Critical. Le note di rilascio comprendono problemi nell’elaborazione dei file TIFF, nella gestione dei metadati Exif, nei documenti PDF e in diversi decoder di immagini compresse. Alcuni difetti permettono di provocare denial-of-service attraverso consumo eccessivo di memoria o CPU, mentre altri possono esporre porzioni di memoria non inizializzata durante la conversione delle immagini. Un esempio riguarda i file TIFF manipolati per alterare dimensioni e contenuto delle strutture ColorMap, con possibili letture oltre i limiti previsti; altri problemi consentono di aggirare i controlli contro le decompression bomb, immagini apparentemente piccole che richiedono quantità sproporzionate di memoria una volta elaborate. La versione 13 introduce inoltre modifiche incompatibili con alcune applicazioni precedenti e termina il supporto per Python 3.10, che ha raggiunto la fine del proprio ciclo di manutenzione.

Per gli amministratori il problema principale è identificare dove Pillow venga realmente utilizzato. La libreria può essere installata direttamente attraverso pip, incorporata in un’immagine container oppure distribuita come dipendenza di un’applicazione più complessa. La correzione upstream è Pillow 13.0.0, ma le distribuzioni Linux possono applicare patch attraverso pacchetti con una numerazione differente. Occorre quindi verificare gli advisory del proprio fornitore e ricostruire le dipendenze effettivamente caricate in produzione, evitando di interpretare la semplice presenza di Python come prova di esposizione. La situazione richiama il problema emerso con LMCache, dove una funzione ordinaria di elaborazione dei dati poteva provocare RCE nei server AI.

x402 consente a un server malevolo di richiedere pagamenti eccessivi

Il secondo fronte riguarda x402, protocollo aperto che utilizza la risposta HTTP 402 Payment Required per consentire a servizi e agenti AI di effettuare pagamenti digitali. In un normale flusso x402, il server comunica al client il costo dell’operazione, il destinatario, la rete blockchain e l’asset richiesto. Il client costruisce quindi una prova di pagamento firmata, che viene verificata e regolata attraverso l’infrastruttura prevista dal protocollo. Il problema emerge quando un agente dispone di un wallet capace di firmare autonomamente le transazioni e il software non applica limiti all’importo richiesto dal server remoto. Un endpoint malevolo potrebbe presentare una richiesta economicamente sproporzionata rispetto al servizio offerto, inducendo il client a firmarla se l’applicazione non dispone di controlli aggiuntivi.

Il comportamento è documentato anche nelle discussioni tecniche del repository ufficiale x402 e non deve essere confuso con una compromissione delle chiavi private. L’attaccante non ha necessariamente bisogno di sottrarre il wallet: può tentare di ottenere una transazione validamente firmata dal suo proprietario automatizzato. La differenza è fondamentale perché il problema non riguarda la capacità degli smart contract di verificare una firma, ma la decisione del software che autorizza il pagamento prima della firma. Il rischio assume maggiore importanza con l’arrivo di AWS AgentCore Payments, che permette agli agenti AI di acquistare servizi e inferenze attraverso x402. La presenza di un agente capace di spendere autonomamente rende indispensabile separare la richiesta economica del server dall’autorizzazione concessa dall’utente.

L’SDK x402 introduce un limite predefinito di un dollaro per pagamento

Per ridurre questo rischio, i manutentori di x402 hanno introdotto controlli di spesa nei client ufficiali, attraverso modifiche distribuite tra il 13 e il 18 agosto 2026 e successivamente integrate nelle release disponibili. La documentazione del progetto descrive un comportamento predefinito che autorizza soltanto asset riconosciuti come ancorati al dollaro e limita ogni pagamento a un dollaro, salvo configurazioni esplicite differenti. L’implementazione utilizza il parametro spendControls, che permette agli sviluppatori di definire asset autorizzati e importi massimi per singola transazione. Le note ufficiali del changelog Python x402 e la documentazione degli asset predefiniti confermano che i controlli possono essere modificati e persino disabilitati attraverso una configurazione esplicita.

Il limite predefinito non equivale a un budget complessivo garantito. Un client che autorizza automaticamente numerose transazioni da un dollaro può comunque consumare somme elevate se l’applicazione non applica limiti cumulativi, controlli sui destinatari e restrizioni sulla frequenza dei pagamenti. È questa la distinzione tra impedire una singola richiesta abusiva e proteggere un wallet da una sequenza di operazioni formalmente valide. Le versioni aggiornate dell’SDK riducono il rischio delle richieste eccessive, ma gli sviluppatori devono verificare che i controlli siano realmente abilitati e che eventuali personalizzazioni non abbiano eliminato i vincoli predefiniti. Il problema si collega alle precedenti ricerche sui pagamenti automatici e sulla necessità di separare identità e autorizzazioni degli agenti AI, dove il vero confine di sicurezza non coincide con la validità crittografica della transazione.

Continua con:

Crypto entra nell’economia automatizzata tra agenti AI, XRP Ledger e Solana

La sicurezza degli agenti AI richiede controlli prima dell’esecuzione

Le vulnerabilità Pillow e il problema dei pagamenti x402 rappresentano due classi differenti di errore, ma evidenziano la stessa esigenza architetturale: i dati provenienti da soggetti non attendibili devono essere verificati prima di produrre effetti sul sistema. Nel caso Pillow, un file immagine può diventare il mezzo per alterare la memoria di un processo privilegiato; in x402, una risposta HTTP apparentemente legittima può trasformarsi in una richiesta di trasferimento economico. Gli interventi necessari sono differenti: aggiornare Pillow almeno alla versione 13.0.0 o a una build corretta dal distributore, isolare i processi che elaborano immagini caricate dagli utenti e verificare i formati realmente supportati; per x402, utilizzare SDK aggiornati, applicare limiti per transazione e complessivi, autorizzare esplicitamente asset e destinatari e monitorare i pagamenti effettuati dagli agenti. Non emergono dalle fonti primarie consultate conferme di campagne di sfruttamento attivo attribuibili a queste specifiche vulnerabilità.

La conseguenza più importante riguarda il rapporto tra automazione e autorizzazione. Le applicazioni moderne elaborano immagini, documenti, messaggi e richieste economiche senza attendere necessariamente una decisione umana per ogni operazione. Proprio questa autonomia rende essenziale collocare i controlli di sicurezza nel componente che esegue l’azione, anziché affidarsi soltanto alla correttezza degli input o alle istruzioni ricevute dal modello AI. Un pagamento crittograficamente valido può essere economicamente non autorizzato, così come un’immagine formalmente riconosciuta può contenere dati capaci di compromettere il decoder che la interpreta.