src/site/xdoc/security.xml - commons-fileupload - Git at Google

 <?xml version="1.0"?>
 <!--

    Licensed to the Apache Software Foundation (ASF) under one or more
    contributor license agreements.  See the NOTICE file distributed with
    this work for additional information regarding copyright ownership.
    The ASF licenses this file to You under the Apache License, Version 2.0
    (the "License"); you may not use this file except in compliance with
    the License.  You may obtain a copy of the License at

        https://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
 -->
 <document>
     <properties>
         <title>Commons FileUpload Security Reports</title>
         <author email="dev@commons.apache.org">Apache Commons Team</author>
     </properties>
     <body>
       <section name="Apache Commons FileUpload Security Vulnerabilities">
         <p>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.</p>

         <p>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.</p>

         <p>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 <a href="mail-lists.html">Commons Users mailing
         list</a>.</p>

         <p>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.</p>

         <p>For information about reporting or asking questions about
         security problems, please see the <a
         href="https://commons.apache.org/security.html">security page
         of the Apache Commons project</a>.</p>

         <subsection name="Fixed in Apache Commons FileUpload 2.0.0-M4">
           <p><b>Important: Denial of Service</b> <a
           href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48976">CVE-2025-48976</a></p>

           <p>Apache Commons FileUpload 2.x before 2.0.0-M4 provides a hard-coded
           limit of 10kB for the size of the headers associated with a multipart
           request. A specially crafted request that used a large number of parts
           with large headers could trigger excessive memory usage on the server
           leading to a DoS. This limit is now configurable
           (FileUploadBase#setPartHeaderSizeMax) with a default of 512 bytes.</p>

           <p>This was fixed in commit
           <a href="https://github.com/apache/commons-fileupload/commit/e5b5543b3a40ac9dde3c33ef1858901b3ca6656a"
           >e5b5543b</a>.</p>

           <p>Affects: 2.0.0-M1 - 2.0.0-M4</p>
         </subsection>

         <subsection name="Fixed in Apache Commons FileUpload 2.0.0-M1">
           <p>
             Starting in version 2.0.0-M1, no FileUpload classes implement Serializable.
           </p>
         </subsection>

         <subsection name="Fixed in Apache Commons FileUpload 1.6.0">
           <p><b>Important: Denial of Service</b> <a
           href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48976">CVE-2025-48976</a></p>

           <p>Apache Commons FileUpload 1.x before 1.6.0 provides a hard-coded
           limit of 10kB for the size of the headers associated with a multipart
           request. A specially crafted request that used a large number of parts
           with large headers could trigger excessive memory usage on the server
           leading to a DoS. This limit is now configurable
           (FileUploadBase#setPartHeaderSizeMax) with a default of 512 bytes.</p>

           <p>This was fixed in commit
           <a href="https://github.com/apache/commons-fileupload/commit/2108495a4775910b8559f18ed5a779d60542ee96"
           >2108495a</a>.</p>

           <p>Affects: 1.0 - 1.5</p>
         </subsection>

         <subsection name="Fixed in Apache Commons FileUpload 1.5">
           <p><b>Important: Denial of Service</b> <a
           href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998">CVE-2023-24998</a></p>

           <p>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.</p>

           <p>This was fixed in commit
           <a href="https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17"
           >e20c0499</a>.</p>

           <p>Affects: 1.0? - 1.4</p>
         </subsection>

         <subsection name="Notes on Apache Commons FileUpload 1.3.3">
           <p>
             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.
           </p>
           <p>
             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.
           </p>
           <p>
             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.
           </p>
           <p>
             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".
           </p>
         </subsection>

         <subsection name="Fixed in Apache Commons FileUpload 1.3.2">
           <p><b>Low: Denial of Service</b> <a
           href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3092">CVE-2016-3092</a></p>

           <p>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 <a href="https://tomcat.apache.org/security.html">Apache Tomcat</a>.</p>

           <p>This was fixed in revision
           <a href="https://svn.apache.org/viewvc?view=revision&amp;revision=1743480">1743480</a>.</p>

           <p>Affects: 1.0? - 1.3.1</p>
         </subsection>

         <subsection name="Fixed in Apache Commons FileUpload 1.3.1">
           <p><b>Low: Denial of Service</b> <a
           href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-0050">CVE-2014-0050</a></p>

           <p>MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in
           <a href="https://tomcat.apache.org/security.html">Apache Tomcat</a>,
           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.</p>

           <p>This was fixed in revision
           <a href="https://svn.apache.org/viewvc?view=revision&amp;revision=1565143">1565143</a>.</p>

           <p>Affects: 1.0? - 1.3</p>
         </subsection>

         <subsection name="Fixed in Apache Commons FileUpload 1.3">

           <p><b>Low: Improved Documentation for Multitenancy</b> <a
           href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0248">CVE-2013-0248</a></p>

           <p>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.</p>

           <p>This was fixed in revision
           <a href="https://svn.apache.org/viewvc?view=revision&amp;revision=1453273">1453273</a>.</p>

           <p>Affects: 1.0 - 1.2.2</p>
         </subsection>

 		</section>

       <section name="Errors and Ommissions">
         <p>Please report any errors or omissions to <a
         href="mail-lists.html">the dev mailing list</a>.</p>
       </section>
     </body>
 </document>
	<?xml version="1.0"?>
	<!--

	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	https://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->
	<document>
	<properties>
	<title>Commons FileUpload Security Reports</title>
	<author email="dev@commons.apache.org">Apache Commons Team</author>
	</properties>
	<body>
	<section name="Apache Commons FileUpload Security Vulnerabilities">
	<p>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.</p>

	<p>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.</p>

	<p>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 <a href="mail-lists.html">Commons Users mailing
	list</a>.</p>

	<p>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.</p>

	<p>For information about reporting or asking questions about
	security problems, please see the <a
	href="https://commons.apache.org/security.html">security page
	of the Apache Commons project</a>.</p>

	<subsection name="Fixed in Apache Commons FileUpload 2.0.0-M4">
	<p><b>Important: Denial of Service</b> <a
	href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48976">CVE-2025-48976</a></p>

	<p>Apache Commons FileUpload 2.x before 2.0.0-M4 provides a hard-coded
	limit of 10kB for the size of the headers associated with a multipart
	request. A specially crafted request that used a large number of parts
	with large headers could trigger excessive memory usage on the server
	leading to a DoS. This limit is now configurable
	(FileUploadBase#setPartHeaderSizeMax) with a default of 512 bytes.</p>

	<p>This was fixed in commit
	<a href="https://github.com/apache/commons-fileupload/commit/e5b5543b3a40ac9dde3c33ef1858901b3ca6656a"
	>e5b5543b</a>.</p>

	<p>Affects: 2.0.0-M1 - 2.0.0-M4</p>
	</subsection>

	<subsection name="Fixed in Apache Commons FileUpload 2.0.0-M1">
	<p>
	Starting in version 2.0.0-M1, no FileUpload classes implement Serializable.
	</p>
	</subsection>

	<subsection name="Fixed in Apache Commons FileUpload 1.6.0">
	<p><b>Important: Denial of Service</b> <a
	href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48976">CVE-2025-48976</a></p>

	<p>Apache Commons FileUpload 1.x before 1.6.0 provides a hard-coded
	limit of 10kB for the size of the headers associated with a multipart
	request. A specially crafted request that used a large number of parts
	with large headers could trigger excessive memory usage on the server
	leading to a DoS. This limit is now configurable
	(FileUploadBase#setPartHeaderSizeMax) with a default of 512 bytes.</p>

	<p>This was fixed in commit
	<a href="https://github.com/apache/commons-fileupload/commit/2108495a4775910b8559f18ed5a779d60542ee96"
	>2108495a</a>.</p>

	<p>Affects: 1.0 - 1.5</p>
	</subsection>

	<subsection name="Fixed in Apache Commons FileUpload 1.5">
	<p><b>Important: Denial of Service</b> <a
	href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998">CVE-2023-24998</a></p>

	<p>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.</p>

	<p>This was fixed in commit
	<a href="https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17"
	>e20c0499</a>.</p>

	<p>Affects: 1.0? - 1.4</p>
	</subsection>

	<subsection name="Notes on Apache Commons FileUpload 1.3.3">
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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".
	</p>
	</subsection>

	<subsection name="Fixed in Apache Commons FileUpload 1.3.2">
	<p><b>Low: Denial of Service</b> <a
	href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3092">CVE-2016-3092</a></p>

	<p>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 <a href="https://tomcat.apache.org/security.html">Apache Tomcat</a>.</p>

	<p>This was fixed in revision
	<a href="https://svn.apache.org/viewvc?view=revision&revision=1743480">1743480</a>.</p>

	<p>Affects: 1.0? - 1.3.1</p>
	</subsection>

	<subsection name="Fixed in Apache Commons FileUpload 1.3.1">
	<p><b>Low: Denial of Service</b> <a
	href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-0050">CVE-2014-0050</a></p>

	<p>MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in
	<a href="https://tomcat.apache.org/security.html">Apache Tomcat</a>,
	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.</p>

	<p>This was fixed in revision
	<a href="https://svn.apache.org/viewvc?view=revision&revision=1565143">1565143</a>.</p>

	<p>Affects: 1.0? - 1.3</p>
	</subsection>

	<subsection name="Fixed in Apache Commons FileUpload 1.3">

	<p><b>Low: Improved Documentation for Multitenancy</b> <a
	href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0248">CVE-2013-0248</a></p>

	<p>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.</p>

	<p>This was fixed in revision
	<a href="https://svn.apache.org/viewvc?view=revision&revision=1453273">1453273</a>.</p>

	<p>Affects: 1.0 - 1.2.2</p>
	</subsection>

	</section>

	<section name="Errors and Ommissions">
	<p>Please report any errors or omissions to <a
	href="mail-lists.html">the dev mailing list</a>.</p>
	</section>
	</body>
	</document>