Github: @Deprrous

**Name of the Vulnerable Software and Affected Versions** Apache Wicket versions 8.0.0 through 8.18.0 Apache Wicket versions 9.0.0 through 9.23.0 Apache Wicket versions 10.0.0 through 10.10.0 **Description** An issue exists when parsing multipart requests where the request body has already been consumed by another component, such as a servlet annotated with `@MultipartConfig`, Spring Boot's multipart resolver, or a filter calling `HttpServletRequest#getParameter()`. In these scenarios, the system falls back to reading uploads via `HttpServletRequest#getParts()`, which bypasses the per-file size limit configured via `Form#setFileMaxSize()` and the file count limit configured via `Form#setFileCountMax()`. Consequently, a remote uploader can submit files that exceed the application's permitted size or quantity. Additionally, parts lacking a Content-Type header are read entirely into memory, with the allocation size determined by the request and limited only by external constraints. This affects components that accept uploads, including `Form` with `FileUploadField`, `FileUploadToResourceField`, and `AjaxFileDropBehavior`. **Recommendations** Upgrade Apache Wicket versions 8.0.0 through 8.18.0 to version 8.19.0. Upgrade Apache Wicket versions 9.0.0 through 9.23.0 to version 9.24.0. Upgrade Apache Wicket versions 10.0.0 through 10.10.0 to version 10.11.0. As a workaround, configure equivalent limits in the component that parses the request, such as `spring.servlet.multipart.max-file-size` and `max-request-size`, or `maxFileSize` and `maxRequestSize` within `@MultipartConfig` or the `web.xml` `<multipart-config>` element.