Is CVE-2017-9791 (Apache Struts 1 Improper Input Validation) being exploited in the wild?

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

Yes. CISA added CVE-2017-9791 to its Known Exploited Vulnerabilities catalogue on 10 February 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. The Struts 1 plugin in Apache Struts might allow remote code execution via a malicious field value passed in a raw message to the ActionMessage.

What it means when a CVE is “being exploited in the wild”

For this question, the key issue is not the vulnerability mechanics alone, but whether there is credible evidence that attackers are actively using it against real systems. CISA’s KEV listing is the practical signal to treat the issue as live, because it reflects confirmed exploitation rather than theoretical risk. That changes urgency, validation, and response order.

When a CVE reaches the KEV catalogue, the first practitioner question is whether your exposed products are actually present in the environment and reachable by the vulnerable code path. For a Struts issue, that means checking application inventory, identifying any Struts 1 usage, and confirming whether the vulnerable plugin or message-handling path exists in deployed applications.

If the product is present, the response should focus on the authoritative vendor advisory and the CISA KEV entry for the required remediation action. The most important practical point is to act on exposure, not on assumptions about whether the application is “legacy but unused.” Internet-facing or externally reachable systems deserve the fastest review because active exploitation usually concentrates there first.

How to reduce exposure if patching must wait

When immediate removal or patching is not possible, the goal is to shrink the exploit path and slow attacker progression. For an input-validation flaw that can lead to remote code execution, compensating controls are about reducing attack reach, limiting what the service can do if abused, and watching for suspicious requests or process behaviour.

That usually means tightening network exposure, restricting who can reach the application, hardening surrounding controls, and removing any unnecessary privileges from the application account. If the vulnerable component runs with broad filesystem, database, or service permissions, the business impact of exploitation is much higher even before the bug is touched.

Temporary mitigations should also include checking for application-layer filtering or request normalization that might block obvious malicious input, but those measures are only a bridge. In practice, they buy time, they do not solve the problem. Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames how to prioritize active exploitation, emergency mitigation, and follow-up hunting.

What to check after active exploitation is confirmed

Once a vulnerability is known to be exploited in the wild, the question becomes whether the system was already abused before you could intervene. That means reviewing logs for suspicious requests, unexpected error patterns, unusual child processes, web shell indicators, new scheduled tasks, and any changes to accounts or configuration that do not fit normal administration.

For an input-validation flaw with potential remote code execution, compromise assessment should include adjacent assets, not just the patched host. Attackers often reuse footholds, harvest credentials, and pivot to connected systems after first access, so a single vulnerable application can become a broader incident if privileges or trust relationships were weak.

If you find signs of compromise, treat credential rotation, session invalidation, and service-account review as part of containment rather than as optional hygiene. The relevant question is whether the flaw could have exposed secrets, runtime access, or downstream trust, not only whether the binary was eventually patched. CISA Known Exploited Vulnerabilities Catalog is the right source to verify the exploitation status and remediation urgency.

Risk and Threat Considerations

An actively exploited input-validation flaw changes the threat model from “possible code execution” to “probable abuse path.” The main risks are unauthorised execution on exposed applications, follow-on credential theft, and lateral movement if the application runs with unnecessary privilege or has access to sensitive back-end systems.

Failure mechanism: Malicious input reaches the vulnerable Struts message-handling path, the application processes it unsafely, and an attacker may turn that flaw into remote code execution on a reachable host.

Impact: Once execution is achieved, defenders may face data theft, service disruption, secret exposure, or broader compromise of connected systems if the application has meaningful trust or privilege.

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	Active exploitation demands fast exposure triage and remediation prioritisation.
Recommendation — Prioritise exposed instances, remove the vulnerable component, and verify remediation speed against exploit activity.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV-listed exploitation requires disciplined flaw remediation and exception handling.
	RA-5 — Vulnerability Monitoring and Scanning	Confirming exposure and hunting affected assets depends on continuous vulnerability discovery.
Recommendation — Remediate the flaw promptly and document compensating controls when patching must wait. Scan for affected deployments, validate reachability, and keep the asset inventory current.
OWASP ASVS	V15 — Secure Coding and Architecture	The flaw is rooted in input handling and unsafe processing paths in application code.
	V16 — Security Logging and Error Handling	Post-exploitation validation depends on logs and error signals that reveal abuse attempts.
Recommendation — Review validation and request-handling logic to remove unsafe data flows that can lead to execution. Retain and inspect security logs for indicators of exploitation, abnormal requests, and follow-on activity.

Practitioner Guidance

What to verify: Confirm whether any internet-facing or partner-facing application still uses the affected Struts 1 plugin or an equivalent vulnerable code path. Inventory alone is not enough, verify actual deployment and reachability.

Decision rule: If the application is exposed and cannot be remediated immediately, treat it as an active security exception, reduce access, and increase monitoring before you spend time on deeper root-cause analysis.

What to measure: Track time to confirm exposure, time to implement the vendor or CISA-required action, and time to complete post-exploitation checks. Those three metrics tell you whether the organisation is responding like the issue is real, which in this case it is.

Practitioner takeaway: For a KEV-listed CVE, the default assumption should be active exploitation until you prove otherwise, and the response should prioritise exposure confirmation, rapid containment, and compromise assessment over debate about exploit novelty.

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