Eclipse RDF4J CVE-2026-15803

Exploitation requires that the target application accepts and parses untrusted XML-based RDF data or SPARQL XML query results through one or more of RDF4J's XML parser entry points. Applications that parse only internally-generated RDF (e.g., data already stored in the triplestore) are not at risk. No authentication is required per the CVSS 4.0 PR:N metric, provided the parsing endpoint is externally reachable - but access control on the RDF ingestion interface (API key, network allowlist, authenticated SPARQL endpoint) would raise the effective bar for exploitation. Limiting factors: the attacker must be able to supply a document that reaches a vulnerable parser entry point; applications that transcode or validate input format before passing to RDF4J may break the exploit path. The vulnerability does not affect non-XML RDF serialisations (Turtle, N-Triples, JSON-LD) - only XML-based formats (RDF/XML, TriX, SPARQL XML Results) trigger the vulnerable code paths.

The CVSS 4.0 score of 8.7 reflects a fully unauthenticated, network-reachable, low-complexity path to high confidentiality impact with no subsequent-system impact (VC:H, VI:N, VA:N, SC:N). These signals align: XXE is reliably exploitable with a crafted document and no special attacker capability. EPSS data was not provided in the input, so probabilistic exploitation likelihood cannot be quantified here. KEV status is absent, and no POC has been identified in the provided references, indicating no confirmed active exploitation at time of analysis. The most significant amplifier is the incomplete-fix pedigree - defenders who believed CVE-2018-1000644 resolved XXE exposure in RDF4J may have deprioritised retesting, leaving patched-but-still-vulnerable deployments. The confidentiality-only CVSS profile (I:N, A:N) is consistent with typical XXE behaviour (file read, SSRF) and somewhat limits blast radius compared to RCE-class flaws, but credential and secret file exfiltration (e.g., /etc/passwd, cloud metadata endpoints, application.properties) represents a meaningful real-world risk.

An attacker submits a crafted RDF/XML document - for example via a SPARQL endpoint, a data import API, or any interface that passes XML-formatted RDF to an RDF4J parser - containing a DOCTYPE declaration that defines an external entity pointing to a sensitive local file such as /etc/passwd or a cloud instance metadata URL. When RDF4J's unpatched parser entry point processes the document, it resolves the entity and includes the file contents in the parsed output or a resulting error message, which the attacker reads from the response. No public exploit code has been identified at time of analysis, but XXE payloads of this form are well-documented and straightforward to construct.