CVE-2024-36522 Overview
CVE-2024-36522 affects Apache Wicket, a component-based Java web application framework. The default configuration of XSLTResourceStream.java accepts untrusted input without validation. Attackers can exploit this design flaw to perform XSLT injection and achieve remote code execution. The vulnerability requires no authentication and can be triggered over the network. Apache assigned the issue to versions before 10.1.0, 9.18.0, and 8.16.0. The flaw is classified under [CWE-74] as improper neutralization of special elements in output used by a downstream component (injection).
Critical Impact
Unauthenticated attackers can execute arbitrary code on servers running vulnerable Apache Wicket applications that process attacker-controlled input through XSLTResourceStream.
Affected Products
- Apache Wicket 8.x prior to 8.16.0
- Apache Wicket 9.x prior to 9.18.0
- Apache Wicket 10.0.0 (including milestone1 and milestone2) prior to 10.1.0
Discovery Timeline
- 2024-07-12 - CVE-2024-36522 published to NVD
- 2024-07-12 - Apache publishes advisory on the official mailing list
- 2025-07-10 - Last updated in NVD database
Technical Details for CVE-2024-36522
Vulnerability Analysis
The XSLTResourceStream class in Apache Wicket transforms XML data using XSLT (Extensible Stylesheet Language Transformations) stylesheets. The default configuration enables external function calls and extension elements within the XSLT processor. When an application passes untrusted input into the transformation pipeline, an attacker can supply a malicious stylesheet that invokes Java runtime methods. This behavior allows code execution within the Wicket application context.
XSLT injection is a well-documented class of injection vulnerability tracked under [CWE-74]. The EPSS score of 8.266% places this issue in the 92nd percentile for exploitation likelihood, indicating elevated attacker interest in Apache Wicket deployments.
Root Cause
The root cause is the unsafe default configuration of the XSLT processor used by XSLTResourceStream.java. The transformer factory does not disable extension functions, external entity resolution, or secure processing features. Wicket applications that pass user-controllable XML or XSLT data to this class inherit the insecure defaults without explicit warning.
Attack Vector
An attacker submits crafted XML or XSLT content to a Wicket endpoint that processes resources through XSLTResourceStream. The malicious stylesheet uses XSLT extension elements to invoke Java classes such as java.lang.Runtime and execute operating system commands. Because the attack vector is network-based and requires no authentication or user interaction, exploitation can be fully automated against exposed applications.
No public proof-of-concept code is currently linked in the advisory. Refer to the Apache Mailing List Thread and the OpenWall OSS Security Update for technical context.
Detection Methods for CVE-2024-36522
Indicators of Compromise
- Unexpected child processes spawned by the Java application server (for example sh, bash, cmd.exe, or powershell.exe) parented to the Wicket process.
- Outbound network connections initiated by the JVM to unfamiliar hosts shortly after HTTP requests containing XML or XSL payloads.
- HTTP request bodies or parameters containing xsl:stylesheet, xsl:value-of, or references to java.lang.Runtime and ProcessBuilder.
- New or modified files in the application working directory written by the Java process.
Detection Strategies
- Inspect web application logs for requests targeting Wicket resource endpoints that include XML, XSL, or XSLT content types.
- Apply web application firewall rules that flag XSLT extension element prefixes and references to xalan:// or xsltc:// namespaces.
- Monitor JVM process trees for unexpected execution of operating system shells or scripting interpreters.
- Review dependency manifests (pom.xml, build.gradle) for vulnerable Apache Wicket versions across the application portfolio.
Monitoring Recommendations
- Enable verbose logging on Wicket resource handlers and forward events to a centralized analytics platform.
- Establish behavioral baselines for the Wicket application's child process activity and outbound connectivity.
- Correlate authentication-free POST requests to resource endpoints with subsequent process or network anomalies.
How to Mitigate CVE-2024-36522
Immediate Actions Required
- Upgrade Apache Wicket to version 10.1.0, 9.18.0, or 8.16.0 depending on the deployed branch.
- Audit application code for direct or indirect use of XSLTResourceStream with user-controllable inputs.
- Restrict network access to Wicket-based applications until patches are applied.
- Rotate credentials and secrets accessible to the application process if compromise is suspected.
Patch Information
Apache released fixed versions 10.1.0, 9.18.0, and 8.16.0. Details are available in the Apache Mailing List Thread and the OpenWall OSS Security Update. Update the org.apache.wicket:wicket-core dependency in Maven or Gradle build files and redeploy the application.
Workarounds
- Remove or replace any application code paths that pass untrusted input to XSLTResourceStream.
- Wrap XSLT transformations in a custom TransformerFactory with FEATURE_SECURE_PROCESSING enabled and extension functions disabled.
- Deploy a web application firewall rule set that blocks XSLT and XML payloads on endpoints that do not require them.
# Configuration example - update Maven dependency to a patched version
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-core</artifactId>
<version>10.1.0</version>
</dependency>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


