exploiting-xslt-server-side-injection

Exploits server-side XSLT injection to achieve file read, SSRF, file write, and RCE.

954|172|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/xalgord/xalgorix --skill exploiting-xslt-server-side-injection
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: exploiting-xslt-server-side-injection
Source: https://github.com/xalgord/xalgorix/tree/main/internal/tools/skills/data/web-application-security/exploiting-xslt-server-side-injection
Command: npx skills add https://github.com/xalgord/xalgorix --skill exploiting-xslt-server-side-injection

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

During authorized penetration tests, applications that transform XML with attacker-influenced XSLT stylesheets are often under-tested because generic XXE payloads fail and testers stop there. This Skill provides a processor-aware methodology to fingerprint the XSLT engine and select the correct exploitation primitives instead of reporting false negatives.

Core Features & Use Cases

  • Processor Fingerprinting: Uses system-property() probes to identify libxslt, Saxon, Xalan, .NET, or MSXML engines before choosing payloads.
  • Multi-Primitive Exploitation: Covers local file read (document(), unparsed-text(), php:function), SSRF to cloud metadata endpoints, file write via exsl:document and xsl:result-document, and RCE through processor-specific extension functions like php:function, java.lang.Runtime, and msxsl:script.
  • Blind Confirmation Techniques: Confirms blind RCE and SSRF via out-of-band DNS/HTTP callbacks, time delays, and marker file writes.
  • Use Case: A PDF report generator transforms user-supplied XML with Saxon; the tester injects unparsed-text('/etc/passwd') to embed the password file in the generated PDF, proving file read impact.

Quick Start

Test the target's XML transformation endpoint for XSLT injection by first fingerprinting the processor and then exploiting it with the appropriate payloads.

Frequently Asked Questions about exploiting-xslt-server-side-injection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for XSLT injection in a web application?

Submit a stylesheet containing system-property('xsl:vendor') and system-property('xsl:version') probes to any endpoint that transforms XML. If the response reveals the vendor and version, injection is confirmed and you can select processor-specific payloads for file read, SSRF, or RCE.

What is the difference between document() and unparsed-text() in XSLT exploitation?

document() in libxslt parses the target as XML, so reading plain-text files like /etc/passwd often fails. Saxon's unparsed-text() reads any text file regardless of format, making it the reliable file-read primitive on XSLT 2.0 processors.

Can XSLT injection lead to remote code execution?

Yes, when processor extension functions are enabled. PHP libxslt allows php:function('shell_exec',...), Xalan and Saxon can invoke java.lang.Runtime, and .NET supports msxsl:script when EnableScript is true on .NET Framework.

Why does my XSLT file read payload fail on libxslt?

libxslt's document() function expects valid XML, so /etc/passwd returns a parse error. This does not mean the engine is hardened; try php:function('file_get_contents',...), DTD external entities, or SSRF via document() to a URL instead.

How do I confirm blind XSLT injection without visible output?

Use out-of-band techniques: trigger DNS or HTTP callbacks to a collaborator server with shell_exec('curl ...'), add time delays like sleep 10, or write a marker file to a web-served path and re-fetch it to prove the primitive.

Does hardening the XML parser prevent XSLT injection?

No. Applications often set resolve_entities=False or no_network=True on the XML parser but leave the stylesheet parser at defaults. XSLT features remain reachable, and xsl:include is fetched before lxml's XSLTAccessControl checks apply.