Yes. CISA added CVE-2013-2251 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apache Struts allows remote attackers to execute arbitrary Object-Graph Navigation Language (OGNL) expressions. Any organisation running the affected product should treat remediation as urgent.
What “Being Exploited in the Wild” Means for CVE-2013-2251
For this CVE, the practical question is not whether a proof of concept exists, but whether active exploitation has already been observed. CISA’s KEV inclusion is the clearest operational signal that exploitation is happening now, so this should be treated as a live exposure rather than a theoretical weakness. The right response is to verify exposure quickly and prioritise remediation over normal patch queues.
Apache Struts is a web application framework, but the security question here is really about exposed attack surface and the speed at which a vulnerable instance can be turned into code execution. Because the flaw allows arbitrary OGNL expression execution, any reachable instance can become an entry point for broader compromise if it is left unaddressed.
When you are triaging this kind of issue, the first decision is whether the affected application is internet-facing, operationally critical, or embedded in a business flow that cannot tolerate downtime. Those factors determine how aggressively you can apply emergency change, isolation, or compensating controls while you plan the fix.
What to Do Before You Assume You Are Safe
Do not rely on “we have not seen alerts” as evidence of safety. With actively exploited vulnerabilities, a lack of telemetry often means the environment is not instrumented well enough to prove whether exploitation has already occurred. Confirm whether any Struts deployment is reachable, whether it is still supported, and whether the vulnerable code path is present in production, staging, or legacy internal systems.
If the application cannot be patched immediately, reduce exposure by removing public reachability, tightening network access, and placing the affected service under heightened monitoring. That is especially important when the application handles authentication, file upload, administration, or other high-value workflows that attackers commonly target after gaining code execution.
Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for the authoritative remediation path, and use the NIST National Vulnerability Database and the CVE Program to anchor internal tracking and reporting.
How to Handle Exposure, Patching Delay, and Compromise Checks
For exploited web application flaws, remediation is only half the task. You also need to test for earlier compromise, because code execution can be used to create persistence, steal secrets, alter application logic, or pivot into adjacent systems. That means checking logs, web shells, unusual outbound connections, unexpected account activity, and changes to application files or scheduled tasks.
If patching is delayed, treat the system as potentially hostile. Revoke or rotate credentials and tokens that the application may have exposed, especially service accounts, API keys, database credentials, and administrative sessions. If the application had access to other internal systems, review those trust relationships as part of the response, not as a separate project.
For the broader vulnerability workflow, the useful pattern is to pair exposure validation with remediation verification. The point is not only to install a fix, but to confirm the vulnerable instance is gone from the fleet and that no surviving instance remains reachable with the same trust assumptions.
Risk and Threat Considerations
Actively exploited web application vulnerabilities compress the time available to respond, and they often fail open into code execution, credential theft, or downstream lateral movement. That makes delay the main risk factor, especially when the affected service is internet-facing or has access to internal resources.
Failure mechanism: An attacker reaches the vulnerable Struts application, supplies crafted input that is evaluated as OGNL, and gains arbitrary execution in the application context. From there, the attacker can search for secrets, implant persistence, or use the host as a pivot point into other systems.
Impact: The organisation can face full application compromise, data exposure, service disruption, and wider environment access if the compromised application had privileged network or credential access. If the flaw is left uncontained, the initial web entry point can become an enterprise incident.
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, 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 | Actively exploited CVEs require rapid discovery and remediation of exposed assets. |
| Recommendation — Prioritise the vulnerable Struts instance for immediate remediation and verify it is removed from exposed asset inventories. | ||
| NIST CSF 2.0 | RS.MA-1 — Incident Management | KEV-listed exploitation calls for coordinated containment and response actions. |
| DE.CM-08 — Vulnerability Scanning | Exposure confirmation depends on identifying vulnerable deployments across the environment. | |
| Recommendation — Treat the CVE as an active incident condition and coordinate containment, patching, and verification. Scan the fleet to confirm whether any Struts deployment remains vulnerable or reachable. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This CVE requires authoritative vulnerability detection and remediation prioritisation. |
| Recommendation — Use vulnerability monitoring to locate affected Struts systems and drive urgent remediation. | ||
| OWASP ASVS | V2 — Validation and Business Logic | The flaw is an input-validation failure that enables execution through unsafe expression handling. |
| Recommendation — Review input validation and expression handling controls in the affected application path. | ||
Practitioner Guidance
What to verify: Confirm whether any deployed Struts instance is still exposed, whether the vulnerable component is reachable in production, and whether the application has already shown signs of file, process, or account tampering.
Decision rule: If the system is internet-facing or supports sensitive business functions, move it to emergency remediation, not routine backlog treatment. If patching must wait, isolate the service and assume compromise until proven otherwise.
What good looks like: You can identify every deployed instance, prove the vulnerable path is removed or mitigated, and show that relevant secrets, sessions, and adjacent trust paths have been reviewed after remediation.
Practitioner takeaway: Once a vulnerability is in KEV, the key question becomes whether your environment is still exposed, not whether exploitation is possible in theory.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- How do you patch or mitigate CVE-2013-2251 (Apache Struts Improper Input Validation)?
- Is CVE-2017-9791 (Apache Struts 1 Improper Input Validation) being exploited in the wild?
- CVE-2013-2251 (Apache Struts Improper Input Validation)
- Is CVE-2013-6282 (Linux Kernel Improper Input Validation) being exploited in the wild?