EUVD-2026-97469
GHSA-j929-4rw7-84fh
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify endpoint unmarshalling untrusted XML via JAXB
-
ExploitCraft XML with external entity referencing local file
-
ExecutionVulnerable JAXP resolves entity despite secure processing
-
ImpactExfiltrate file contents out-of-band to attacker server
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A02:2025 - Security Misconfiguration
ASVS 5.0
V13 - Configuration XML external entity prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Two conditions must both hold: (1) the application unmarshals attacker-influenced/untrusted XML through JAXB factory methods (XmlFactory in jaxb-ri core/xsom), and (2) the underlying JAXP/SAX/DocumentBuilder implementation is one where XMLConstants.FEATURE_SECURE_PROCESSING alone does NOT disable DOCTYPE/external general/parameter entities or external DTD loading - the pre-patch code set only that single feature. Limiting factors: on JAXP stacks where secure processing already blocks external entities (e.g., many default JDK/Xerces configurations) the flaw is not exploitable; exploitation requires the app to accept external XML; and AC:H reflects dependence on this non-default parser behavior. No authentication is required (PR:N) and no user interaction is needed. |
| Impact | The input CVSS 4.0 vector (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:L) scores 8.3 (High), driven by network reach, no privileges/no interaction, and high confidentiality impact (local file disclosure) - but tempered by AC:H. That AC:H is the decisive real-world signal: per the description, exploitation only succeeds on JAXP implementations where FEATURE_SECURE_PROCESSING alone does not block external entity resolution, a precondition outside the attacker's control. On the default JDK/Xerces JAXP stack, secure processing frequently does restrict external entities, so a large fraction of deployments may not be exploitable without a non-default JAXP provider. No EPSS score, CISA KEV listing, or public POC was provided, so there is no evidence of active or at-scale exploitation (no public exploit identified at time of analysis). SSVC decision data (exploitation/automatable/technical impact) was not supplied. Net: a legitimately serious XXE file-disclosure bug with a vendor patch available (Eclipse PR #2013), but conditional on the JAXP backend and on the application unmarshalling untrusted XML - prioritize patching for apps that ingest external XML, but this is not a drop-everything mass-exploitation scenario on current signals. |
| Exploit ScenarioDerived | An application uses JAXB to unmarshal XML it receives from an untrusted source (e.g., an API body, uploaded document, or message queue payload). On a JAXP backend where FEATURE_SECURE_PROCESSING does not by itself disable external entity resolution, an attacker submits XML containing an external entity that references a local file and triggers out-of-band exfiltration to an attacker-controlled server, disclosing file contents. No public POC is referenced, and the high attack complexity reflects dependence on the specific JAXP implementation's behavior. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Out-of-band XML External Entity (XXE) injection in Eclipse JAXB RI (jaxb-ri) lets an unauthenticated remote attacker read local files when an application unmarshals attacker-influenced XML through the affected JAXB factory helpers (XmlFactory in the core and xsom modules). The pre-patch code relied solely on XMLConstants.FEATURE_SECURE_PROCESSING, so on JAXP/SAX/DocumentBuilder implementations where that single feature does not disable DOCTYPE declarations, external general entities, external parameter entities, or external DTD loading, external entity resolution remains possible and file content can be exfiltrated out-of-band. Exploitation requires both conditions to hold - untrusted XML reaching JAXB unmarshalling, plus a parser stack where secure processing alone is insufficient - which is why the vector carries AC:H and the score is 8.3 (High) on both the supplied CVSS 4.0 vector and the independently assessed CVSS 3.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L). No confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
RemediationAI
Apply the upstream fix from https://github.com/eclipse-ee4j/jaxb-ri/pull/2013 - upstream fix available (PR/commit); released patched version not independently confirmed, so verify the fix is present in the specific JAXB RI release you consume (check that your artifact's XmlFactory sets disallow-doctype-decl, external-general-entities=false, external-parameter-entities=false and load-external-dtd=false, plus setExpandEntityReferences(false) for the DocumentBuilderFactory path) and cross-check the Eclipse advisory at https://gitlab.eclipse.org/security/cve-assignment/-/work_items/310 for the endorsed fixed version before upgrading. Where upgrading immediately is not possible, the most effective compensating control is to configure the JAXP parsers yourself before unmarshalling: on your own SAXParserFactory/DocumentBuilderFactory/XMLInputFactory, set disallow-doctype-decl to true (this alone blocks DOCTYPE-based XXE but will reject legitimate XML documents that carry a DOCTYPE, so validate your input contract first), or set external-general-entities, external-parameter-entities and load-external-dtd to false and expandEntityReferences to false (narrower, permits well-formed DOCTYPEs but blocks entity fetching). Because the vulnerable code path only hardens parsers when secure processing is enabled, do not pass a flag or system property that disables JAXB secure processing - that leaves the parser entirely unhardened and removes even the partial mitigation. Finally, treat XML from untrusted sources as hostile input at the application boundary: reject DTD-bearing payloads at the ingress gateway, and run the unmarshalling service with a least-privilege filesystem identity and no network egress so out-of-band exfiltration of local files is contained if a bypass is found.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
JAXB (Jakarta/Java Architecture for XML Binding) unmarshals XML into Java objects and internally constructs SAXParserFactory, DocumentBuilderFactory, and related JAXP factories through helper classes such as org.glassfish.jaxb.core.v2.util.XmlFactory in jaxb-ri/core and com.sun.xml.xsom.parser.XmlFactory in jaxb-ri/xsom. Historically these helpers hardened the parsers by setting only XMLConstants.FEATURE_SECURE_PROCESSING (unless the caller explicitly disabled secure processing). That reliance assumes the underlying JAXP implementation defaults to blocking external entity resolution once secure processing is on; the patch diff shows this assumption does not hold universally, leaving the classic CWE-611 Improper Restriction of XML External Entity Reference condition. The fix explicitly sets http://apache.org/xml/features/disallow-doctype-decl, http://xml.org/sax/features/external-general-entities, http://xml.org/sax/features/external-parameter-entities and http://apache.org/xml/features/nonvalidating/load-external-dtd to safe values, and additionally calls setExpandEntityReferences(false) on the DocumentBuilderFactory, whenever security is enabled. The affected surface is the JAXB/JAXP parsing layer itself, not the application's business logic, so the flaw propagates to any consumer of these factory methods that accepts external or untrusted XML. CPE data confirms the affected component is eclipse_foundation:jaxb-ri_(core), with the same hardening pattern applied to the xsom module in the same pull request. Authentication requirements are not confirmed from available data beyond the assessed vector, which shows PR:N (unauthenticated) - but exploitation is conditional on the two prerequisites described above.
Know when Jaxb Ri Core gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N
AV:N as XML may arrive remotely; AC:H because success depends on a JAXP backend not blocking entities under secure processing; PR:N/UI:N; C:H for local file read, A:L possible DoS, I:N.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
The JAXB factory methods historically relied solely on FEATURE_SECURE_PROCESSING to prevent XML External Entity (XXE) resolution. On JAXP implementations where that feature alone does not block external entity resolution, an attacker who can get untrusted XML unmarshalled through JAXB can read local files via out-of-band XXE.
Executive ViewAI
Eclipse JAXB RI, a widely embedded XML-binding library used across Java applications and services, contains an XML External Entity flaw that can allow an unauthenticated remote party to read and exfiltrate local files from any system that unmarshals attacker-influenced XML through the affected factory helpers. Because the library is a transitive dependency in many business applications, leadership should assume the exposure surface is broader than any single product team owns, and that any internet-facing or partner-facing Java service consuming XML is a candidate. Successful exploitation is conditioned on both untrusted XML reaching unmarshalling code and a parser stack where secure processing alone is insufficient, so this is a latent, broadly distributed risk rather than a confirmed active incident.
No vendor-released patch identified at time of analysis. Interim mitigations: set XMLConstants.ACCESS_EXTERNAL_DTD and XMLConstants.ACCESS_EXTERNAL_SCHEMA to empty strings, enable disallow-doctype-decl and disable external general and parameter entities and external DTD loading on all JAXB/JAXP parser factories, install a rejecting EntityResolver, and do not rely on FEATURE_SECURE_PROCESSING alone. Additionally, restrict outbound network egress to prevent out-of-band exfiltration, block inline DTDs at the WAF/API gateway, validate and constrain untrusted XML input, and apply least-privilege filesystem permissions on hosts that unmarshal XML.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
XML External Entity (XXE) attacks exploit XML parsers that process Document Type Definitions (DTDs) without proper restrictions.
Exploit-DB