Apache Struts flaw: one crafted JSON request can exhaust memory and crash the app (CVE-2026-73633)

A single oversized web request can now take down an Apache Struts application. CVE-2026-73633, which Apache tracks as advisory S2-072, lets an attacker send a JSON body that Struts reads with no size limit, filling the server's heap until the application stalls or crashes. This is a denial-of-service bug, not the remote code execution Struts is infamous for, and Apache rates it Moderate. Struts still runs deep inside enterprise Java, a proof-of-concept is already public, and the fix is worth scheduling. Here is who is actually exposed and what to do about it.

Are you actually exposed?

You are affected only if your application uses the optional Struts JSON plugin and accepts JSON request bodies. An app that never loads the plugin, or that uses it only to serialize JSON responses, is not vulnerable to this. Check that first, because it decides whether this is an urgent job or a routine upgrade.

The plugin in question ships as struts2-json-plugin, and it is what turns an incoming JSON payload into action properties your code can read. Grep your build files for that dependency, then look at whether any action actually consumes a JSON content type on input. If both are true, you are in scope.

Affected and fixed versions

The flaw reaches across every current Struts line. On the legacy branches that means 2.x up to 2.3.37 and 2.5.x up to 2.5.33; on the maintained branches it is 6.x up to 6.10.0 and 7.x up to 7.2.1. Apache shipped the fix in 7.3.0, and backported it to 6.11.0 for anyone staying on the 6.x series. The 2.x and 2.5.x branches are end of life and get no dedicated patch, so the only real fix there is to move onto a supported release.

What the attack looks like, and how to catch it

The mechanism is simple, which is part of why it is worth taking seriously. An attacker points a large or open-ended JSON body at an endpoint that maps to a JSON-plugin action. Struts buffers that input in memory without a ceiling, the heap fills, garbage collection starts thrashing, and the process either throws an out-of-memory error or grinds to a halt. No credentials and no clever payload are required, just size.

You do not need the exploit to detect the abuse. Watch for three signals together: unusually large request bodies aimed at your JSON endpoints, sudden spikes in heap usage paired with full-garbage-collection storms, and OutOfMemoryError entries in application logs that line up with a burst of inbound traffic. Any one of those is noise; the three together, on a Struts app, is the pattern. This is the same class of blind spot we flagged with a denial-of-service flaw in Cisco firewalls: the request looks ordinary until the resource math tips over.

Your move: scope first, then patch or cap

Start by confirming exposure, as above. If you are not running the JSON plugin, log the CVE and move on. If you are, patch on the normal change cadence: 6.x moves to 6.11.0, and everything else moves to 7.3.0.

If you cannot patch this week, put a ceiling on request size in front of the app. Apache's own workaround is to cap the request body size upstream of Struts, either at a reverse proxy or in the app server. On nginx that is client_max_body_size; most application servers have an equivalent setting. A sane limit rejects the oversized request before Struts ever buffers it.

Treat that cap as permanent, not a stopgap. Unbounded-read bugs like this one are a recurring class (the formal name is uncontrolled resource consumption, CWE-400), and a body-size limit at the edge is cheap insurance against the next one, whether or not you run Struts at all. Widely deployed server software keeps drawing this kind of attention, as the steady stream of flaws in other internet-facing server platforms shows. For now, no in-the-wild exploitation has been reported and EPSS scores this in the 25th percentile, so you have room to do this right rather than fast.