Exposure of data element to wrong session vulnerability in the JSON plugin of Apache Struts. Per-request parsing state could be shared across concurrent requests, allowing data associated with one request to become observable in another, and configured parsing limits not to be enforced as intended. Populating actions from a JSON request body is not enabled by default; applications that do not use the JSON plugin are not affected.
This issue affects Apache Struts: 7.2.1.
Users are recommended to upgrade to version 7.3.0, which fixes the issue.
Exposure of data element to wrong session vulnerability in the JSON plugin of Apache Struts. Per-response serialization state could be shared across concurrent requests, allowing response content associated with one request to become observable in another. Only the SMD / JSON-RPC handling of the JSON interceptor is affected, which is not enabled by default; applications using the json result type are not affected.
This issue affects Apache Struts: 7.2.1.
Users are recommended to upgrade to version 7.3.0, which fixes the issue.
Uncontrolled resource consumption vulnerability in Apache Struts. An application that exposes an endpoint collecting Content Security Policy violation reports reads the submitted report into memory without bounding how much it will accept, so a single request can exhaust the heap and deny service to other users. Such endpoints are ordinarily reachable without authentication. The core distribution maps no such endpoint by default; applications that do not collect violation reports are not affected.
This issue affects Apache Struts: from 6.0.0 through 6.10.0, from 7.0.0 through 7.2.1.
Users are recommended to upgrade to version 6.11.0 or 7.3.0, which fixes the issue.
Allocation of resources without limits or throttling vulnerability in Apache Struts. When no fixed locale is configured, the locale used for localized-text lookups is taken from the incoming request, allowing an unauthenticated remote client to cause the framework's internal localized-text caches to grow without bound and exhaust the Java heap, denying service to other users. Applications that configure a fixed locale are not affected.
This issue affects Apache Struts: from 2.0.0 through 2.3.37, from 2.5.0 through 2.5.33, from 6.0.0 through 6.10.0, from 7.0.0 through 7.2.1.
Users are recommended to upgrade to version 6.11.0 or 7.3.0, which fixes the issue.
Uncontrolled resource consumption vulnerability in the JSON plugin of Apache Struts. When an application is configured to populate actions from a JSON request body, the plugin reads that body into memory without bounding how much it will accept, so a single request can exhaust the heap and deny service to other users. The plugin's configurable JSON input length limit does not bound this read. The JSON plugin is an optional component; applications that do not use it, or use it without enabling JSON request-body handling, are not affected.
This issue affects Apache Struts: from 2.1.8 through 2.3.37, from 2.5.0 through 2.5.33, from 6.0.0 through 6.10.0, from 7.0.0 through 7.2.1.
Users are recommended to upgrade to version 6.11.0 or 7.3.0, which fixes the issue.
Missing XML Validation vulnerability in Apache Struts, Apache Struts.
This issue affects Apache Struts: from 2.0.0 before 2.2.1; Apache Struts: from 2.2.1 through 6.1.0.
Users are recommended to upgrade to version 6.1.1, which fixes the issue.
Allocation of Resources Without Limits or Throttling vulnerability in Apache Software Foundation Apache Struts.This issue affects Apache Struts: through 2.5.30, through 6.1.2.
Upgrade to Struts 2.5.31 or 6.1.2.1 or greater
Allocation of Resources Without Limits or Throttling vulnerability in Apache Software Foundation Apache Struts.This issue affects Apache Struts: through 2.5.30, through 6.1.2.
Upgrade to Struts 2.5.31 or 6.1.2.1 or greater.
Forced OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution. Affected software : Apache Struts 2.0.0 - Struts 2.5.25.
Apache Struts contains a Remote Code Execution when using results with no namespace and it's upper actions have no or wildcard namespace. The same flaw exists when using a url tag with no value, action set, and it's upper actions have no or wildcard namespace.
Apache Struts REST Plugin uses an XStreamHandler with an instance of XStream for deserialization without any type filtering, which can lead to remote code execution when deserializing XML payloads.
The Struts 1 plugin in Apache Struts 2.1.x and 2.3.x might allow remote code execution via a malicious field value passed in a raw message to the ActionMessage.
Apache Struts Jakarta Multipart parser allows for malicious file upload using the Content-Type value, leading to remote code execution.
Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar in Apache Struts 1.x through 1.3.10 and in other products requiring commons-beanutils through 1.9.2, does not suppress the class property, which allows remote attackers to "manipulate" the ClassLoader and execute arbitrary code via the class parameter, as demonstrated by the passing of this parameter to the getClass method of the ActionForm object in Struts 1.
CookieInterceptor in Apache Struts before 2.3.20, when a wildcard cookiesName value is used, does not properly restrict access to the getClass method, which allows remote attackers to "manipulate" the ClassLoader and execute arbitrary code via a crafted request. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-0094.
It was found that the fix for CVE-2014-0094 was incomplete. The Struts 2 ParametersInterceptor was updated to block access to the 'class' parameter, but not all forms in which this parameter can be specified were blocked. A remote attacker could use this flaw to manipulate the ClassLoader used by the application server running Struts 2. This could lead to arbitrary remote code execution under certain conditions.
This flaw is reported to affect Struts 2.0.0 through to Struts 2.3.16.1. It is corrected in 2.3.16.2.
External References:
https://cwiki.apache.org/confluence/display/WW/S2-021
It was found that the Struts 2 ParametersInterceptor allows access to the 'class' parameter, which is directly mapped to the getClass() method. A remote attacker could use this flaw to manipulate the ClassLoader used by the application server running Struts 2. This could lead to arbitrary remote code execution under certain conditions.
This flaw is reported to affect Struts 2.0.0 through to Struts 2.3.16. It is corrected in 2.3.16.1.
External References:
https://cwiki.apache.org/confluence/display/WW/S2-020
Multiple cross-site scripting (XSS) vulnerabilities in Apache Struts 2.3.15.3 allow remote attackers to inject arbitrary web script or HTML via the namespace parameter to (1) actionNames.action and (2) showConfig.action in config-browser/.
Apache Struts 2.0.0 through 2.3.15 allows remote attackers to execute arbitrary OGNL expressions via a parameter with a crafted (1) action:, (2) redirect:, or (3) redirectAction: prefix.
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during certain exception handling for mismatched data types of properties, which allows remote attackers to execute arbitrary Java code via a crafted parameter.
Multiple directory traversal vulnerabilities in Apache Struts 2.0.x before 2.0.12 and 2.1.x before 2.1.3 allow remote attackers to read arbitrary files via a ..%252f (encoded dot dot slash) in a URI with a /struts/ path, related to (1) FilterDispatcher in 2.0.x and (2) DefaultStaticContentLoader in 2.1.x.
ParametersInterceptor in OpenSymphony XWork 2.0.x before 2.0.6 and 2.1.x before 2.1.2, as used in Apache Struts and other products, does not properly restrict # (pound sign) references to context objects, which allows remote attackers to execute Object-Graph Navigation Language (OGNL) statements and modify server-side context objects, as demonstrated by use of a \u0023 representation for the # character.
ActionForm in Apache Software Foundation (ASF) Struts before 1.2.9 with BeanUtils 1.7 allows remote attackers to cause a denial of service via a multipart/form-data encoded form with a parameter name that references the public getMultipartRequestHandler method, which provides further access to elements in the CommonsMultipartRequestHandler implementation and BeanUtils.
Last updated 22 August 2024
Impact The vulnerability may allow a remote attacker to request data from internal resources that are not publicly available only by manipulating the processed input stream.
Patches If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.15.
Workarounds The reported vulnerability does not exist running Java 15 or higher.
No user is affected, who followed the recommendation to setup XStream's Security Framework with a whitelist! Anyone relying on XStream's default blacklist can immediately switch to a whilelist for the allowed types to avoid the vulnerability.
Users of XStream 1.4.14 or below who still insist to use XStream default blacklist - despite that clear recommendation - can use a workaround depending on their version in use.
Users of XStream 1.4.14 can simply add two lines to XStream's setup code: Java xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypesByRegExp(new String[]{ ".\\.ReadAllStream\\$FileStream" });
Users of XStream 1.4.14 to 1.4.13 can simply add three lines to XStream's setup code: Java xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class }); xstream.denyTypesByRegExp(new String[]{ ".\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.12 to 1.4.7 who want to use XStream with a black list will have to setup such a list from scratch and deny at least the following types: javax.imageio.ImageIO$ContainsFilter, java.beans.EventHandler, java.lang.ProcessBuilder, jdk.nashorn.internal.objects.NativeString.class, java.lang.Void and void and deny several types by name pattern. Java xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, "jdk.nashorn.internal.objects.NativeString", java.beans.EventHandler.class, java.lang.ProcessBuilder.class, java.lang.Void.class, void.class }); xstream.denyTypesByRegExp(new String[]{ ".\\$LazyIterator", "javax\\.crypto\\..", ".\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.6 or below can register an own converter to prevent the unmarshalling of the currently know critical types of the Java runtime. It is in fact an updated version of the workaround for CVE-2013-7285: Java xstream.registerConverter(new Converter() { public boolean canConvert(Class type) { return type != null && (type == java.beans.EventHandler.class || type == java.lang.ProcessBuilder.class || type.getName().equals("javax.imageio.ImageIO$ContainsFilter") || type.getName().equals("jdk.nashorn.internal.objects.NativeString") || type == java.lang.Void.class || void.class || Proxy.isProxy(type)) || type.getName().startsWith("javax.crypto.") || type.getName().endsWith("$LazyIterator") || type.getName().endsWith(".ReadAllStream$FileStream")); }
public Object unmarshal(HierarchicalStreamReader reader, UnmarshallingContext context) { throw new ConversionException("Unsupported type due to security reasons."); }
public void marshal(Object source, HierarchicalStreamWriter writer, MarshallingContext context) { throw new ConversionException("Unsupported type due to security reasons."); } }, XStream.PRIORITYLOW); For more information If you have any questions or comments about this advisory: Open an issue in XStream Contact us at XStream Google Group
CookieInterceptor in Apache Struts 2.x before 2.3.20, when a wildcard cookiesName value is used, does not properly restrict access to the getClass method, which allows remote attackers to "manipulate" the ClassLoader and modify session state via a crafted request. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-0113.
Missing XML Validation vulnerability in Apache Struts, Apache Struts.
This issue affects Apache Struts: from 2.0.0 before 2.2.1; Apache Struts: from 2.2.1 through 6.1.0.
Users are recommended to upgrade to version 6.1.1, which fixes the issue.
Denial of Service vulnerability in Apache Struts, file leak in multipart request processing causes disk exhaustion.
This issue affects Apache Struts: from 2.0.0 through 6.7.0, from 7.0.0 through 7.0.3.
Users are recommended to upgrade to version 6.8.0 or 7.1.1, which fixes the issue.
So there is a thing or two that the IT industry can learn from software projects like OpenBSD.
OpenBSD has been advocating for this for years now :-)
On Mon, 12 Jan 2026 at 18:58, Hanno Böck <hanno () hboeck de> wrote: Looking through recent mails on this list with XXE in the toppic, I see:
XXE in Apache Struts due to insecure defaults in Java's standard library: CVE-2025-68493 XXE in Apache SIS due to insecure defaults in Java's standard library: CVE-2025-68280 XXE in Apache Tika due to insecure defaults in Java's standard library: CVE-2025-54988, CVE-2025-66516 XXE in Apache Jackrabbit due to insecure defaults in Java's standard library: CVE-2025-53689 XXE in Apache Ambari due to insecure defaults in Java's standard library: CVE-2025-23195 XXE in Apache XML Graphics FOP due to insecure defaults in Java's standard library: CVE-2024-28168 XXE in Apache Drill due to insecure defaults in Java's standard library: CVE-2023-48362
Also recently: my research on prevalent XXEs in electronic invoicing software, largely due to insecure defaults in Java and Saxon (which is based on Java): https://invoice.secvuln.info/
I'm sensing a pattern here. Maybe Apache should audit all their uses of Apache's XML standard library. And, maybe, having insecure defaults in Java's standard library is not so great.
-- Hanno Böck - Independent security researcher https://itsec.hboeck.de/ https://badkeys.info/
Looking through recent mails on this list with XXE in the toppic, I see:
XXE in Apache Struts due to insecure defaults in Java's standard library: CVE-2025-68493 XXE in Apache SIS due to insecure defaults in Java's standard library: CVE-2025-68280 XXE in Apache Tika due to insecure defaults in Java's standard library: CVE-2025-54988, CVE-2025-66516 XXE in Apache Jackrabbit due to insecure defaults in Java's standard library: CVE-2025-53689 XXE in Apache Ambari due to insecure defaults in Java's standard library: CVE-2025-23195 XXE in Apache XML Graphics FOP due to insecure defaults in Java's standard library: CVE-2024-28168 XXE in Apache Drill due to insecure defaults in Java's standard library: CVE-2023-48362
Also recently: my research on prevalent XXEs in electronic invoicing software, largely due to insecure defaults in Java and Saxon (which is based on Java): https://invoice.secvuln.info/
I'm sensing a pattern here. Maybe Apache should audit all their uses of Apache's XML standard library. And, maybe, having insecure defaults in Java's standard library is not so great.
-- Hanno Böck - Independent security researcher https://itsec.hboeck.de/ https://badkeys.info/