Post cover image

September 18, 2026

Apache Struts 2 REST Plugin XStream Deserialization: When XML Requests Become Remote Code Execution

A trusted XML request should never be able to decide which Java objects your server creates.

By EternalSec

5 min read

A trusted XML request should never be able to decide which Java objects your server creates.

Introduction

During a Web/API Vulnerability Assessment, you may encounter a critical finding related to the Apache Struts 2 REST Plugin and its handling of XML requests.

This vulnerability is CVE-2017–9805, also tracked by Apache as S2–052. It affects vulnerable versions of the Struts 2 REST Plugin where the XStreamHandler used XStream to deserialize XML without adequate type filtering. NVD classifies it as CWE-502: Deserialization of Untrusted Data and currently lists a CVSS 3.1 score of 8.1 (High). It is also listed in CISA's Known Exploited Vulnerabilities catalog.

Apache described S2–052 as a possible Remote Code Execution vulnerability when the REST Plugin uses the XStream handler to process XML payloads.

What is Apache Struts 2?

Apache Struts 2 is a Java web application framework used for building web applications.

One of its components is the REST Plugin, which provides REST-style URL mapping and supports serialization/deserialization of data including XML and JSON.

A simplified application architecture looks like:

Client
   │
   │ HTTP Request
   ▼
Apache Struts 2
   │
   ├── Action / Controller
   │
   ├── REST Plugin
   │
   └── XML Handler
          │
          ▼
      Java Object

The vulnerability occurs in the way untrusted XML was converted into Java objects.

What is Deserialization?

To understand this vulnerability, first understand serialization and deserialization.

Serialization

Converting an object into a format that can be stored or transmitted.

Java Object
     ↓
  XML / JSON

Deserialization

Converting that data back into an object.

XML / JSON
     ↓
Java Object

The dangerous situation occurs when an application accepts attacker-controlled serialized data and creates objects from it without properly restricting what types can be instantiated.

Attacker-Controlled XML
          ↓
     Deserialization
          ↓
    Java Objects

This is the fundamental security problem behind CWE-502: Deserialization of Untrusted Data.

What is XStream?

XStream is a Java library used to serialize Java objects to XML and deserialize XML back into Java objects.

The Struts REST Plugin used an XStreamHandler for XML processing.

The vulnerable implementation did not provide adequate type filtering, meaning an attacker could potentially influence the types of objects created during deserialization.

What is the Vulnerability?

The vulnerable flow can be simplified as:

Attacker
   │
   │ Malicious XML
   ▼
Struts REST Endpoint
   │
   ▼
XStreamHandler
   │
   ▼
XStream Deserialization
   │
   ▼
Attacker-Controlled Object Creation
   │
   ▼
Potential RCE

The important point is:

The application trusts attacker-controlled XML during object deserialization.

If the vulnerable deserialization process can be chained with suitable Java classes available in the application's classpath, it can result in remote code execution.

Affected Versions

According to NVD, the affected Struts versions include:

Struts 2.1.1 – 2.3.x before 2.3.34
Struts 2.5.x before 2.5.13

Apache released Struts 2.3.34 to address S2–052 among other security issues.

So when you encounter this finding, don't rely only on the application's visible version banner. Verify the actual Struts and REST Plugin versions being deployed.

Why Does This Become RCE?

Normally, an API should accept data such as:

<user>
    <name>John</name>
</user>

and map it to an expected application object:

XML
 ↓
User object

The vulnerable behavior could allow an attacker to influence the type of object that XStream attempts to instantiate.

Conceptually:

Expected

XML → User Object

Vulnerable:
XML
 ↓
Attacker Influences Object Type
 ↓
Unexpected Java Object
 ↓
Gadget Chain
 ↓
Code Execution

This is where deserialization gadget chains become important.

A gadget chain is a sequence of existing classes and methods that, when constructed or invoked in a particular way during deserialization, can lead to an unintended security-sensitive operation.

How Can It Be Exploited?

For an authorized VAPT assessment, the exploitation process can be understood at a high level:

1. Identify Struts REST endpoint
             ↓
2. Determine whether XML input is accepted
             ↓
3. Identify vulnerable Struts / REST Plugin version
             ↓
4. Determine whether XStream deserialization is used
             ↓
5. Send controlled XML input
             ↓
6. Observe application behavior
             ↓
