Apache Commons logo Commons FileUpload

Apache Commons FileUpload Security Vulnerabilities

This page lists all security vulnerabilities fixed in released versions of Apache Commons FileUpload. Each vulnerability is given a security impact rating by the development team - please note that this rating may vary from platform to platform. We also list the versions of Commons FileUpload the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Please note that binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Commons FileUpload version that you are using.

If you need help on building Commons FileUpload or other help on following the instructions to mitigate the known vulnerabilities listed here, please send your questions to the public Commons Users mailing list.

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Apache Security Team. Thank you.

For information about reporting or asking questions about security problems, please see the security page of the Apache Commons project.

Notes on Apache Commons FileUpload 1.3.3

Regarding potential security problems with the class called DiskFileItem, it is true, that this class exists, and can be serialized/deserialized in FileUpload versions, up to, and including 1.3.2. It is also true, that a malicious attacker can abuse this possibility to create abitraryly located files (assuming the required permissions) with arbitrary contents, if he gets the opportunity to provide specially crafted data, which is being deserialized by a Java application, which has either of the above versions of Commons FileUpload in the classpath, and which puts no limitations on the classes being deserialized.

That being said, we (the Apache Commons team) hold the view, that the actual problem is not the DiskFileItem class, but the "if" in the previous sentence. A Java application should carefully consider, which classes can be deserialized. A typical approach would be, for example, to provide a blacklist, or whitelist of packages, and/or classes, which may, or may not be deserialized.

On the other hand, we acknowledge, that the likelyhood of application container vendors taking such a simple security measure is extremely low. So, in order to support the Commons Fileupload users, we have decided to choose a different approach:

Beginning with 1.3.3, the class DiskFileItem is still implementing the interface java.io.Serializable. In other words, it still declares itself as serializable, and deserializable to the JVM. In practice, however, an attempt to deserialize an instance of DiskFileItem will trigger an Exception. In the unlikely case, that your application depends on the deserialization of DiskFileItems, you can revert to the previous behaviour by setting the system property "org.apache.commons.fileupload.disk.DiskFileItem.serializable" to "true".

Fixed in Apache Commons FileUpload 1.3.2

Low: Denial of Service CVE-2016-3092

Specially crafted input can trigger a DoS (slow uploads), if the size of the MIME boundary is close to the size of the buffer in MultipartStream. This is also fixed for Apache Tomcat.

This was fixed in revisions 1743480.

Affects: 1.0? - 1.3.1

Fixed in Apache Commons FileUpload 1.3.1

Low: Denial of Service CVE-2014-0050

MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in Apache Tomcat, JBoss Web, and other products, allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted Content-Type header that bypasses a loop's intended exit conditions.

This was fixed in revisions 1565143.

Affects: 1.0? - 1.3

Fixed in Apache Commons FileUpload 1.3

Low: Improved Documentation for Multitenancy CVE-2013-0248

Update the Javadoc and documentation to make it clear that setting a repository is required for a secure configuration if there are local, untrusted users.

This was fixed in revisions 1453273.

Affects: 1.0 - 1.2.2

Errors and Ommissions

Please report any errors or omissions to the dev mailing list.