-
Bug
-
Resolution: Fixed
-
Low
-
8.4.0, 7.13.18, 7.19.10, 8.3.2
-
None
-
Severity 3 - Minor
-
40
-
UPDATE 2024-01-16: We have shipped a follow-up fix in Confluence 8.5.5 and 8.7.2 which raises this limit to 10,000 parts for authenticated users. Additionally, we have introduced the system property multipart.authenticated.max.parts which can be used to override the limit for authenticated users. We highly discourage using the previous workaround listed below as this changes the global limit (includes unauthenticated users) and will heighten the risk of DDoS attacks. If you have previously applied this workaround, please remove it as soon as practical.
Issue Summary
As per title. Multipart request is rejected if its request part count exceeds 256.
Steps to Reproduce
- Make a multipart request to any endpoint* - request should have a count of parts (either files or fields) that exceed 256
*In 7.13/7.19, these are only requests that are served by the WebWork servlet. In 8.x, these are requests that are subject to filtering by Struts. REST resources and custom servlets are not subject to this same limit in all versions of Confluence.
Expected Results
Request is processed/successful
Actual Results
The below warning is logged:
Request exceeded allowed number of files! Max allowed files number is: 256
Workaround
For Confluence 8.0 and above:
- Set struts.multipart.maxFiles in confluence.cfg.xml to a custom value.
Do this by adding the following line within the properties element:
<property name="struts.multipart.maxFiles">1000</property>
For Confluence 7.13 and 7.19:
- Set the system property webwork.multipart.maxFiles to a custom value.
Learn how to configure system properties here and then verify it has been applied correctly after system restart here.
DISCLAIMER: Please set this conservatively or you may be vulnerable to DoS. See CVE-2023-24998.
- is related to
-
-
- Closed
-
- is caused by
-
ECOHELP-19951 Loading...
- mentioned in
-