7. Validate whether unsafe object deserialization occurs

A vulnerable REST endpoint might look conceptually like:

POST /app/resource.xml
Content-Type: application/xml

The Struts REST Plugin supports XML as an incoming representation for REST resources.

Important VAPT distinction

A scanner finding or vulnerable version does not by itself prove RCE.

You should distinguish:

Vulnerable Version
       ≠
Confirmed RCE

To claim Remote Code Execution, you need evidence that the vulnerable deserialization path is actually reachable and exploitable in the target deployment.

For a production assessment, use a harmless proof of concept and obtain client authorization before attempting any command-execution validation.

Why Is This Vulnerability Serious?

The biggest concern is that exploitation can occur through a remote HTTP request.

The vulnerable endpoint may be exposed through a web application:

Internet
   │
   ▼
Web Server
   │
   ▼
Apache Struts
   │
   ▼
REST Plugin
   │
   ▼
XStream

If the vulnerable deserialization path is reachable without authentication, the attacker may not need an existing application account.

NVD's CVSS vector reflects:

AV:N / AC:H / PR:N / UI:N / S:U / C:H / I:H / A:H

with a score of 8.1 High.

Impact

If successfully exploited, the impact can be severe.

Confidentiality

An attacker could potentially access sensitive application or server data.

Application
     ↓
Sensitive Files
Credentials
Configuration
Database Information

Integrity

With code execution, an attacker may be able to modify application or system data.

Availability

An attacker with sufficient execution privileges could potentially disrupt the application or underlying server.

Therefore:

Remote Code Execution
        ↓
Code Execution Context
        ↓
Confidentiality
Integrity
Availability

The actual impact depends on the privileges of the application process and the server's security controls.

How to Verify the Finding

For VAPT, use multiple pieces of evidence.

1. Identify Apache Struts

Look for:

struts2-core
struts2-rest-plugin

in the deployed application libraries.

For example:

WEB-INF/lib/
    struts2-core-*.jar
    struts2-rest-plugin-*.jar

2. Determine the Version

Check the actual JAR metadata or dependency configuration rather than relying solely on HTTP banners.

3. Identify REST Endpoints

Look for endpoints accepting XML, such as:

/resource.xml
/api/resource.xml

The exact endpoint depends on the application's configuration.

4. Confirm XML Processing

Send a benign XML request appropriate to the application's expected schema and verify that the REST Plugin processes XML.

5. Validate the Deserialization Path

Determine whether the vulnerable XStreamHandler is actually being used.

This matters because modern Struts versions have changed the XML handling architecture. Apache's current REST Plugin documentation says that the default XML binding uses JacksonXmlHandler, while the older XStreamHandler is deprecated and scheduled for removal.

Don't Confuse Detection With Exploitation

This is particularly important when writing your VAPT report.

Suppose Nessus or another scanner says:

Apache Struts 2 REST Plugin XStream XML Request Deserialization RCE

That doesn't automatically mean:

"The server has been compromised."

Your assessment should establish:

Scanner Detection
       ↓
Version Verification
       ↓
REST Plugin Present
       ↓
XML Endpoint Present
       ↓
XStream Handler Used
       ↓
Safe Exploit Validation
       ↓
Confirmed / Not Confirmed

This produces much stronger evidence.

Recommendation

1. Upgrade Apache Struts

The primary remediation is to upgrade to a version containing the security fix.

Apache released Struts 2.3.34 with the S2–052 fix, and the affected 2.5 branch was fixed in 2.5.13.

For modern environments, use a currently supported Struts release rather than deliberately remaining on an old 2.x release.

2. Avoid Unsafe XStream Deserialization

If the application has explicitly configured the REST Plugin to use XStreamHandler, review that configuration.

Current Apache documentation states that XStreamHandler is deprecated and recommends migrating applications that explicitly override XML handling to JacksonXmlHandler.

3. Restrict Deserialization

If XStream must be used for a specific application requirement, implement strict class/type allowlisting rather than allowing arbitrary classes.

4. Remove Unnecessary XML Processing

If the application doesn't require XML input, disable unnecessary XML endpoints/content types where practical.

5. Rescan

After remediation:

Upgrade Struts
      ↓
Review REST Configuration
      ↓
Restart Application
      ↓
Verify Version
      ↓
Test XML Endpoint
      ↓
Nessus / VAPT Rescan