CVE-2006-1547 is an actionform denial-of-service vulnerability in Apache Struts 1. CISA added it to the Known Exploited Vulnerabilities catalogue on 21 January 2022, which means attackers have used it in real attacks. ActionForm in Apache Struts versions before 1.2.9 with BeanUtils 1.7 contains a vulnerability that allows for denial-of-service (DoS).
Why this Struts flaw is dangerous
CVE-2006-1547 is dangerous because it turns ordinary request handling into a denial-of-service condition inside a widely used web application framework. In a Struts 1 deployment, repeated malformed or expensive form-processing requests can consume thread, CPU, or memory resources until the application becomes sluggish or unavailable.
That makes the issue operationally important even when it is not a code-execution bug. A DoS vulnerability at the framework layer can affect many applications at once, especially where Struts is embedded broadly across legacy Java estates. For remediation context, use the vendor advisory and the CISA KEV catalogue rather than relying on summaries alone, and pair that with a current NIST National Vulnerability Database record for product and exposure details.
How exposure is usually assessed
Exposure starts with knowing where Apache Struts 1 is actually installed, because many organisations inherit it through older internal applications rather than through an obvious platform inventory. Asset discovery, application ownership, and codebase review all matter, because a single legacy app can still represent a live attack surface.
Internet-facing systems deserve special attention, since a remotely reachable web tier is the most likely place an attacker can repeatedly trigger the vulnerable path. Organisations should also check whether a vendor or application owner has already issued guidance, because patching and workaround advice often depends on the exact Struts release line and bundled dependencies.
For authoritative recordkeeping and naming, cross-check the vulnerability entry at the CVE Program and compare it with internal application inventories so that the same issue is not tracked under multiple local names.
Containment and remediation when patching is delayed
Legacy web frameworks often remain in service long after formal support assumptions have changed, so remediation is usually a mix of upgrade planning and temporary exposure reduction. If immediate replacement is not possible, organizations should reduce reachable attack surface, place strict request controls in front of the application, and isolate the affected service from broader shared resources.
Compensating controls matter most when the vulnerable application is business critical. Rate limiting, reverse proxy filtering, WAF rules, and tighter resource caps can all help absorb abuse, but they do not remove the flaw itself. The practical goal is to make repeated request flooding harder, less effective, and easier to absorb until the framework can be retired or updated.
For broader prioritisation, the Vulnerability Management Guide is useful for mapping this kind of KEV-listed issue into asset scope, prioritisation, and remediation workflows.
Detection and compromise review
Detection should focus on symptoms of resource exhaustion rather than on a single signature. Sudden latency spikes, thread pool saturation, repeated HTTP errors, and load that is disproportionate to normal traffic patterns can all indicate an active denial-of-service attempt or a post-exploitation stress condition.
After the issue is patched or isolated, review logs and telemetry for repeated probing, high-frequency form submissions, and any changes in application behaviour that appeared during the attack window. Even though the primary impact here is availability, a compromise review is still valuable because attackers often use noisy disruption as cover for reconnaissance or follow-on abuse.
For readers who want a control-oriented view of service exhaustion and web-layer mitigation, the DDoS Protection Guide explains the kinds of rate controls, scrubbing, and response patterns that are most relevant to this failure mode.
Risk and Threat Considerations
A Struts DoS flaw is dangerous because it creates a low-complexity availability attack against a framework that may underpin multiple business applications. In practice, the risk is not only outage duration, but also the possibility that shared hosting, shared JVM capacity, or tightly coupled services magnify the impact across more than one workload.
Failure mechanism: Repeatedly triggered ActionForm processing can exhaust application resources faster than the service can recover, especially when the vulnerable component sits on an internet-facing path.
Impact: The application can become slow, unstable, or unavailable, and incident response may be complicated if the same legacy framework is deployed in several places with inconsistent ownership.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PS-01 — Secure Development Practices | Legacy framework flaws require secure maintenance and lifecycle hardening. |
| PR.IR-01 — Network Resilience | Availability attacks against web apps are bounded by resilience and recovery controls. | |
| Recommendation — Retire or upgrade vulnerable legacy applications before relying on compensating controls. Limit blast radius with isolation, rate controls, and recovery procedures. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed flaws belong in formal vulnerability prioritisation and remediation workflows. |
| CIS-12 — Network Infrastructure Management | Web-layer DoS mitigation depends on traffic filtering, segmentation, and edge controls. | |
| Recommendation — Prioritise KEV-listed exposures for rapid remediation and verification. Apply edge controls and segmentation to reduce exposure to request flooding. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Detecting DoS conditions requires monitoring for resource exhaustion and anomalous traffic. |
| Recommendation — Monitor for saturation, latency spikes, and abnormal request patterns. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a legacy-application risk, not just a single CVE ticket. If Struts 1 still exists anywhere in the estate, ownership, maintenance status, and replacement plan should be explicit because availability failures often repeat until the platform is retired.
What to watch for: Prioritise any externally reachable application that shows bursty request patterns, unexplained resource spikes, or repeated incident recurrence on the same codebase. Those signals usually mean the affected service is still reachable in a way that can be abused again.
Practitioner takeaway: The cleanest fix is removal or upgrade; everything else is only a buffer while the vulnerable path remains live.
Related resources from NHI Mgmt Group
- CVE-2022-0028 (Palo Alto Networks PAN-OS Reflected Amplification Denial-of-Service)
- CVE-2018-0154 (Cisco IOS Software Integrated Services Module for VPN Denial-of-Service)
- CVE-2017-12319 (Cisco IOS XE Software Ethernet Virtual Private Network Border Gateway Protocol Denial-of-Service)
- CVE-2017-12231 (Cisco IOS Software Network Address Translation Denial-of-Service)