FileUpload – Commons FileUpload Security Reports

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 behavior 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.

Fixed in Apache Commons FileUpload 2.0.0-M1

Starting in version 2.0.0-M1, no FileUpload classes implement Serializable.

Fixed in Apache Commons FileUpload 1.5

Important: Denial of Service CVE-2023-24998

Apache Commons FileUpload before 1.5 does not provide an option to limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured.

This was fixed in commit e20c0499.

Affects: 1.0? - 1.4

Notes on Apache Commons FileUpload 1.3.3

Up to, and including version 1.3.2, the class org.apache.commons.fileupload2.disk.DiskFileItem can be serialized and deserialized. A malicious attacker can abuse this feature to arbitrarily create files with any content, assuming the required permissions for a given file location. If an attacker gets the opportunity to provide maliciously crafted data and an application puts no limitations on classes being deserialized, that data can then be deserialized by a Java application.

We hold the view that the actual problem is not the DiskFileItem class, but that a Java application should carefully consider which classes can be deserialized. A typical approach would be, for example, to provide a deny list, or an accept list of packages, and/or classes, which may, or may not be deserialized.

We acknowledge that the likelihood of application container vendors taking such a simple security measure is extremely low. In order to better support Commons FileUpload users, we chose a different approach.

Starting with version 1.3.3, the class DiskFileItem still implements the interface java.io.Serializable but attempts 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 behavior 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 revision 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 revision 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 revision 1453273.

Affects: 1.0 - 1.2.2

Errors and Ommissions

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