CVE-2020-26259: XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling

Published Dec 13, 2020
·
Updated

Last updated 22 August 2024

Other sources

XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.15, is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling. The vulnerability may allow a remote attacker to delete arbitrary know files on the host as log as the executing process has sufficient rights only by manipulating the processed input stream. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.15. 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 want to use XStream default blacklist can use a workaround described in more detailed in the referenced advisories.

Affected Software

10 affected componentsFixes available
redhat/xstream<1.4.15
1.4.15
debian/libxstream-java
1.4.15-3+deb11u21.4.15-3+deb11u31.4.20-1+deb12u11.4.21-1
Xstream Project Xstream<1.4.15
Debian Debian Linux=9.0
Debian Debian Linux=10.0
Fedoraproject Fedora=33
Fedoraproject Fedora=34
Fedoraproject Fedora=35
Apache struts<6.0.0
XStream XStream<1.4.15

Remediation

Information

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);

Event History

Dec 13, 2020
CVE Published
12:00 AM
Data Sourced
12:00 AM
RemedyDescriptionSeverityWeaknessAffected Software
Dec 16, 2020
CVE Published
via MITRE·01:05 AM
Data Sourced
via MITRE·01:05 AM
DescriptionSeverityWeakness
Dec 17, 2020
Data Sourced
via Red Hat·05:40 PM
DescriptionSeverityAffected Software
Aug 26, 2024
Data Sourced
via Launchpad·04:27 PM
Description
Sep 15, 2024
Data Sourced
via Ubuntu·04:29 PM
RemedyDescriptionSeverityAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is CVE-2020-26259?

CVE-2020-26259 is a vulnerability in the XStream Java library that allows remote attackers to delete arbitrary known files on the host.

2

What is the severity of CVE-2020-26259?

CVE-2020-26259 has a severity rating of 6.8, which is considered medium.

3

Which software versions are affected by CVE-2020-26259?

Versions of XStream before 1.4.15 are affected by CVE-2020-26259.

4

How can I fix CVE-2020-26259?

To fix CVE-2020-26259, upgrade to XStream version 1.4.15 or later.

5

Are there any references related to CVE-2020-26259?

Yes, you can find more information about CVE-2020-26259 at the following references: [Github Advisory](https://github.com/x-stream/xstream/security/advisories/GHSA-jfvx-7wrx-43fh), [XStream CVE-2020-26259](https://x-stream.github.io/CVE-2020-26259.html), [Red Hat Bugzilla](https://bugzilla.redhat.com/show_bug.cgi/show_bug.cgi?id=1908838).

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