Details
-
Bug
-
Resolution: Fixed
-
Highest
-
8.5.0, 8.6.0, 8.4.1, 8.5.2, 8.5.3
-
None
-
21
-
Severity 3 - Minor
-
161
-
Description
UPDATE 2024-01-16: We have shipped a fix which raises this limit to 100,000 bytes for authenticated users. Additionally, we have introduced the system property multipart.authenticated.max.param.length 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.
Please check the following KB article to see how you can define the newly introduced system property (multipart.authenticated.max.param.length) based on your OS and your startup method:
Issue Summary
As per title. Multipart request form parameter is rejected if its length exceeds 4096 bytes.
Steps to Reproduce
- Make a multipart request to any endpoint* - request should have a multipart form parameter with length exceeding 4096 bytes
* REST resources and custom servlets are not subject to this limit.
Expected Results
Request is processed/successful with lengthy parameter retained
Actual Results
The multipart request parameter exceeding the length limit is discarded from the parsed request.
Workaround
Set struts.multipart.maxStringLength in confluence.cfg.xml to a custom value.
Do this by adding the following line within the properties element:
<property name="struts.multipart.maxStringLength">10000</property>
DISCLAIMER: Please set this conservatively or you may be vulnerable to DoS. See CVE-2023-34396.
Note for Plugin Vendors
To prevent unexpected exceptions, multipart requests should be validated for errors prior to processing.
This can be done using com.atlassian.confluence.util.StrutsUtil#localizeMultipartErrorMessages or org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper#getErrors.
Attachments
Issue Links
- relates to
-
-
- Closed
-