CISA’s October 8, 2026, listing of CVE-2016-3081 as exploited puts old Apache Struts 2 applications back on the patch list. A remote attacker can run arbitrary code on a Struts application server when Dynamic Method Invocation (DMI) is enabled. CISA gives October 11 as the remediation due date for the federal response it directs.
This is a 2016 flaw in Struts 2 installations, but its new KEV listing puts any still-running application with DMI enabled back in scope. The vulnerable route uses the method: prefix to pass a malicious expression into server-side execution. Start with the applications that an untrusted client can reach, then check their deployed Struts version and effective DMI setting.
How DMI reaches server code
DMI lets a request select an action method.
In its S2-032 bulletin, Apache says a malicious expression supplied through the method: prefix can reach arbitrary server-side execution when that feature is on. Security researcher Nike Zheng reported the vulnerability. Disabling DMI removes the prerequisite Apache identifies for this route; keep the framework on a maintained release.
The CVE Program record describes affected Struts versions as 2.3.19 through 2.3.20.2, 2.3.21 through 2.3.24.1, and 2.3.25 through 2.3.28, with DMI enabled. Apache’s S2-032 affected-software line starts at 2.3.20; include 2.3.19 in the inventory because the CVE record explicitly names it. Apache names 2.3.20.3, 2.3.24.3, and 2.3.28.1 as the corrected releases for those respective branches. Choose a maintained release path for production after checking the applicable branch fix.
Which Struts deployments need triage
Inventory the deployed Struts libraries. Look inside application packages and on servers, including copies inside third-party products. Match their actual versions to the affected ranges, inspect the running application’s DMI setting, and test which application endpoints are reachable from outside their intended clients. Include internet reachability in that application-by-application inventory, as CISA directs. A reachable affected application with DMI enabled deserves prompt remediation and incident triage. Confirm running configuration and request reachability alongside the library inventory.
Retain and inspect web-server, reverse-proxy, and application request logs for the period that exposed applications ran. Search for the method: marker in recorded request paths or parameters and examine matching requests in context. Treat a method: match as a triage lead and correlate it with host activity. If that search returns nothing, check other available request fields and host evidence too: ordinary logging can omit or normalize relevant request material. Preserve surrounding host and application evidence for incident response if suspicious requests or execution activity appear. CISA calls for forensic triage alongside mitigation.
Remove the DMI execution route
Apache’s first recommendation is direct: “Disable Dynamic Method Invocation if possible.” Before changing production, record each affected application’s deployed Struts version, effective DMI setting, and the client networks that can reach its action endpoints. Turn DMI off in affected applications that do not need it, or upgrade to the appropriate corrected Struts branch and plan a maintained release. If DMI must stay on during the upgrade, restrict access to the application from untrusted client networks. Verify the restriction from a previously untrusted client network. For a third-party product embedding Struts, obtain the supplier’s patched build and verify the deployed library it contains.
After rollout, verify the library version in the running application, its effective DMI state, and the reachability of its action endpoints from the networks that previously had access. A disabled DMI setting or a deployed corrected release addresses this specific execution path. For a server that was exposed, compare pre-change request and host evidence with expected behavior and carry any suspicious activity into incident response even after the framework update.