Nel gennaio 2026, OPSWAT ha pubblicato un'analisi della vulnerabilità CVE-2025-66516, una vulnerabilità critica in Apache Tika causata da un PDF dannoso che raggiungeva un parser di backend. La soluzione era semplice: sanificare il file prima che raggiungesse il parser, in modo che quest’ultimo non vedesse mai il payload. Ciò ha funzionato perché c’era un solo parser, un solo tipo di file e una sola libreria nota.
E se l’XML non fosse un PDF, ma un file di configurazione importato in una piattaforma SSO (Single Sign-On), una definizione di flusso di lavoro inviata a un motore di automazione finanziaria o un payload di dati sanitari elaborato da un sistema di integrazione ospedaliero? Questi file circolano ogni giorno tra organizzazioni, appaltatori, autorità di regolamentazione e partner, arrivando tramite sistemi di trasferimento file gestito e portali dei partner come input aziendali attendibili. La maggior parte delle soluzioni di sanificazione non li ispeziona mai.
L'XML è il linguaggio dell'industria, ed è proprio questo il problema
Gli attacchi XXE (XML External Entity) su PDF e SVG seguono lo stesso schema: un utente carica un file; una libreria di backend lo analizza; il parser esegue il payload. Il punto di ingresso è visibile.
L'XML di settore è diverso. Si tratta di trasferimenti business-to-business, importazioni di configurazioni e payload da sistema a sistema provenienti da partner, autorità di regolamentazione, appaltatori e fornitori noti. Proprio questa apparente legittimità è il motivo per cui sfuggono al controllo applicato ai caricamenti sul web.
L'XML è parte integrante del funzionamento di numerosi settori:
- Servizi finanziari: i messaggi SWIFT, le istruzioni FIX (Financial Information eXchange) e i pagamenti ISO 20022 sono tutti in formato XML.
- Sanità: HL7 (Health Level Seven) e FHIR (Fast Healthcare Interoperability Resources), i protocolli standard per lo scambio di dati sanitari, sono basati su XML. Un soggetto malintenzionato all’interno di un payload FHIR riesce a superare qualsiasi sistema che verifichi la struttura ma non il DOCTYPE.
- IT aziendale: le piattaforme di gestione delle identità e di SSO importano file di configurazione XML durante le fasi di integrazione, migrazione e onboarding. Una singola importazione può interessare tutte le applicazioni per cui la piattaforma gestisce l'autenticazione.
- OT: I sistemi SCADA e di gestione energetica scambiano dati in formati XML definiti dalle norme IEC 61968 e 61970, spesso attraversando i confini tra IT e OT, dove i controlli sono minimi.
In ogni caso, il payload non è uno script né una macro, ma si trova nel livello di contenuto dell'XML: una dichiarazione DOCTYPE che fa riferimento a un'entità esterna la quale, a sua volta, rimanda a un percorso di file locale o a un endpoint interno. Quando il parser elabora il file, recupera tale contenuto.
Sebbene il file risulti strutturalmente valido in base al controllo dello schema, il suo contenuto richiede un livello più approfondito di sanificazione, ad esempio per quanto riguarda ciò che dichiara il DOCTYPE o dove punta l’entità.
Non si tratta di un problema legato al passato
La vulnerabilità XXE è stata descritta nel 2003 e inserita nella Top 10 dell’OWASP nel 2017, il che a volte induce i team a considerarla risolta. I dati relativi al 2025 e al 2026 indicano invece il contrario, e i casi rilevanti per la sicurezza dei file sono quelli in cui il payload arriva sotto forma di file.
- lxml (CVE-2026-41066): la configurazione predefinita del parser in una libreria XML per Python ampiamente utilizzata consentiva a file XML non attendibili di leggere file locali. lxml è la stessa libreria utilizzata da svglib per analizzare i file SVG (Scalable Vector Graphics); l'OPSWAT a tramite percorso nel file è stata illustrata nel suo blog del 2024 dedicato all'SVG XXE. La sanificazione del file rimuove l'entità prima che il parser la rilevi.
- Atlassian Crowd (CVE-2026-21569, CVSS 7.9 - Alto): una piattaforma di SSO e gestione delle identità. Un payload XML appositamente creato consente a un malintenzionato di ottenere l'accesso locale o remoto ai file; inoltre, la valutazione CVSS "Scope:Changed" indica che un exploit riuscito interessa tutte le applicazioni autenticate da Crowd. Il file XML viene inviato come importazione di configurazione o integrazione da un partner o da una workstation amministrativa.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 Alto): IBM BAW elabora file XML in flussi di lavoro quali l’erogazione di prestiti e la gestione dei sinistri. La vulnerabilità consente la divulgazione di file e l’SSRF (Server-Side Request Forgery), permettendo a un aggressore di accedere a endpoint interni; inoltre, la stessa struttura DOCTYPE può causare l’espansione di entità con conseguente DoS (Denial of Service). I file XML giungono tramite portali dei partner da periti, autorità di regolamentazione e integratori.
Tutto converge su un unico modello comune: un file XML aziendale attendibile contenente un payload DOCTYPE, che passa attraverso un flusso di lavoro consolidato prima di raggiungere un parser vulnerabile.
Una precisazione: questo blog tratta dei casi di XXE che si presentano sotto forma di file. I file XML e i formati basati su XML, come SVG, PDF con XFA e file Office, che passano attraverso un flusso di lavoro di sanificazione, vengono ricostruiti in modo sicuro. I casi che coinvolgono i file sono quelli più comuni: caricamenti, importazioni di configurazioni, scambio di dati con partner e allegati e-mail. L’XXE che si verifica tramite il corpo grezzo di una richiesta API o una chiamata di analisi sintattica nel codice non comporta il trasferimento di alcun file, pertanto in tale percorso non è presente alcun gateway di sanificazione dei file.
Come la tecnologia Deep CDR™ gestisce i file XML autonomi
La tecnologia Deep CDR™ supporta XML 1.0 e 1.1, oltre ai formati correlati basati su XML, tra cui ZEI, JNLP, TDS, RDF, BML, MPD e TTML, tutti gestiti dallo stesso motore.
Per i file XML, i riferimenti che puntano all’esterno del documento vengono rifiutati per impostazione predefinita, e il DOCTYPE e i relativi riferimenti alle entità esterne non vengono mantenuti nel file ricostruito. Nessuno dei due comportamenti costituisce una politica che debba essere individuata e ottimizzata. La protezione è attiva fintanto che l’XML esterno viene instradato attraverso il flusso di lavoro di sanificazione in MetaDefender Core™.
Oltre a questa rimozione predefinita del DOCTYPE, gli operatori dispongono di ulteriori controlli che possono configurare in base al proprio ambiente
- Rimuovi macro: elimina le macro VBA codificate nei formati Office basati su XML
- Rimuovi CDATA: quattro opzioni di politica graduate, da “Non fare nulla” a “Rimuovi tutto”, che consentono ai team di decidere con quale intensità gestire le sezioni CDATA a seconda della sensibilità del flusso di lavoro
- Rimozione delle iniezioni: risolve il problema delle iniezioni XML e del codice JavaScript a livello di contenuto incorporato nei valori degli elementi
- Elaborazione dei dati codificati in Base64: gestisce i payload codificati incorporati nei valori XML, inclusi i modelli dello schema URL dei dati
Una protezione correlata copre l'altro aspetto della stessa dinamica. Le strutture programmate per espandersi fino a esaurire la memoria vengono individuate e rimosse, in modo che un file di piccole dimensioni non possa trasformarsi in uno enorme durante il processo; è proprio per questo motivo che si parla di “XML Bomb” (o “Billion Laughs”).
Ogni operazione di sanificazione viene registrata in un report forense in formato JSON. Il report include il nome dell'oggetto, il contenuto rimosso (con un limite massimo di 5.000 caratteri per voce) e l'hash SHA-256 dell'oggetto rimosso. I team di sicurezza dispongono così di una traccia di audit completa per la verifica della conformità e la ricostruzione degli incidenti, senza dover riesaminare il file originale.
Per una spiegazione completa dell'iniezione XML, dell'iniezione CDATA, delle "bombe XML" e delle relative dinamiche di attacco XML, consulta la nostra approfondimento tecnico sui vettori di attacco ai documenti XML.
Proteggi i tuoi flussi di lavoro con i file XML
Quando un parser affidabile si trova di fronte a un file XML dannoso, è il file ad avere la meglio. Apache Tika, Atlassian Crowd, IBM BAW e il percorso di analisi SVG ne sono la prova concreta in contesti quali le pipeline di documenti, le piattaforme di identità e i motori di workflow.
Questi file non vengono considerati minacce. Provengono da partner noti attraverso flussi di lavoro consolidati e contengono contenuti legittimi, ed è proprio questo che li rende efficaci. La soluzione non cambia da un CVE all’altro: intercettare a livello di trasferimento, depurare il file prima che raggiunga il parser e garantire che la protezione copra i file di dati XML esterni, non solo gli allegati e-mail e i file caricati sul web.
