În ianuarie 2026, OPSWAT a publicat o analiză a CVE-2025-66516, o vulnerabilitate critică în Apache Tika declanșată de un fișier PDF rău intenționat care ajungea la un parser din backend. Soluția a fost simplă: curățarea fișierului înainte ca acesta să ajungă la parser, astfel încât parserul să nu vadă niciodată încărcătura. Aceasta a funcționat deoarece exista un singur parser, un singur tip de fișier și o singură bibliotecă cunoscută.
Dar ce se întâmplă dacă fișierul XML nu este un PDF, ci un fișier de configurare importat într-o platformă SSO (Single Sign-On), o definiție de flux de lucru trimisă către un motor de automatizare financiară sau un set de date medicale procesat de un sistem de integrare spitalicească? Aceste fișiere circulă zilnic între organizații, contractori, autorități de reglementare și parteneri, ajungând prin intermediul serviciilor de transfer gestionat de fișiere și al portalurilor partenerilor ca date de afaceri de încredere. Majoritatea soluțiilor de curățare a datelor nu le verifică niciodată.
XML este limbajul industriei, și tocmai asta este problema
Atacurile XXE (XML External Entity) de tip PDF și SVG au același tipar: un utilizator încarcă un fișier; o bibliotecă din backend îl analizează; analizatorul execută încărcătura. Punctul de intrare este vizibil.
XML-ul din sectorul industrial este diferit. Este vorba despre transferuri între întreprinderi, importuri de configurații și date transmise de la un sistem la altul, provenind de la parteneri, autorități de reglementare, contractanți și furnizori cunoscuți. Tocmai această aparentă legitimitate este motivul pentru care acestea scapă de controlul aplicat încărcărilor de pe web.
XML este integrat în modul de funcționare al multor sectoare de activitate:
- Servicii financiare: mesajele SWIFT, instrucțiunile FIX (Financial Information eXchange) și plățile conform standardului ISO 20022 sunt toate în format XML.
- Sănătate: HL7 (Health Level Seven) și FHIR (Fast Healthcare Interoperability Resources), protocoalele standard de schimb de date medicale, sunt bazate pe XML. O entitate rău intenționată dintr-un conținut FHIR poate trece neobservată prin orice sistem care verifică structura, dar nu și DOCTYPE-ul.
- IT pentru întreprinderi: Platformele de identitate și SSO preiau fișiere de configurare XML în timpul integrării, migrării și procesului de integrare a noilor utilizatori. O singură operațiune de import poate acoperi toate aplicațiile pe care platforma le autentifică.
- OT: Sistemele SCADA și cele de gestionare a energiei fac schimb de date în formate XML definite de standardele IEC 61968 și 61970, adesea traversând granițele dintre IT și OT, unde măsurile de control sunt minime.
În toate cazurile, încărcătura utilă nu este un script sau o macro, ci se află în stratul de conținut al fișierului XML: o declarație DOCTYPE care face referire la o entitate externă ce indică o cale către un fișier local sau un punct final intern. Atunci când analizorul procesează fișierul, acesta preia conținutul respectiv.
Deși fișierul este valid din punct de vedere structural în urma verificării schemei, conținutul său necesită un nivel mai aprofundat de curățare, de exemplu în ceea ce privește declarația DOCTYPE sau destinația entității.
Aceasta nu este o problemă legată de moștenirea trecutului
XXE a fost descris în 2003 și inclus în Top 10 OWASP în 2017, ceea ce determină uneori echipele să îl considere o problemă rezolvată. Datele din 2025 și 2026 indică însă altceva, iar cazurile relevante pentru securitatea fișierelor sunt cele în care încărcătura ajunge sub formă de fișier.
- lxml (CVE-2026-41066): configurația implicită a analizorului dintr-o bibliotecă Python pentru XML, utilizată pe scară largă, permitea unui fișier XML neîncredibil să citească fișiere locale. lxml este aceeași bibliotecă pe care svglib o folosește pentru a analiza fișiere SVG (Scalable Vector Graphics), iar vulnerabilitatea de tip „path- OPSWAT ” transmisă prin fișier a fost demonstrată în articolul de pe blogul SVG XXE din 2024. Curățarea fișierului elimină entitatea înainte ca analizorul să o detecteze.
- Atlassian Crowd (CVE-2026-21569, CVSS 7,9 – Risc ridicat): o platformă de autentificare unică (SSO) și de gestionare a identităților. O încărcătură XML special concepută îi permite atacatorului să obțină acces la fișiere la nivel local sau de la distanță, iar calificativul CVSS „Scope:Changed” înseamnă că o exploatare reușită afectează toate aplicațiile autentificate de Crowd. Fișierul XML ajunge sub forma unui fișier de configurare sau de integrare importat de la un partener sau de pe stația de lucru a unui administrator.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 Ridicat): IBM BAW procesează fișiere XML în fluxuri de lucru precum inițierea împrumuturilor și procesarea cererilor de despăgubire. Vulnerabilitatea permite divulgarea fișierelor și SSRF (Server-Side Request Forgery), permițând unui atacator să acceseze terminale interne, iar aceeași structură DOCTYPE poate determina extinderea entităților pentru a provoca un atac DoS (Denial of Service). Fișierele XML sunt transmise prin portalurile partenerilor de către experți în daune, autorități de reglementare și integratori.
Toate indică o singură formă comună: un fișier XML de afaceri de încredere care conține un DOCTYPE, care ajunge printr-un flux de lucru stabilit înainte de a ajunge la un analizor vulnerabil.
O precizare privind domeniul de aplicare: acest blog tratează vulnerabilitatea XXE care se manifestă sub forma unui fișier. Fișierele XML și formatele bazate pe XML, precum SVG, PDF cu XFA și fișierele Office, care trec printr-un flux de lucru de curățare, sunt reconstituite fără vulnerabilități. Cazurile legate de fișiere sunt cele mai frecvente: încărcări, importuri de configurații, schimbul de date cu partenerii și atașamente de e-mail. XXE accesat printr-un corp de cerere brut de tip „ API ” sau printr-un apel de parsare în cod nu implică transferul unui fișier, astfel încât o poartă de igienizare a fișierelor nu se află în acea cale.
Modul în care tehnologia Deep CDR™ gestionează fișierele XML independente
Tehnologia Deep CDR™ suportă XML 1.0 și 1.1, precum și formatele conexe bazate pe XML, inclusiv ZEI, JNLP, TDS, RDF, BML, MPD și TTML, toate în cadrul aceluiași motor.
În cazul fișierelor XML, referințele care indică în afara documentului sunt respinse în mod implicit, iar DOCTYPE-ul și referințele sale la entități externe nu sunt păstrate în fișierul reconstruit. Niciunul dintre aceste comportamente nu reprezintă o politică care trebuie identificată și ajustată. Atâta timp cât conținutul XML extern este dirijat prin fluxul de lucru de curățare din MetaDefender Core™, protecția se aplică.
Pe lângă această eliminare implicită a DOCTYPE-ului, operatorii dispun de opțiuni suplimentare pe care le pot configura în funcție de mediul lor de lucru
- Eliminare macro: elimină macro-urile VBA codificate în formatele Office bazate pe XML
- Eliminarea secțiunilor CDATA: patru opțiuni de politică graduale, de la „Nu se face nimic” până la „Se elimină tot”, oferind echipelor controlul asupra gradului de rigurozitate cu care sunt tratate secțiunile CDATA, în funcție de gradul de confidențialitate al fluxului de lucru
- Eliminarea injecțiilor: tratează problema injecțiilor XML și a codului JavaScript din stratul de conținut încorporat în valorile elementelor
- Prelucrarea datelor codificate în format Base64: gestionează încărcăturile utile codificate încorporate în valorile XML, inclusiv tiparele schemei URL de date
O măsură de protecție conexă acoperă cealaltă latură a aceleiași direcții. Structurile concepute să se extindă până la epuizarea memoriei sunt detectate și eliminate, astfel încât un fișier mic nu poate deveni unul uriaș pe parcurs, motiv pentru care s-a ajuns la denumirea de „XML Bomb” (sau „Billion Laughs”).
Fiecare acțiune de curățare este înregistrată într-un raport JSON de tip criminalistic. Raportul include numele obiectului, conținutul eliminat (cu o limită maximă de 5.000 de caractere pe intrare) și hash-ul SHA-256 al obiectului eliminat. Echipele de securitate dispun de o pistă de audit completă pentru verificarea conformității și reconstituirea incidentelor, fără a fi nevoie să reexamineze fișierul original.
Pentru o explicație detaliată a injecției XML, a injecției CDATA, a „bombelor” XML și a mecanismelor de atac XML asociate, consultați analiza tehnică aprofundată privind vectorii de atac asupra documentelor XML.
Protejați-vă fluxurile de lucru cu fișiere XML
Atunci când un analizor de încredere se confruntă cu un fișier XML rău intenționat, fișierul are câștig de cauză. Apache Tika, Atlassian Crowd, IBM BAW și calea de analiză SVG demonstrează acest lucru în cadrul fluxurilor de documente, al platformelor de identitate și al motoarelor de flux de lucru.
Aceste fișiere nu sunt considerate amenințări. Ele provin de la parteneri cunoscuți, prin intermediul unor fluxuri de lucru stabilite, și conțin conținut legitim, ceea ce le conferă eficacitate. Soluția nu se schimbă de la un CVE la altul: interceptarea la nivelul stratului de transfer, curățarea înainte ca fișierul să ajungă la analizor și asigurarea faptului că protecția acoperă fișierele externe de date XML, nu doar atașamentele din e-mailuri și fișierele încărcate pe web.
