CVE-2026-71257: Software Security Vulnerability Vulnerability
HIGHCVE-2026-71257 is a HIGH (CVSS 7.5) security vulnerability vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Software libraries in the Maven ecosystem. The weakness occurs when the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.. Remediation is available in the latest vendor maintenance releases.
CVE-2026-71257 at a Glance
Security Impact
CVSS: 7.5
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
How to Fix CVE-2026-71257
To remediate this vulnerability, upgrade all affected Software dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
mvn dependency:treeHow to Check if You Are Affected
To determine whether your Java application is affected by CVE-2026-71257, inspect your build dependencies using the Maven Dependency Plugin:
mvn dependency:treeAnalyze the terminal output to locate any version of Software in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.
Note: The mvn dependency:tree command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Software, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
References
Frequently Asked Questions
What is CVE-2026-71257?
Which Software versions are affected?
What version fixes CVE-2026-71257?
What is the CVSS score of CVE-2026-71257?
What CWE is associated with CVE-2026-71257?
How can I check Maven dependencies for CVE-2026-71257?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-qx8r-cr7v-r5mp",
"modified" : "2026-09-01T18:30:33Z",
"published" : "2026-08-31T12:30:24Z",
"aliases" : [ "CVE-2026-71257" ],
"details" : "Apache Wicket enforces the upload limits configured on a form or upload field while parsing a multipart request with Apache Commons FileUpload. If the request body has already been consumed by another component, Commons FileUpload returns no items and Wicket falls back to reading the upload through HttpServletRequest#getParts(). The per-file size limit (for example Form#setFileMaxSize) and the file count limit (Form#setFileCountMax) are not applied to the parts obtained that way, and no exception is raised, so the upload is processed as though those limits had been satisfied. A remote uploader can therefore submit files that are larger, or more numerous, than the application permits, up to whatever the component that parsed the request allows. A part carrying no Content-Type header is additionally read into memory in full during parsing, so the size of that allocation is determined by the request and bounded only by those same external limits.\n\nThe total upload size limit (Form#setMaxSize) is not affected. Commons FileUpload compares the declared Content-Length against it before reading the body, so a request declaring an oversized length is rejected before the fallback is reached.\n\nThe fallback is reached in deployments where a servlet or filter has already parsed the request body — for example a servlet annotated with @MultipartConfig, Spring Boot's multipart resolver, or any filter that calls HttpServletRequest#getParameter() on a multipart request. It applies to the Wicket components that accept uploads on that path, including Form with FileUploadField, FileUploadToResourceField and AjaxFileDropBehavior. Applications that configure neither a per-file nor a file-count limit are not affected, as Wicket applies neither by default.\n\nThis issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0.\n\nUsers are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. As a workaround, configure equivalent limits in the component that parses the request — for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml <multipart-config> element.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
} ],
"affected" : [ ],
"references" : [ {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-71257"
}, {
"type" : "WEB",
"url" : "https://lists.apache.org/thread/o59f8jz1m09kqdwm73pyyn6hdsxt190q"
}, {
"type" : "WEB",
"url" : "http://www.openwall.com/lists/oss-security/2026/08/30/4"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-770" ],
"severity" : "HIGH",
"github_reviewed" : false,
"github_reviewed_at" : null,
"nvd_published_at" : "2026-08-31T12:17:56Z"
}
}