xslt-injection

A security-testing playbook for XSLT injection, used when user-controlled XSLT or stylesheet input, or transform endpoints, are in scope for authorized testing. The vulnerability arises when attacker-influenced XSLT is compiled or executed server-side, and the recommended methodology maps the processor family first, then chains the appropriate escalation per platform. Many payloads are noted as destructive, so it is framed for authorized testing only.

The workflow starts by finding sinks (parameters named xslt, stylesheet, transform, or template, plus SOAP stylesheets, report generators, and XML-to-HTML converters), probing for reflection with a harmless marker, and fingerprinting the engine via system-property reads that reveal vendors such as Xalan (Java), Saxon, libxslt, or MSXML/.NET. Escalation paths are organized by capability: external entity (XXE) injection through DTD entities; local file read via the document() function; server-side request forgery and out-of-band interaction using document() against http URLs; arbitrary file write via the EXSLT exslt:document extension; and remote code execution surfaces that depend on platform configuration, namely PHP via php:function (for example readfile, scandir, or historically preg_replace with the /e modifier), Java via Saxon/Xalan extension functions mapping to static methods like Runtime.exec, and .NET via msxsl:script script blocks.

Throughout, the guidance notes that hardened parsers and secure defaults often disable external DTDs, extensions, and script blocks, so a failed vector does not disprove others, and testers are advised to pivot between document(), XXE, SSRF, and platform-specific paths. It cross-references related skills for generic XML external entity testing and for SSRF, and includes a decision tree to route from user-influenced transforms to the most promising technique.