{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-08-31T12:16:28.466Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/08/30/4"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "HIGH",
              "baseScore": 7.5,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-71257",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-01T18:01:05.319886Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-01T18:01:24.791Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.wicket:wicket-core",
          "product": "Apache Wicket",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "8.18.0",
              "status": "affected",
              "version": "8.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "9.23.0",
              "status": "affected",
              "version": "9.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "10.10.0",
              "status": "affected",
              "version": "10.0.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "GitHub: @deprrous"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "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.\u003cbr\u003e\u003cbr\u003eThe 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.\u003cbr\u003e\u003cbr\u003eThe fallback is reached in deployments where a servlet or filter has already parsed the request body \u2014 for example a servlet annotated with @MultipartConfig, Spring Boot\u0027s 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.\u003cbr\u003e\u003cbr\u003eThis 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.\u003cbr\u003e\u003cbr\u003eUsers 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 \u2014 for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml \u0026lt;multipart-config\u0026gt; element."
            }
          ],
          "value": "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 \u2014 for example a servlet annotated with @MultipartConfig, Spring Boot\u0027s 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 \u2014 for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml \u003cmultipart-config\u003e element."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-31T11:45:49.528Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/o59f8jz1m09kqdwm73pyyn6hdsxt190q"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Wicket: Configured file upload limits are not enforced when the multipart request has already been parsed",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-71257",
    "datePublished": "2026-08-31T11:45:49.528Z",
    "dateReserved": "2026-08-05T11:48:12.846Z",
    "dateUpdated": "2026-09-01T18:01:24.791Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"http://www.openwall.com/lists/oss-security/2026/08/30/4\"}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2026-08-31T12:16:28.466Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 7.5, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"NONE\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-71257\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-09-01T18:01:05.319886Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-09-01T18:01:18.388Z\"}}], \"cna\": {\"title\": \"Apache Wicket: Configured file upload limits are not enforced when the multipart request has already been parsed\", \"source\": {\"discovery\": \"UNKNOWN\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"GitHub: @deprrous\"}], \"metrics\": [{\"other\": {\"type\": \"Textual description of severity\", \"content\": {\"text\": \"moderate\"}}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"vendor\": \"Apache Software Foundation\", \"product\": \"Apache Wicket\", \"versions\": [{\"status\": \"affected\", \"version\": \"8.0.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"8.18.0\"}, {\"status\": \"affected\", \"version\": \"9.0.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"9.23.0\"}, {\"status\": \"affected\", \"version\": \"10.0.0\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"10.10.0\"}], \"packageName\": \"org.apache.wicket:wicket-core\", \"collectionURL\": \"https://repo.maven.apache.org/maven2\", \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://lists.apache.org/thread/o59f8jz1m09kqdwm73pyyn6hdsxt190q\", \"tags\": [\"vendor-advisory\"]}], \"x_generator\": {\"engine\": \"Vulnogram 0.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"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 \\u2014 for example a servlet annotated with @MultipartConfig, Spring Boot\u0027s 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 \\u2014 for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml \u003cmultipart-config\u003e element.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"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.\u003cbr\u003e\u003cbr\u003eThe 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.\u003cbr\u003e\u003cbr\u003eThe fallback is reached in deployments where a servlet or filter has already parsed the request body \\u2014 for example a servlet annotated with @MultipartConfig, Spring Boot\u0027s 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.\u003cbr\u003e\u003cbr\u003eThis 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.\u003cbr\u003e\u003cbr\u003eUsers 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 \\u2014 for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml \u0026lt;multipart-config\u0026gt; element.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-770\", \"description\": \"CWE-770 Allocation of Resources Without Limits or Throttling\"}]}], \"providerMetadata\": {\"orgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"shortName\": \"apache\", \"dateUpdated\": \"2026-08-31T11:45:49.528Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-71257\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-09-01T18:01:24.791Z\", \"dateReserved\": \"2026-08-05T11:48:12.846Z\", \"assignerOrgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"datePublished\": \"2026-08-31T11:45:49.528Z\", \"assignerShortName\": \"apache\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}