Where
-Infinity
0
Severity
4.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

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.

First published (updated )
Severity
4.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

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.

First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

First published (updated )

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/

First published (updated )

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/

First published (updated )
Severity
7

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.

First published (updated )
Severity
8.1
XEE
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H

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.

First published (updated )

Severity: important

Affected versions:

- Apache Struts (com.opensymphony:xwork) 2.0.0 before 2.2.1 - Apache Struts (org.apache.struts.xwork:xwork-core) 2.2.1 through 6.1.0

Description:

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.

References:

https://cwiki.apache.org/confluence/display/WW/S2-069 https://struts.apache.org/ https://www.cve.org/CVERecord?id=CVE-2025-68493

First published (updated )
Severity
8.2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H

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.4, 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.

1 / 2
Source: GitHub
First published (updated )

Severity: important

Affected versions: - Apache Struts (org.apache.struts:struts2-core) 2.0.0 through 6.7. - Apache Struts (org.apache.struts:struts2-core) 7.0.0 through 7.0.

Description: 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.4, 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.

It's related to https://cve.org/CVERecord?id=CVE-2025-64775 - this CVE addresses missing affected version 6.7.4

Credit: Nicolas Fournier (reporter)

References: https://cwiki.apache.org/confluence/display/WW/S2-068 https://cve.org/CVERecord?id=CVE-2025-64775 https://cve.org/CVERecord?id=CVE-2025-66675 https://struts.apache.org/

Kind regards Łukasz

Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

First published (updated )
Severity
4.6
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Workspace ONE Launcher contains a Privilege Escalation Vulnerability. A malicious actor with physical access to Workspace ONE Launcher could utilize the Edge Panel feature to bypass setup to gain access to sensitive information.

First published (updated )
Severity
8.8
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C

Internet Connection Sharing (ICS) Remote Code Execution Vulnerability

1 / 3
Source: Microsoft
First published (updated )
Severity
8.1
Use After Free
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C

Windows MSHTML Platform Remote Code Execution Vulnerability

1 / 3
Source: Microsoft
First published (updated )
Severity
9.6
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C

Microsoft Power Platform Connector Spoofing Vulnerability

1 / 3
Source: Microsoft
First published (updated )
Severity
8.8
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C

Internet Connection Sharing (ICS) Remote Code Execution Vulnerability

1 / 3
Source: Microsoft
First published (updated )
Severity
5.5
Divide by Zero
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality.

1 / 3
Source: Launchpad
First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

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.

1 / 2
Source: MITRE
First published (updated )
Severity
6.8
OS Command Injection
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

Last updated 22 August 2024

1 / 3
Source: Ubuntu

Remedy

As recommended, use XStream's security framework to implement a whitelist for the allowed types. Users of XStream 1.4.14 who insist to use XStream default blacklist - despite that clear recommendation - can simply add two lines to XStream's setup code: xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.13 who want to use XStream default blacklist can simply add three lines to XStream's setup code: 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 blacklist 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, java.lang.Void and void and deny several types by name pattern. xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, 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: 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.PRIORITY_LOW);
First published (updated )
Severity
7.7
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

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

1 / 4
Source: GitHub

Remedy

As recommended, use XStream's security framework to implement a whitelist for the allowed types. Users of XStream 1.4.14 who insist to use XStream default blacklist - despite that clear recommendation - can simply add two lines to XStream's setup code: xstream.denyTypes(new String[]{ "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypesByRegExp(new String[]{ ".*\\.ReadAllStream\\$FileStream" }); Users of XStream 1.4.13 who want to use XStream default blacklist can simply add three lines to XStream's setup code: 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 blacklist 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, java.lang.Void and void and deny several types by name pattern. xstream.denyTypes(new String[]{ "javax.imageio.ImageIO$ContainsFilter", "jdk.nashorn.internal.objects.NativeString" }); xstream.denyTypes(new Class[]{ java.lang.ProcessBuilder.class, 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: 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.PRIORITY_LOW);
First published (updated )
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
First published (updated )
Severity
8.8
Malicious File Upload
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

A local code execution issue exists in Apache Struts2 when processing malformed XSLT files, which could let a malicious user upload and execute arbitrary files.

First published (updated )
Severity
8.1
Input Validation
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 3
Source: GitHub
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

The Apache Struts REST Plugin is using XStream library which is vulnerable and allow perform a DoS attack when using a malicious request with specially crafted XML payload. Upgrade to the Apache Struts version 2.5.16 and switch to an optional Jackson XML handler as described here http://struts.apache.org/plugins/rest/#custom-contenttypehandlers. Another option is to implement a custom XML handler based on the Jackson XML handler from the Apache Struts 2.5.16.

First published (updated )
Severity
8.1
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 3
Source: CISA
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

When using a Spring AOP functionality to secure Struts actions it is possible to perform a DoS attack. Solution is to upgrade to Apache Struts version 2.5.12 or 2.3.33.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203