In April 2022, researchers disclosed CVE-2022-24815, a critical remote-code-execution flaw in eXist-db, an open-source native XML database used by government archives, publishers, and research institutions worldwide. The root cause: unsanitized user input concatenated directly into RestXQ/XQuery expressions, letting attackers rewrite the query logic itself and execute arbitrary code on the server. This is XPath injection — the XML-query equivalent of SQL injection, formally cataloged by MITRE as CWE-643 ("Improper Neutralization of Data within XPath Expressions"). First documented publicly in Amit Klein's May 2004 whitepaper "Blind XPath Injection," the technique has quietly persisted for more than two decades inside login forms, SOAP/XML web services, SAML identity flows, and configuration systems that build XPath queries by concatenating strings instead of binding parameters. For a supply chain security company, XPath injection matters because it usually hides several layers deep — inside XML parsers, identity libraries, and legacy SOAP stacks that most application teams never directly audit.
What Is an XPath Injection Vulnerability?
An XPath injection vulnerability occurs when untrusted input is inserted into an XPath expression without proper neutralization, allowing an attacker to alter the logic of the query used to navigate an XML document. MITRE tracks this weakness class as CWE-643, and OWASP documents testing for it under WSTG-INPV-09 in the Web Security Testing Guide. XPath itself is a W3C query language for selecting nodes from XML documents — XPath 1.0 became a formal Recommendation on November 16, 1999, followed by XPath 2.0 in January 2007 and XPath 3.1 in March 2017 — and it is embedded everywhere XML is used: SAML assertions, SOAP envelopes, configuration files, and XML-backed user directories.
A classic vulnerable pattern looks like this in a login handler:
//users/user[username/text()='INPUT_USER' and password/text()='INPUT_PASS']
If the application drops raw form input into INPUT_USER and INPUT_PASS, an attacker who submits ' or '1'='1 as the username collapses the predicate into a tautology, and the query returns the first user node in the document — logging the attacker in without valid credentials. It is functionally identical to the ' OR '1'='1' SQL injection payload that has been abused against relational databases since the late 1990s, just aimed at an XML tree instead of a database table.
How Do Attackers Exploit XPath Injection in Practice?
Attackers exploit XPath injection either directly, forging a single boolean expression to bypass authentication in one request, or blindly, asking the application a long series of true/false questions to extract an entire XML document one character at a time. Klein's 2004 paper formalized the blind technique: by injecting functions like count(), substring(), and string-length() into a vulnerable query and observing whether the application returns a "true" or "false" response (a login success versus failure, or a results page versus an error page), an attacker can iteratively reconstruct usernames, password hashes, or any other data stored in the XML document without ever seeing raw output.
The eXist-db case (CVE-2022-24815) shows how much further this can go in modern XML databases. Because eXist-db exposes RestXQ endpoints that map HTTP requests directly to XQuery functions, and because affected versions before 5.3.1 failed to sanitize annotation values used to build those mappings, an unauthenticated attacker could inject arbitrary XQuery — not just read data, but execute code on the host. The advisory carried a near-maximum severity score, and the maintainers pushed a patched release the same month. It is a useful reminder that "XPath injection" and "XQuery injection" sit on the same spectrum: once an attacker controls part of a structured XML query, the blast radius depends entirely on what that query language is allowed to do.
Why Do XPath Injection Vulnerabilities Keep Appearing in 2026?
XPath injection vulnerabilities keep appearing because the XML-heavy systems that rely on it — SAML single sign-on, SOAP APIs, healthcare HL7 messaging, and XML-configured network and IoT devices — are still deeply embedded in enterprise and government infrastructure decades after JSON became the default for new APIs. OWASP has kept Injection as a top-tier risk category in every Top 10 release, including A03:2021-Injection in the September 2021 edition, and XPath injection sits squarely inside that category alongside SQL and command injection. Unlike SQL, which has near-universal prepared-statement support in every mainstream driver and ORM, XPath tooling is inconsistent: many teams don't realize javax.xml.xpath.XPathVariableResolver (available in Java since 2004) or .NET's parameterized XPathNavigator calls exist, so developers default to string concatenation because it "just works" in testing. Add in identity federation stacks that parse and query attacker-influenced SAML/XML payloads, and legacy enterprise software with support contracts stretching back 10–15 years, and the conditions for CWE-643 findings persist well past when most teams assume the risk retired with early-2000s web apps.
How Is XPath Injection Different from SQL Injection and XXE?
XPath injection, SQL injection, and XML External Entity (XXE) injection are distinct weaknesses that share a root cause — unsanitized input flowing into a structured query or parser — but differ in target and impact. SQL injection (CWE-89) manipulates queries against a relational database and can lead to data theft, tampering, or in some configurations command execution. XXE (CWE-611) abuses an XML parser's handling of external entity declarations to read local files, perform server-side request forgery, or exhaust resources, and is mitigated by disabling DTD processing entirely. XPath injection (CWE-643) instead manipulates the path expression used to select nodes within an already-parsed XML document, most commonly to bypass authentication logic or exfiltrate document contents through blind boolean or timing techniques. A single vulnerable code path can sometimes chain more than one of these — an XML endpoint that both resolves external entities and builds XPath queries from user input can be exploited via either weakness depending on which control is missing — which is why supply chain and application security reviews need to check all three independently rather than assuming a fix for one covers the others.
How Can Organizations Detect and Prevent XPath Injection?
Organizations prevent XPath injection primarily through parameterized queries, strict input validation, and least-privilege XML data access — the same defense-in-depth principles that eventually tamed SQL injection. In practice that means using variable-binding APIs instead of string concatenation (Java's XPathVariableResolver, .NET's parameterized XPathNavigator, or equivalent bind mechanisms in libraries like lxml and Saxon), rejecting or escaping XPath metacharacters such as ', ", /, [, ], and @ in any field that reaches a query, and running the XML data store under an account with read access scoped only to the documents a given user is authorized to see, so a successful injection still can't reach unrelated records. Detection relies on both static analysis, which flags string-concatenated calls to XPath.compile(), SelectNodes(), or evaluate() before code ships, and dynamic testing, which fuzzes input fields with classic payloads like ' or '1'='1 and blind-extraction functions to confirm whether an endpoint actually enforces the fix. Because XPath injection frequently arrives through a third-party library or framework component rather than first-party code, monitoring the software bill of materials for known-vulnerable XML processing dependencies — and patching within days of an advisory like eXist-db's April 2022 disclosure — is as important as fixing the query logic itself.
How Safeguard Helps
Safeguard treats XPath injection as a supply chain problem as much as a coding problem, because in most real incidents the vulnerable query logic lives inside a dependency — an XML database, a SAML library, a SOAP toolkit — rather than in code a team wrote and reviewed themselves. Safeguard's software bill of materials tooling identifies exactly which XML-processing and XPath/XQuery libraries are running in production, down to the patch version, so a disclosure like CVE-2022-24815 can be matched against your actual dependency graph in minutes instead of days of manual auditing. Continuous vulnerability monitoring flags newly published CWE-643 advisories against that inventory automatically and routes them to the teams that own the affected service. Static analysis integrated into CI/CD pipelines catches insecure XPath construction — string-concatenated queries built from request parameters — before the code merges, giving developers the fix (parameterized bindings) at the point of introduction rather than after a pen test finds it. And Safeguard's policy gates can block a build or deployment outright when it pulls in a library version with a known, unpatched XPath or XQuery injection flaw, closing the gap between disclosure and remediation that attackers routinely exploit in the first days after a CVE goes public. Together, these controls turn a class of vulnerability that has survived unnoticed in enterprise XML stacks since 2004 into something that's visible, tracked, and gated well before it reaches production.