2026 januárjában a OPSWAT közzétette a CVE-2025-66516 elemzését, amely az Apache Tika egy kritikus sebezhetőségét amelyet egy rosszindulatú PDF-fájl váltott ki, miután eljutott a háttérben futó elemzőhöz. A javítás egyszerű volt: a fájlt megtisztítják, mielőtt eljutna az elemzőhöz, így az elemző soha nem látja a rosszindulatú tartalmat. Ez azért működött, mert csak egy elemző, egy fájltípus és egy ismert könyvtár volt.
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áshivatkozásai nem kerülnek át a rekonstruált fájlba. Egyik viselkedés sem olyan szabály, amelyet fel kell fedezni és be kell állítani. Mindaddig, amíg a külső XML-adatokat az MetaDefender Core™ tisztítási munkafolyamatán keresztül irányí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.
Az XML-befecskendezés, a CDATA-befecskendezés, az XML-bombák és a kapcsolódó XML-támadási mechanizmusok részletes ismertetését lásd a XML-dokumentumok támadási vektorairól szóló részletes technikai elemzésünket.
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.
