XSLT Injection is a vulnerability where untrusted input is inserted into an XSLT stylesheet or transformation context and changes how XML is processed. Attackers can use it to read data, alter output, or trigger server-side requests when the transformation engine is exposed. Defenders must treat XSLT input as code, not data.
XSLT Injection and why it matters
XSLT injection happens when untrusted data is treated as part of a stylesheet or transformation expression, so the attacker influences how XML is processed. Because the transformation layer can execute logic, fetch resources, or reshape output, this becomes a code-execution style flaw rather than a simple validation error.
That distinction matters because XSLT is often used deep inside XML handling pipelines, where developers assume the stylesheet boundary is trusted. If attacker-controlled content reaches that boundary, the transformation engine may reveal data, produce tampered output, or reach out to internal or remote resources in ways the application did not intend.
How XSLT injection works
The vulnerability usually appears when an application concatenates user input into XPath, XSLT parameters, or dynamically generated stylesheet fragments. The issue is not XML alone, but the point at which input changes the transformation program itself.
In practical terms, an attacker looks for any place where the application lets them influence template names, expressions, include paths, document references, or parameters passed into the transformer. Once they control those values, the transformation engine may evaluate attacker-chosen logic instead of the intended rules.
This is why XSLT injection is often grouped with other injection flaws, but it is its own class. The dangerous part is the shift from data handling to instruction handling, which can produce effects such as data extraction, output tampering, or server-side request activity.
Attack paths and security consequences
XSLT injection can expose sensitive XML contents, such as configuration data, internal documents, or identity and business records that were never meant to leave the transformation boundary. If the engine supports external document access or extension functions, the blast radius can expand quickly.
In some environments, the transformation context can also be used to trigger server-side requests, turning the flaw into a pivot for internal reconnaissance or data retrieval. This is why defenders should treat XSLT handling as part of the application attack surface, not as a harmless formatting layer.
For a broader view of how XSLT injection fits into the wider family of web exploitation patterns, the Web Application Attacks Guide is the best internal starting point.
Defensive design and validation patterns
The safest design is to keep stylesheets static and pass only structured, prevalidated data into the transformation layer. If the application must vary the transformation, restrict that variability to controlled parameters rather than letting users modify stylesheet syntax or expression logic.
Input handling should assume that any value reaching the XSLT engine may affect execution flow. That means avoiding string concatenation into templates, disallowing unsafe extension features where possible, and using allowlists for any configurable transformation options.
Because this issue sits at the intersection of XML processing and injection defense, organisations should review both application code and parser or transformer configuration. The relevant risk is not just malformed input, but untrusted input that becomes executable transformation logic.
For readers wanting a baseline web-application risk reference, the OWASP Top 10 remains the clearest external starting point for situating XSLT injection within broader injection and server-side abuse patterns.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | XSLT injection is an input-handling flaw where untrusted text becomes executable transformation logic. |
| V15 — Secure Coding and Architecture | The issue arises from unsafe dynamic composition of transformation code and data. | |
| V16 — Security Logging and Error Handling | Transformation errors and unusual parser behaviour can expose exploitation attempts or leaked data. | |
| Recommendation — Validate and encode any data that reaches XSLT templates or parameters before it can alter transformation logic. Design XML transformation paths so user input cannot change stylesheet structure or execution flow. Log XSLT failures and suspicious transformation inputs so exploitation attempts are visible during review. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The flaw is caused by untrusted input altering how transformation code is processed. |
| Recommendation — Validate XML and XSLT inputs so attacker-controlled content cannot change processing behaviour. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | XSLT injection is an application-layer injection weakness needing secure development and testing. |
| Recommendation — Test XML transformation code for injection paths and remove any dynamic stylesheet construction. | ||