In January 2026, OPSWAT published analysis of CVE-2025-66516, a critical vulnerability in Apache Tika triggered by a malicious PDF reaching a backend parser. The fix was clean: sanitize the file before it reaches the parser, and the parser never sees the payload. That worked because there was one parser, one file type, and one known library.
Mi van viszont akkor, ha az XML nem PDF, hanem egy SSO (Single Sign-On) platformba importált konfigurációs fájl, egy pénzügyi automatizálási motorhoz elküldött munkafolyamat-leírás, vagy egy kórházi integrációs rendszer által feldolgozott egészségügyi adatcsomag? Ezek a fájlok nap mint nap áramlanak szervezetek, alvállalkozók, szabályozó hatóságok és partnerek között, és felügyelt fájlátvitel vagy partnerportálok révén érkeznek be megbízható üzleti adatokként. A legtöbb adatmegtisztító megoldás soha nem vizsgálja meg őket.
Az XML az ipar nyelve, és éppen ez a probléma
A PDF- és SVG-fájlok ellen indított XXE-támadások (XML External Entity) hasonló mintát követnek: a felhasználó feltölt egy fájlt; egy háttérkönyvtár feldolgozza azt; az elemző futtatja a kártékony kódot. A behatolási pont nyilvánvaló.
Az iparági XML-fájlok esetében más a helyzet. Ezek vállalatok közötti adatátvitelek, konfigurációs importok, valamint ismert partnerektől, szabályozó hatóságoktól, alvállalkozóktól és beszállítóktól érkező, rendszerről rendszerre továbbított adatcsomagok. Pontosan ez a látszólagos legitimitás az oka annak, hogy elkerülik a webes feltöltésekre alkalmazott ellenőrzést.
Az XML számos iparág működésének szerves részét képezi:
- Pénzügyi szolgáltatások: A SWIFT-üzenetek, a FIX (Financial Information eXchange) utasítások és az ISO 20022 szerinti fizetések mind XML formátumúak.
- Egészségügy: Az HL7 (Health Level Seven) és az FHIR (Fast Healthcare Interoperability Resources) – az egészségügyi adatcsere szabványos protokolljai – XML-alapúak. A FHIR-adatcsomagban található rosszindulatú elem átjut minden olyan rendszeren, amely a szerkezetet ellenőrzi, de a DOCTYPE-ot nem.
- Vállalati informatika: Az identitáskezelő és SSO-platformok az integráció, az áttérés és az új felhasználók bevonása során XML-konfigurációs fájlokat olvasnak be. Egyetlen importálással elérhetők az összes olyan alkalmazás, amelynek hitelesítését a platform végzi.
- OT: A SCADA- és az energiagazdálkodási rendszerek az IEC 61968 és 61970 szabványokban meghatározott XML-formátumokban cserélnek adatokat, gyakran az IT/OT határok átlépésével, ahol a biztonsági ellenőrzések minimálisak.
Minden esetben a hasznos adat nem szkript vagy makró, hanem az XML tartalmi rétegében található: egy DOCTYPE-deklaráció, amely egy külső entitásra hivatkozik, amely pedig egy helyi fájl elérési útjára vagy egy belső végpontra mutat. Amikor az elemző feldolgozza a fájlt, letölti ezt a tartalmat.
Bár a fájl szerkezetileg érvényes a sémavizsgálat szerint, tartalmát alaposabban ellenőrizni kell, például azt, hogy mit határoz meg a DOCTYPE, vagy hová mutat az entitás.
Ez nem egy múltból örökölt probléma
Az XXE-t 2003-ban írták le, és 2017-ben felvették az OWASP Top 10 listájára, ami miatt a csapatok néha úgy tekintenek rá, mintha már megoldott probléma lenne. A 2025-ös és 2026-os adatok azonban másról tanúskodnak, és a fájlbiztonság szempontjából azok az esetek számítanak, amikor a hasznos adat fájl formájában érkezik.
- lxml (CVE-2026-41066): egy széles körben használt Python XML-könyvtár alapértelmezett elemzőkonfigurációja lehetővé tette, hogy megbízhatatlan XML-fájlok hozzáférjenek a helyi fájlokhoz. Az lxml ugyanaz a könyvtár, amelyet az svglib is használ az SVG (Scalable Vector Graphics) fájlok elemzéséhez; az „ OPSWAT ” nevű, fájlon keresztüli támadási útvonalat a svglib a 2024-es SVG XXE-ről szóló blogbejegyzésében mutatta be. A fájl tisztításával az entitás eltávolítható, mielőtt az elemző feldolgozná.
- Atlassian Crowd (CVE-2026-21569, CVSS 7,9 – Magas): egy SSO- és identitáskezelő platform. Egy speciálisan kialakított XML-adatcsomag helyi vagy távoli fájlhozzáférést biztosít a támadónak, és a CVSS „Scope:Changed” besorolás azt jelenti, hogy egy sikeres támadás minden olyan alkalmazást elér, amelyet a Crowd hitelesít. Az XML-adatcsomag egy partner vagy rendszergazdai munkaállomásról érkezik konfigurációs vagy integrációs importként.
- IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 Magas): Az IBM BAW XML-fájlokat dolgoz fel olyan munkafolyamatokban, mint a hitelnyújtás és a kárigény-feldolgozás. A sebezhetőség lehetővé teszi a fájlok nyilvánosságra hozatalát és az SSRF-t (Server-Side Request Forgery), ami révén a támadó belső végpontokra tud átterjedni; emellett ugyanaz a DOCTYPE-struktúra a DoS (Denial of Service) támadáshoz vezető entitás-kiterjesztést is előidézhet. Az XML-fájlok partnerportálokon keresztül érkeznek kárrendezőktől, szabályozó hatóságoktól és integrátoroktól.
Mindez egy közös mintára utal: egy megbízható üzleti XML-fájlra, amely DOCTYPE-adatot tartalmaz, és egy kialakult munkafolyamaton keresztül érkezik, mielőtt egy sebezhető elemzőhöz jutna.
Egy megjegyzés a hatályról: ez a blogbejegyzés azokat az XXE-támadásokat tárgyalja, amelyek fájl formájában érkeznek. Az XML, valamint az XML-alapú formátumok – mint például az SVG, az XFA-val ellátott PDF és az Office-fájlok –, amelyek átmennek egy tisztítási munkafolyamaton, hibamentes állapotban kerülnek visszaállításra. A fájlon keresztül terjedő esetek a leggyakoribbak: feltöltések, konfigurációs importok, partneri adatcsere és e-mail mellékletek. Az olyan XXE-támadások, amelyek nyers API kérés testén vagy kódon belüli elemzési híváson keresztül érkeznek, nem járnak fájlátvitellel, így a fájltisztító átjáró nem szerepel az útvonalban.
Hogyan kezeli a Deep CDR™ technológia az önálló XML-fájlokat?
A Deep CDR™ technológia ugyanazon a motoron belül támogatja az XML 1.0 és 1.1 szabványokat, valamint a kapcsolódó XML-alapú formátumokat, többek között a ZEI, JNLP, TDS, RDF, BML, MPD és TTML formátumokat.
XML-fájlok esetében a dokumentumon kívülre mutató hivatkozásokat alapértelmezés szerint elutasítja a rendszer, és a DOCTYPE, valamint annak külső entitás-hivatkozásai nem kerülnek át a rekonstruált fájlba.
Egyik viselkedés sem olyan szabály, amelyet meg kell találni és be kell állítani. Mindaddig, amíg a külső XML-adatokat az MetaDefender Core™ tisztítási munkafolyamatán keresztül továbbítják, a védelem érvényben marad.
Ezen alapértelmezett DOCTYPE-eltávolításon túl a rendszergazdák további beállításokat is konfigurálhatnak a környezetükhöz igazodva
- Makró eltávolítása: eltávolítja az XML-alapú Office-formátumokban kódolt VBA-makrókat
- CDATA eltávolítása: négy fokozatos beállítási lehetőség, a „Semmit ne tegyen”től a „Mindent eltávolítson”ig, amelyek lehetővé teszik a csapatok számára, hogy a munkafolyamat érzékenységétől függően maguk határozzák meg, milyen szigorúan kezeljék a CDATA-szakaszokat
- Injekció eltávolítása: az XML-injekciót és az elemértékekbe ágyazott, tartalmi rétegű JavaScript-kódokat kezeli
- Base64-kódolt adatok feldolgozása: kezeli az XML-értékekbe ágyazott kódolt hasznos adatokat, beleértve az adat-URL-séma mintáit is
Egy ehhez kapcsolódó védelmi mechanizmus ugyanazon irány másik oldalát is lefedi. Azokat a struktúrákat, amelyek úgy lettek megírva, hogy a memória kimerüléséig bővüljenek, a rendszer felismeri és eltávolítja; így egy kis fájl nem válhat hatalmas méretűvé a feldolgozás során – éppen ezért kapták az ilyen esetek az „XML Bomb” (vagy „Billion Laughs”) nevet.
Minden tisztítási műveletet egy nyomozati célú JSON-jelentés rögzít. A jelentés tartalmazza az objektum nevét, az eltávolított tartalmat (bejegyzésenként legfeljebb 5 000 karakter) és az eltávolított objektum SHA-256 hash-értékét. A biztonsági csapatok így teljes ellenőrzési nyomvonalhoz jutnak a szabályozási megfelelés felülvizsgálatához és az incidensek rekonstruálásához anélkül, hogy újra meg kellene vizsgálniuk az eredeti fájlt.
For a full explanation of XML injection, CDATA injection, XML bombs, and related XML attack mechanics, see our technical deep dive on XML document attack vectors.
Védje meg XML-fájl-munkafolyamatait
Amikor egy megbízható elemző rosszindulatú XML-fájllal találkozik, a fájl kerül ki győztesen. Az Apache Tika, az Atlassian Crowd, az IBM BAW és az SVG-elemzési útvonal egyaránt alátámasztják ezt a megállapítást a dokumentum-feldolgozási folyamatok, az identitáskezelő platformok és a munkafolyamat-motorok területén.
Ezeket a fájlokat nem tekintik fenyegetésnek. Ismert partnerektől érkeznek, bevált munkafolyamatok keretében, és legitim tartalmat hordoznak – éppen ez teszi őket hatékonnyá. A megoldás az egyes CVE-k esetében nem változik: az átviteli rétegen kell elfogni őket, megtisztítani, mielőtt a fájl eléri az elemzőt, és gondoskodni arról, hogy a védelem kiterjedjen a külső XML-adatfájlokra is, ne csak az e-mail-mellékletekre és a webes feltöltésekre.
