How do you patch or mitigate CVE-2017-5638 (Apache Struts Remote Code Execution)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2017-5638 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 patching CVE-2017-5638 should look like in practice

The safest response is to treat this as an active exposure problem, not a routine maintenance task. Inventory every Apache Struts deployment, confirm whether the vulnerable code path is present, and apply the vendor security update or documented mitigation as the primary fix. If you cannot remediate quickly, remove the service from internet-facing reach or take it out of service until you can.

For exposed and actively exploited vulnerabilities, triage should be driven by exposure and exploitability rather than by convenience. Use the CISA Known Exploited Vulnerabilities Catalog to anchor the response in the confirmed exploitation status, and use the vendor advisory to confirm the exact update or mitigation steps for your Struts version.

When a flaw is already being used in the wild, patching alone is only half the response. The other half is reducing the attacker’s opportunity window by shrinking exposure, because internet-accessible systems are the first place exploitation tends to land.

How to confirm exposure and reduce blast radius before and during remediation

Start by finding every application, container, appliance, or legacy host that includes Apache Struts, including forgotten internal applications that were never formally retired. Validate whether the vulnerable component is actually reachable from a user-controlled request path, because a dormant library on a dead host is a different risk from one exposed behind a public web front end.

If you need a practical prioritisation lens, pair the inventory with the Exploit Prediction Scoring System and your external exposure data. That helps you focus first on assets that are both vulnerable and likely to be hit quickly, rather than spreading effort evenly across the estate.

Where patching must wait, the best mitigation is to remove the attack path, not to hope for compensating controls to hold indefinitely. Segment the application, restrict inbound access to trusted networks only, disable the vulnerable feature if the vendor documents a safe workaround, and remove the system from service if neither patching nor mitigation can be applied reliably.

What to check after remediation, and what to preserve

After patching or mitigation, review web, application, reverse-proxy, and host logs for signs of earlier exploitation. For a remote code execution flaw, the question is not only whether the patch installed cleanly, but whether the system was already used to execute commands, drop a web shell, or stage follow-on activity before the fix landed.

That review should include adjacent systems that may have been touched after initial access, because successful exploitation often becomes a pivot into credentials, configuration files, or application data. If you see evidence of code execution, treat the host as potentially compromised and escalate to containment, forensic preservation, and broader credential review.

Keep enough evidence to reconstruct the timeline: alerting, request traces, process creation records, file modification times, and the exact remediation change that was applied. Without that record, you may know the vulnerability is gone while still missing the compromise that happened before the patch.

Risk and Threat Considerations

Remote code execution vulnerabilities are attractive because they turn a simple request into arbitrary execution on the server. When the application is internet reachable, attackers can probe quickly, automate exploitation, and move from initial access to persistence or lateral movement before defenders notice.

Failure mechanism: The vulnerable Struts request handling path allows crafted input to reach code execution, which can then be used to drop malware, change application files, or pull secrets from the host.

Impact: Successful exploitation can lead to full application compromise, data theft, credential exposure, and wider environment access if the host has trusted network paths or overbroad permissions.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE patching and exposure reduction are core vulnerability management tasks.
Recommendation — Prioritise exposed Struts instances, validate remediation, and track the fix to closure.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	You must identify every Struts instance before patching or mitigating the CVE.
Recommendation — Enumerate Struts assets and document where the vulnerable version is reachable.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	This CVE is a public-facing application RCE risk with active exploitation.
Recommendation — Hunt for public-facing exploitation attempts and correlate them with suspicious server activity.
OWASP ASVS	V15 — Secure Coding and Architecture	Struts RCE response hinges on eliminating exploitable request-processing paths.
	V16 — Security Logging and Error Handling	Post-patch log review is necessary to detect prior exploitation and follow-on activity.
Recommendation — Review application architecture to remove or constrain unsafe request handling paths. Retain and review logs to detect exploitation attempts and confirm remediation timing.
OWASP API Security Top 10	API8 — Security Misconfiguration	Mitigation often depends on removing unsafe exposure and hardening reachable endpoints.
Recommendation — Harden exposed endpoints and remove unnecessary internet access before returning the service online.

Practitioner Guidance

What to prioritise: Put internet-facing Struts instances first, then any internal instance that can reach sensitive data or privileged services. A vulnerable but isolated test system is still worth fixing, but it is not the same emergency as a public production endpoint.

What to verify: Verify that the vulnerable instance is actually removed, updated, or safely mitigated, and then verify that the mitigation did not leave the service functionally exposed through another path. If the system cannot be confidently validated, assume residual risk remains.

Decision rule: If you cannot patch immediately, choose exposure reduction over delay, meaning disable the reachable service, restrict access, or retire the instance until remediation is complete. If you already have signs of exploitation, treat the issue as an incident, not just a vulnerability ticket.

Practitioner takeaway: For an exploited RCE, the right goal is not merely “patched”; it is “patched, no longer exposed, and checked for pre-patch compromise.”

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org