Undertow has fixed a CVE regarding a potential memory leak.
Since this fix, if you upload a part that is larger than the 16384 byte limit that is imposed, the parsing of a request goes wrong here because Undertow has created a "file" part that has a Disposition header without a filename:
https://github.com/spring-projects/spring-framework/blob/b61552b9df8e3f18f901fd30996ae0ec0f222060/spring-web/src/main/java/org/springframework/web/multipart/support/StandardMultipartHttpServletRequest.java#L99
Comment From: Laurens-W
As I clicked submit I realized this should be filed under spring-framework and not spring-boot
Comment From: bclozel
I don't understand. What is the ask here? How should we update Spring Framework? This CVE is fixed in Undertow but I don't see how this is impacting our support.
If you believe there is a CVE in Spring Framework, please reach out to us responsibly via https://spring.io/security-policy
Comment From: jhoeller
If Undertow exposes a Content-Disposition header without a filename to us now, how are we supposed to differentiate between a regular form field and an uploaded file then? We need to see the original Content-Disposition header that the client sent there.
Comment From: Laurens-W
I wasn't too sure whether it was a spring issue or an Undertow issue, but giving it another thought After Juergen's comment I think this should be filed as an issue with Undertow! Undertow is providing a Content-Disposition header that doesn't match with them writing the part to a file.
Comment From: bclozel
I guess they're not fixing the case where the given file name is null, but only fixing the fact that they'll make up a file name of their own when writing to disk for temporary storage. So this doesn't change anything to our support, it's rather an internal matter for Undertow. If you believe something needs to be done here or in Undertow, please create first a sample application that demonstrates the problem and share it with the relevant team. I'll close this issue now.
Comment From: Laurens-W
FYI https://github.com/undertow-io/undertow/pull/1541#issuecomment-1921364323 I've created a reproducer and mentioned that on a PR that proposes a fix related to this problem
Comment From: Laurens-W
FYI: Undertow has merged a fix for this problem, and has release a 2.3.11.Final version