Decade-old Struts RCE flaw CVE-2016-3081 lands on CISA's actively exploited catalog

A 2016 Struts flaw is now on CISA's exploited list

CVE-2016-3081, a remote code execution vulnerability in Apache Struts 2.3.x published in April 2016, was added to CISA's Known Exploited Vulnerabilities catalog on 8 October 2026, according to a dev.to analysis of the listing. Placement on the catalog means the flaw is confirmed as actively exploited, which typically triggers mandatory remediation timelines for US federal agencies and raises the priority for everyone else. NVD rates the vulnerability 8.1 on CVSS with a vector that includes high attack complexity, a detail that matters more than the headline number.

The affected versions are Struts 2.3.19 through 2.3.20.2, 2.3.21 through 2.3.24.1, and 2.3.25 through 2.3.28. An attacker who reaches a vulnerable deployment can execute arbitrary code by sending a request that uses a method: prefix inside a chained expression.

Exploitation depends on one configuration flag

The vulnerability only works when Dynamic Method Invocation (DMI) is switched on. DMI is a configuration setting, controlled by the struts.enable.DynamicMethodInvocation property, that allows a request parameter to decide which method Struts calls on an action. When enabled, the OGNL expression language Struts uses to resolve the method name can be manipulated into running code; when disabled, the attack path is closed, as the dev.to write-up explains.

That precondition is why the score carries high attack complexity. A scanning attacker cannot simply knock on every Struts 2.3.x server and expect entry: they need a deployment where somebody turned DMI on, often years ago to support a legacy page and usually with no record of the decision. The catalog listing proves at least one such deployment was found and used; it does not mean every Struts 2.3.x installation is exploitable.

Inventory has to happen at runtime

Finding the flag is harder than searching source repositories, because configuration accumulates in artifacts: a struts.xml inside an old WAR, a properties file bundled in a shared library, or a build reconstructed from an untracked branch. Grepping source control only catches the settings people remember making. The dev.to author recommends a runtime inventory instead: enumerate the deployed web applications, extract each Struts core JAR version, and determine whether DMI is active in each application's configuration chain. Deployments where the setting cannot be established should be treated as unknown, not safe.

What an exploit looks like and how to catch it

A successful request resolves a method name containing an OGNL expression that runs inside the JVM with the privileges of the application server. From there the consequences are familiar: command execution as the service account, exposure of configuration files and connection strings, and outbound connections to attacker-controlled infrastructure.

Because the malicious request resembles an ordinary parameter at the web tier, and OGNL offers many equivalent ways to spell the same payload, string-signature detection has a short shelf life. The dev.to post argues for behavioural detection instead: a Java process spawning sh, cmd.exe or PowerShell is anomalous in most application servers, as is an outbound connection from an application host to a destination no policy authorises. Both are worth alerting on regardless of framework.

Remediation order

Upgrade Struts. The affected range ends at 2.3.28 and a fixed version has existed for roughly a decade, so a deployment still on 2.3.x faces an upgrade project rather than a one-line patch, and that project is the correct response.

Where an upgrade cannot land this quarter, the interim step is to explicitly disable DMI and confirm the change takes effect in the running application, then test the pages that depended on it, since the feature was presumably enabled for a reason. Teams should also review hosts for signs of earlier compromise, focusing on what survives beyond log retention: unexpected files in the deployment directory, newly created scheduled tasks, and changes to JVM startup arguments.

Why it matters

The listing shows a vulnerability can return to relevance ten years after disclosure. The same October 2026 catalog update also added entries covering flaws from 2015, 2016 and 2021, a clustering the dev.to author reads as the signature of an exploit economy that scans for old framework versions, replays known payloads and monetises whatever responds. For anyone operating legacy Java stacks, the lesson is that a vendor's default describes the shipped configuration, not the inherited deployment actually running in production, and a KEV entry turns that uncertainty into a concrete, dated obligation.