Is CVE-2017-5638 (Apache Struts Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2017-5638 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Apache Struts Jakarta Multipart parser allows for malicious file upload using the Content-Type value, leading to remote code execution.

What makes CVE-2017-5638 a live exploitation concern?

The practical issue is not just that the bug exists, but that it is publicly known, has been added to CISA’s KEV catalogue, and is treated as an actively exploited vulnerability. For defenders, that means exposure assessment should be immediate and asset-specific. If Apache Struts is present anywhere in the environment, assume it deserves urgent validation, not normal backlog handling.

A useful starting point is a focused inventory check: identify every application, appliance, and embedded platform that may bundle the affected Struts component, then confirm whether the vulnerable code path is actually reachable. Public vulnerability records remain the authoritative reference point for identifying the issue and tracking it consistently across tools and teams, and the CVE Program and NIST National Vulnerability Database are the cleanest places to anchor that recordkeeping.

Because the issue involves remote code execution through malformed multipart handling, the exposure question is not only “is Struts installed?” but “does any exposed application still accept attacker-controlled upload traffic through the vulnerable path?” That distinction matters when the framework is present inside a larger product, when the vulnerable endpoint sits behind a reverse proxy, or when an old application remains reachable from a legacy network segment.

The most defensible response is to treat this as an emergency remediation case, following the vendor’s guidance and CISA’s KEV status rather than relying on generic patch cadences. If a system is internet-facing, business-critical, or handles sensitive data, the confirmation threshold should be low and the remediation priority high.

What should defenders do if patching is delayed?

When immediate patching is not possible, the goal shifts from “fix later” to “reduce exploitable reach” without assuming the threat has gone away. That usually means restricting exposure at the edge, tightening upload handling, and removing unnecessary access to the application until the vulnerable component is replaced or mitigated. Temporary controls are not a substitute for removal of the flaw, but they can lower the chance of opportunistic exploitation while change windows are arranged.

If a workaround is in place, verify that it actually changes the attack path, not just the documentation. For example, blocking obvious file extensions is not the same as eliminating unsafe multipart handling, and putting the application behind a WAF is not enough if the same endpoint remains directly reachable through another route. A mitigation is only meaningful if it closes the practical exploit path described in the advisory.

Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the exact triage problem defenders face with KEV-listed issues: verify exposure, prioritize exploitability, and move quickly from detection to containment.

For teams that maintain risk-based remediation queues, this type of issue should outrank ordinary CVE severity debates. Public exploitation evidence changes the decision model, so the main question becomes how fast the service can be contained, corrected, or isolated without creating a larger operational outage.

How should teams check for compromise after exposure?

Once a vulnerability is known to be exploited in the wild, the next question is whether the environment was already used before remediation. That means looking for unusual web requests, unexpected process creation, new web shells, outbound connections, and any post-exploitation activity that follows code execution on the application host. The objective is not only to confirm whether the patch is applied, but to determine whether the host must also be treated as potentially compromised.

Response should include a review of adjacent assets and authentication material that the application might have reached. Remote code execution can expose configuration files, local credentials, session material, service accounts, and internal network access paths, so compromise assessment should include any secrets or credentials that may have been accessible from the application context.

CISA Known Exploited Vulnerabilities Catalog is the right operational reference for deciding which systems deserve accelerated hunt and remediation activity, while FIRST EPSS helps teams understand whether a vulnerability is broadly likely to be exploited, even though KEV status already makes this case urgent.

Vulnerability Management Guide is the stronger internal navigation point for practitioners who need to connect KEV status, prioritisation, verification, and post-remediation validation into one operational workflow.

Risk and Threat Considerations

CVE-2017-5638 matters because remote code execution on a widely deployed web framework creates a direct path from internet exposure to system-level compromise. When a flaw is already in KEV and tied to ransomware activity, the risk is no longer theoretical: unpatched assets become straightforward targets for opportunistic scanning, follow-on payload delivery, and lateral movement.

Failure mechanism: The vulnerable Struts multipart parser can be driven by attacker-controlled content-type handling, allowing malicious input to reach code execution conditions before normal application controls can stop it.

Impact: An exposed application may be taken over, used to stage malware, or leveraged to steal credentials and pivot deeper into the environment, especially if the web tier has privileged reach into internal 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, NIST SP 800-53 Rev 5 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-2017-5638 is a known exploited vulnerability requiring urgent prioritization and remediation.
Recommendation — Prioritize exposure, patching, and verification for KEV-listed systems before ordinary backlog work.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires fast remediation and validation of vulnerable software components.
	RA-5 — Vulnerability Monitoring and Scanning	Confirming exposure and checking for vulnerable instances is central to this KEV case.
	SI-4 — System Monitoring	Post-exploitation review is needed because active exploitation may leave host and network indicators.
Recommendation — Remove or mitigate the vulnerable Struts component and verify the fix is deployed everywhere. Scan for all Struts instances and confirm which ones remain reachable from attacker-controlled input. Monitor for suspicious web requests, process launches, and outbound activity after exposure is found.
OWASP ASVS	V5 — File Handling	The vulnerability is triggered through malicious multipart file handling in the web layer.
Recommendation — Review upload and multipart handling paths for unsafe parsing and trust boundaries.

Practitioner Guidance

What to prioritise: Validate every internet-facing and business-critical Struts deployment first, then extend the check to internal-facing applications that still process untrusted uploads. A KEV-listed RCE should be treated as an exposure problem, not a pure patching task.

What to verify: Confirm whether the vulnerable endpoint is actually reachable, whether the application has already generated suspicious server-side activity, and whether any credentials, sessions, or local files could have been exposed before remediation. If the answer to any of those is yes, expand the response beyond patching.

Practitioner takeaway: For exploited RCEs, the correct decision is to combine rapid exposure removal with compromise assessment, because the absence of visible abuse does not materially reduce the need to assume the system was already probed.