How do you patch or mitigate CVE-2017-9805 (Apache Struts Deserialization of Untrusted Data)?

CISA’s required action for CVE-2017-9805 is to apply updates per vendor instructions. In practice, find every instance of Apache Struts in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2017-9805 means in practice

Apache Struts deserialization flaws are dangerous because they can turn a crafted request into code execution or broader compromise if the vulnerable component remains reachable. The practical question is not whether the CVE exists, but where Struts is deployed, how exposed it is, and whether the vulnerable path is still enabled in production, test, or forgotten internet-facing systems.

For teams tracking vulnerable software, the right response is to treat this as an asset discovery and exposure problem first, then a remediation problem. The fix is only useful if you can confirm every Struts instance, identify the versions in use, and verify that the affected application path is either patched or removed from reach. NHI Management Group’s Vulnerability Management Guide is useful here because this is exactly the kind of issue that fails when organisations do not have reliable software inventory and prioritisation discipline.

When the vulnerable application cannot be patched immediately, the mitigation changes the attack surface rather than the code: isolate the service, block public access, or take it out of service until a vendor-backed fix can be applied. That is often the safer choice for legacy deployments than leaving a known-exploited component exposed while waiting for a maintenance window. For teams building a repeatable response path, NHI Management Group’s Zero-Day and Exploited Vulnerabilities Guide covers the same emergency pattern of triage, containment, and post-patch validation.

How to reduce exposure before and after patching

The first step is to locate every instance of Apache Struts, including embedded copies inside larger applications and older environments that may have escaped normal patch cycles. A vulnerability is often missed not because the fix is unknown, but because the affected application is not in the asset register or is hidden behind an internal deployment pattern that no one still actively owns.

Once you have scope, apply the vendor security update or the documented mitigation exactly as provided for the affected deployment. If a code fix is unavailable or operationally unsafe in the short term, reduce exposure by removing the internet-facing route, tightening network reachability, or suspending the service. The point is to eliminate the attack path, not to wait for the ideal remediation state while the system stays reachable.

Patch validation matters as much as the patch itself. After remediation, confirm the application no longer accepts the vulnerable path, and check adjacent systems that might still expose the same library through shared images, templates, or legacy build artefacts. If the fix was applied under pressure, plan a second verification pass once normal operations resume so temporary compensating controls do not become permanent blind spots.

What to look for after the patch is applied

Because this flaw was exploited in the wild, post-remediation review is not optional. Search for evidence of suspicious requests, unexpected process launches, web shell artefacts, and other signs that the system may already have been compromised before the patch landed. If the vulnerable app handled sensitive credentials, session material, or administrative access, treat the host as a compromise candidate rather than assuming patching alone closed the incident.

Log review should focus on the period before detection and on any time when the application was known to be reachable without protection. Look for abnormal error patterns, strange user agents, repeated exploit attempts, outbound connections that do not fit the application role, and changes to files or scheduled tasks that would support persistence. If those signals exist, the response should move from simple remediation into full incident handling and scope expansion.

Risk and Threat Considerations

A deserialization flaw is especially risky because it can collapse the normal trust boundary between network input and application execution. When the vulnerable component is reachable from the internet, attackers can probe for it at scale, and a single missed instance may provide an entry point even after most of the estate has been remediated.

Failure mechanism: A crafted payload reaches a Struts endpoint that accepts untrusted serialized data, triggering unsafe object handling and potentially arbitrary code execution or follow-on compromise.

Impact: The result can be server takeover, lateral movement, data access, persistence, or the use of the host as a foothold for wider intrusion, especially if the application runs with elevated privileges.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 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	Applies because the issue requires finding and remediating exposed vulnerable software.
Recommendation — Maintain asset scope and prioritize remediation for all exposed Struts instances.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	Applies because the response depends on identifying, fixing, and validating a known vulnerability.
	RS.MA-1 — Incident Management is Executed	Applies because post-exploitation review and containment may be needed after active exploitation.
Recommendation — Track vulnerable Struts deployments and verify remediation after patching. Escalate to incident handling when logs or indicators suggest prior compromise.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Applies because the flaw must be patched or mitigated per vendor guidance.
	SI-4 — System Monitoring	Applies because logs and telemetry should be reviewed for exploitation evidence.
Recommendation — Apply vendor security updates or documented mitigations for affected Struts systems. Review logs and alerts for signs of exploitation after remediation.

Practitioner Guidance

What to prioritise: Patch or isolate the most exposed Struts instances first, especially anything internet-facing, business-critical, or difficult to monitor. If a system is both exposed and unpatchable, treat removal from service as a normal security decision rather than an operational failure.

What to verify: Confirm that remediation changed the real exposure, not just the ticket status. You want evidence of asset coverage, applied vendor guidance, and post-fix validation that the vulnerable path is no longer reachable.

Decision rule: If you cannot prove the vulnerable instance is patched, contained, or decommissioned, assume it remains exploitable and continue containment until that proof exists.

Practitioner takeaway: For exploited deserialization flaws, the safe order is discover, contain, remediate, then hunt for compromise, because patching without exposure control and log review leaves too much attack surface behind.