Is CVE-2017-9805 (Apache Struts Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2017-9805 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apache Struts REST Plugin uses an XStreamHandler with an instance of XStream for deserialization without any type filtering, which can lead to remote code execution when deserializing XML payloads.

What “Exploited in the Wild” Means for This CVE

For a vulnerability like CVE-2017-9805, the practical question is not whether the flaw exists, but whether attackers are already using it as a reliable entry point. CISA’s KEV listing is the clearest operational signal that this is not just a theoretical issue, so the response should assume exposure is worth immediate attention.

That matters because deserialization flaws are often attractive to attackers precisely when they can turn a single crafted request into code execution. The value of the KEV signal is that it changes prioritisation: you are no longer deciding whether to patch a possible weakness, you are deciding how quickly to remove an actively abused path into the environment.

When you verify exposure, start from the actual Apache Struts footprint rather than from vulnerability scanners alone. Affected internet-facing applications, legacy integrations, forgotten test systems and cloned deployments are the places most likely to keep a known exploited flaw alive long after the original fix window has passed.

Why Apache Struts Deserialisation Is a High-Value Attack Path

Apache Struts REST Plugin deserialisation problems are dangerous because untrusted XML can be converted into object instances before the application has a meaningful chance to validate intent. Once the attacker can influence that deserialisation step, the application may process data as executable behaviour instead of inert input.

The practical failure pattern is simple: an application accepts XML, deserialises it with insufficient type filtering, and gives the attacker a way to steer object construction. In environments where the Struts component is exposed through a web entry point, that can move very quickly from a malformed request to remote code execution.

That attack path is why this issue should be treated as both a vulnerability management problem and an application trust-boundary problem. If the deserialisation boundary is reachable from untrusted users, the application is assuming too much about the integrity of its input stream.

What Practitioners Should Check First

Confirm whether any Struts application still accepts the relevant XML-based request paths, not just whether the package exists somewhere on disk. Then verify whether the application is internet-facing, whether it processes untrusted payloads, and whether it has been rebuilt or redeployed from a known-good baseline since the fix was applied.

Use a Zero-Day and Exploited Vulnerabilities Guide approach for triage: combine KEV status, exploitability, and asset criticality instead of relying on severity labels alone. For broader remediation workflow discipline, the Vulnerability Management Guide is the right operational model for verification, exception handling, and remediation tracking.

If you need a deeper technical refresher on the weakness itself, the Insecure Deserialisation Guide explains why object injection and gadget-chain style abuse can turn parser logic into execution risk. The issue is not just “bad input”, it is input crossing into execution-relevant object creation.

Risk and Threat Considerations

Actively exploited deserialisation flaws create a direct exposure path for remote code execution, so the main risk is not abstract code quality debt but immediate compromise potential on reachable systems. If the vulnerable Struts component sits behind a public endpoint, attackers do not need deep privilege to turn the bug into an intrusion foothold.

Failure mechanism: The application deserialises attacker-controlled XML without adequate type filtering, allowing crafted payloads to influence object instantiation and potentially trigger arbitrary code execution.

Impact: A successful exploit can lead to full application compromise, follow-on credential theft, persistence, lateral movement, and broader environment exposure if the affected service has access to sensitive data or downstream systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes prioritisation and remediation timing central.
Recommendation — Prioritize and remediate KEV-listed exposures first, then verify no vulnerable instance remains reachable.
OWASP ASVS	V14 — Data Protection	Deserialisation of untrusted input creates direct code-execution and data exposure risk.
	V15 — Secure Coding and Architecture	The flaw reflects unsafe object handling and missing trust-boundary enforcement.
Recommendation — Restrict deserialisation of untrusted data and validate that parser boundaries cannot be abused. Redesign the input path so attacker-controlled data cannot reach executable object construction.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	A KEV-listed CVE requires verification of exposure and rapid remediation tracking.
	SI-2 — Flaw Remediation	The subject is an exploitable software flaw that requires timely remediation and validation.
Recommendation — Continuously identify vulnerable Struts instances and track remediation until none remain. Apply the fix, validate the affected application path, and document closure.

Practitioner Guidance

What to verify: Confirm not only that the patch is present, but that the vulnerable code path is unreachable from untrusted input. Also check whether any adjacent services, reverse proxies or legacy routes can still expose the same application logic.

Decision rule: If the application is internet-facing or handles sensitive data, treat this as a high-priority containment and recovery issue, not a routine backlog item. If patching must wait, reduce exposure immediately by removing access, isolating the service, or disabling the affected function path.

What to measure: Track whether every exposed Struts instance has an owner, a verified remediation state and a post-fix validation result. The useful metric is not “patched somewhere”, it is “no reachable vulnerable instance remains”.

Practitioner takeaway: For KEV-listed deserialisation flaws, assume exploitation pressure is real and act on reachability first, because the fastest win is eliminating the attack path before debating how likely abuse may be.