https://seclists.org/oss-sec/2026/q3/616: CVE-2026-71257: Apache Wicket: Configud file upload limits anot enforced when the multipart quest has alady been parsed

Q: Which deployments are exposed to this issue?

Applications using wicket-core 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, or 10.0.0 through 10.10.0 are affected when another component consumes a multipart request before Wicket processes it. The fallback to HttpServletRequest#getParts() is the condition under which Wicket’s configured per-file and file-count limits are bypassed.

Q: What does an attacker need to do to exploit the limit bypass?

A remote uploader needs to submit a multipart upload request that reaches Wicket after its body has already been parsed by another component. They can then provide files larger than the configured per-file limit or more files than the configured file-count limit, subject to limits enforced by the component that parsed the request first.

Q: Does this affect uploads that Wicket parses normally?

No. Wicket enforces the configured form or upload-field limits when it parses the multipart request through Apache Commons FileUpload. The bypass occurs only when Commons FileUpload finds no items because another component has already consumed the request and Wicket falls back to request parts.

Q: What is the memory-related concern during exploitation?

A multipart part without a Content-Type header is read fully into memory during parsing. Its allocation size is controlled by the request and is bounded only by the limits imposed by the component that parsed the request, rather than Wicket’s per-file or file-count limits.

Published Aug 30, 2026

Updated

Affected Software

6 affected components

Apache wicket>=8.0.0<=8.18.0

Apache wicket>=9.0.0<=9.23.0

Apache wicket>=10.0.0<=10.10.0

Apache wicket<8.19.0

Apache wicket<9.24.0

Apache wicket<10.11.0

Frequently Asked Questions

Which deployments are exposed to this issue?

Applications using wicket-core 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, or 10.0.0 through 10.10.0 are affected when another component consumes a multipart request before Wicket processes it. The fallback to HttpServletRequest#getParts() is the condition under which Wicket’s configured per-file and file-count limits are bypassed.

What does an attacker need to do to exploit the limit bypass?

A remote uploader needs to submit a multipart upload request that reaches Wicket after its body has already been parsed by another component. They can then provide files larger than the configured per-file limit or more files than the configured file-count limit, subject to limits enforced by the component that parsed the request first.

Does this affect uploads that Wicket parses normally?

No. Wicket enforces the configured form or upload-field limits when it parses the multipart request through Apache Commons FileUpload. The bypass occurs only when Commons FileUpload finds no items because another component has already consumed the request and Wicket falls back to request parts.

What is the memory-related concern during exploitation?

A multipart part without a Content-Type header is read fully into memory during parsing. Its allocation size is controlled by the request and is bounded only by the limits imposed by the component that parsed the request, rather than Wicket’s per-file or file-count limits.