Apache Struts is old enough that many defenders only think about it when a historic exploit comes up in a tabletop exercise. That is exactly why new Struts advisories still matter: legacy Java applications often sit on internet-facing portals, partner integrations, admin tools, and line-of-business systems that nobody wants to touch until something breaks.

On October 5, Apache disclosed multiple Struts vulnerabilities on the oss-sec mailing list, including CVE-2026-104713, an important REST plugin issue that can let a single oversized request consume Java heap memory and deny service to other users. Apache recommends upgrading affected deployments to Struts 6.12.0 or 7.4.0.

For SMBs, MSPs, SaaS providers, and government contractors, this is a practical exposure-review item. The question is not just “Do we use Struts?” It is “Which Struts applications are reachable, which plugins or mappers are enabled, and who owns the patch window?”

What Apache disclosed

The most operationally important issue for many teams is CVE-2026-104713. Apache says Struts applications using the REST plugin can read a request body into memory without a bound on how much will be accepted. That means a single request can force memory allocation proportional to the request size, potentially exhausting the Java heap. Applications that do not use the REST plugin are not affected by this specific issue.

Apache also published related Struts advisories the same day:

The affected version ranges are broad. Depending on the specific CVE, they include Struts 2.x, 6.x, and 7.x releases prior to the fixed versions. Apache’s recommended remediation is to upgrade to version 6.12.0 or 7.4.0.

Why this matters

Struts vulnerabilities are rarely just dependency-management trivia. Struts applications are often tied to business workflows that predate the current security team: customer portals, claims systems, procurement tools, case management, reporting dashboards, vendor integrations, and internal admin panels.

That makes the exposure pattern uneven. One organization may have no Struts exposure at all. Another may have one forgotten WAR file behind an old reverse proxy. A third may have several partner-facing Java applications where the framework version is buried in a vendor package or custom build pipeline.

The REST plugin memory exhaustion issue is especially relevant because denial of service can be business-critical even without data theft. If an exposed Java application supports billing, claims processing, logistics, customer service, or contract delivery, a heap-exhaustion path can create real operational impact.

The OGNL advisory deserves separate attention. Even though Apache rates it moderate and limits the affected configuration, OGNL injection has a long history of turning Struts misconfiguration into serious compromise. If an organization uses the legacy RESTful action mapper, the risk profile changes quickly.

Defensive takeaways

  • Inventory Struts applications first. Search source repositories, build manifests, container images, application servers, deployment directories, SBOMs, and vendor documentation for Struts components.
  • Prioritize exposed apps. Patch internet-facing, partner-facing, VPN-adjacent, and privileged internal applications before isolated development or lab systems.
  • Check plugin and mapper usage. Determine whether the REST plugin or legacy RESTful action mapper is enabled. Do not assume default-safe behavior applies to older custom apps.
  • Upgrade to fixed versions. Apache recommends Struts 6.12.0 or 7.4.0 for the disclosed issues. If an application cannot upgrade quickly, document compensating controls and an owner.
  • Constrain request size at the edge. Use reverse proxies, WAFs, application gateways, and server settings to enforce reasonable body-size limits before traffic reaches the Java application.
  • Watch for heap pressure and restarts. Alert on sudden JVM memory growth, repeated garbage collection pressure, 5xx spikes, application-server restarts, and unusual large request bodies.
  • Review OGNL hardening. Confirm Struts 7 allowlist behavior has not been disabled and that legacy mapper usage is intentional, documented, and monitored.
  • Ask vendors directly. If a commercial product embeds Struts, ask whether the product uses affected versions or configurations and when a fixed build will ship.

Government-contractor angle

Government contractors often inherit legacy Java applications through acquisitions, subcontractor portals, customer-specific workflows, or long-running internal systems. Those applications may not hold CUI directly, but they can still support contract performance, reporting, billing, or secure collaboration.

This is where vulnerability management becomes evidence work. A strong response is not just a ticket that says “patch Struts.” It is an asset list, exposure ranking, affected-plugin check, patch record, compensating-control note, and vendor follow-up where needed. That documentation helps during incident response, audits, supplier reviews, and customer security questionnaires.

Bulwark Black assessment

The Struts advisories are a reminder that legacy web frameworks do not disappear just because the industry moved on. They remain in production until someone finds them, owns them, and patches them.

The immediate move is a focused Struts exposure review: find the applications, identify REST plugin and legacy mapper usage, upgrade to 6.12.0 or 7.4.0, and put request-size controls in front of anything that cannot move quickly. That turns four advisories into a concrete hardening sprint instead of another ignored framework alert.

Original source: oss-sec — CVE-2026-104713: Apache Struts REST plugin unbounded request body read