CVE-2026-83594

Description

Memory allocation with an excessive size value in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction. UploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application. An application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.

Overview

State: PUBLISHED
Assigner (CNA): apache
CVSS severity: HIGH
CVSS score: 8.3 / 10
CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
Effective score: 8.3 / 10 HIGH source: CNA overview
CWE(s): CWE-789
Reserved: 2026-08-31
Published: 2026-11-01 22:21 UTC
Last updated: 2026-11-01 22:21 UTC
Source: https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/83xxx/CVE-2026-83594.json
Linked Threat: CVE-2026-83594 — Apache Wicket: FileUploadToResourceField accepts a client-asserted upload result and allocates the size it names

NVD triage scoring NVD CVE 2.0

Layer NVD adds on top of the CNA's CVE record — published / last-modified timestamps, exploitability / impact subscores, and the FIRST.org EPSS probability that this CVE will be exploited in the wild in the next 30 days.

NVD published: 2026-11-01 23:17:29 UTC
NVD last modified: 2026-11-01 23:17:29 UTC

European Union Vulnerability Database ENISA EUVD

ENISA's official EU repository for curated vulnerability intelligence. Carries a separate identifier (EUVD-YYYY-NNNN) and frequently exposes an earlier-published description + CVSS than NVD does.

EUVD ID: EUVD-2026-114897
Assigner: apache
Published: Nov 1, 2026, 10:21:13 PM
Updated: Nov 1, 2026, 10:21:13 PM
EUVD base score (CVSS 4.0): 8.3 / 10
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
EUVD-reported EPSS: 0.0000
Vendors: Apache Software Foundation
Products: Apache Wicket (9.14.0 ≤9.24.0)

Apache Wicket (10.0.0 ≤10.11.0)
Aliases: GHSA-7x2v-qvvr-3xhg

ENISA description: Memory allocation with an excessive size value in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction. UploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application. An application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.

EUVD references (1)

https://lists.apache.org/thread.html/h5lxspxg746pzjd437n3n7mq5t3sfbcb

Affected products (1)

Vendor	Product	Versions	Platforms
Apache Software Foundation	Apache Wicket	`9.14.0` (affected), `10.0.0` (affected)	—

Vendor references (1)

References embedded in the original CVE record by the assigning CNA.

https://lists.apache.org/thread.html/h5lxspxg746pzjd437n3n7mq5t3sfbcb vendor-advisory

MITRE references (1) cveawg.mitre.org

Pulled from MITRE's CVE Services API by the 🛰 Backfill from MITRE button.

https://lists.apache.org/thread.html/h5lxspxg746pzjd437n3n7mq5t3sfbcb vendor-advisory

Web references (0)

DuckDuckGo results ranked by threat-intel / vendor advisory domains. Generated by the 🔎 Find references (web) button above — same flow as the Remediations search.

No web references attached yet.

NVD-tagged references (1)

Reference list NVD curates from the CNA record, vendor advisories, and third-party reports. The tag chips below are NVD's analyst-assigned categories.

https://lists.apache.org/thread.html/h5lxspxg746pzjd437n3n7mq5t3sfbcb security@apache.org

Remediations (10)

Remediations are stored against the linked Threat row; the list below is deduplicated across both pages.

July 2026 Critical Patch Update Released | security - Oracle Blogs

web:blogs.oracle.com

For more information about the Critical Patch Update program, see the security vulnerability remediation practices page located on the Oracle Trust Center.

2026-11-02 11:27 UTC
September 2026 Critical Security Patch Update Released

web:blogs.oracle.com

For more information about the Critical Security Patch Update program, see the security vulnerability remediation practices page located on the Oracle Trust Center.

2026-11-02 11:27 UTC
CVE-2026-83594: Apache Wicket Vulnerability - CVETodo

web:cvetodo.com

CVE-2026-83594 is a CVSS 8.3 high-severity vulnerability in Apache Wicket. Includes technical details, affected versions, and mitigation steps.

2026-11-02 11:27 UTC
CVE-2026-83594: Apache Wicket · Excessive Memory Allocation

web:radar.offseq.com

CVE-2026-83594 is a high-severity vulnerability in Apache Wicket affecting versions 9.14.0 through 9.24.0 and 10.0.0 through 10.11.. It involves memory allocation with an excessive size value in the FileUploadToResourceField component, which can be exploited by sending crafted requests that cause the server to allocate large byte arrays ...

2026-11-02 11:27 UTC
Cisco Meraki Security Hardening Release: October 2026

web:sec.cloudapps.cisco.com

As part of Cisco's ongoing commitment to proactive security and product quality, engineering teams conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. These vulnerabilities were found during internal testing and are not known to be actively exploited. To assist customers in patching ...

2026-11-02 11:27 UTC
[Security Advisory] October 2026 CVE Advisory Notification

web:support.servicenow.com

On October 29, 2026 , ServiceNow issued CVE - 2026 -103093, CVE - 2026 -103094, and CVE - 2026 -6877. Each of these security issues was identified through internal security testing, customer security assessments, or reports submitted through ServiceNow's responsible disclosure and bug bounty programs and was remediated independently. For security issues identified through responsible disclosure ...

2026-11-02 11:27 UTC
CVE-2026-58594: Patch Windows RDP Client RCE in July 2026

web:windowsforum.com

Microsoft's July 14, 2026 security updates fix CVE - 2026 -58594, a Remote Desktop Client remote code execution vulnerability that can let an unauthenticated attacker run code on a Windows machine after persuading a user to initiate a malicious RDP connection.

2026-11-02 11:27 UTC
Critical Patch Updates, Critical Security Patch Updates ... - Oracle

web:www.oracle.com

Critical Security Patch Updates Critical Security Patch Updates provide security patches for supported Oracle on-premises products. A Critical Security Patch Update provides targeted, high-priority security fixes in a smaller, more focused format, making them easier to apply with minimal disruption.

2026-11-02 11:27 UTC
Oracle Critical Security Patch Update Advisory - September 2026

web:www.oracle.com

Prior Critical Patch Update and Critical Security Patch Update advisories should be reviewed for information regarding earlier published security patches. Refer to Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins for information about Oracle Security advisories.

2026-11-02 11:27 UTC
Track Critical Vulnerabilities with Qualys Security Advisories

web:www.qualys.com

Get timely updates on security threats, vulnerabilities, and recommended solutions through Qualys security advisories, helping you secure your infrastructure.

2026-11-02 11:27 UTC

AI Forensic Analysis

Only Available for Registered Users. Sign in to view.

Raw JSON

The full cvelistV5 record. Download as CVE-2026-83594.json.

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.wicket:wicket-core",
          "packageURL": "pkg:maven/org.apache.wicket/wicket-core",
          "product": "Apache Wicket",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "9.24.0",
              "status": "affected",
              "version": "9.14.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "10.11.0",
              "status": "affected",
              "version": "10.0.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Emond Papegaaij"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Memory allocation with an excessive size value in Apache Wicket.<br><br>org.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction.<br><br>UploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application.<br><br>An application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected.<br><br>This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.<br>"
            }
          ],
          "value": "Memory allocation with an excessive size value in Apache Wicket.\n\norg.apache.wicket.markup.html.form.upload.resource.FileUploadToResourceField uploads files to a separately mounted resource rather than through a form, and is told the outcome afterwards over its own Ajax callback. That callback reads the request parameter filesInfo, a JSON array carrying a client file name, a size and a content type for each file, and turns it into the list of FileUploadToResourceField.UploadInfo that onUploadSuccess() receives. Nothing binds that JSON to an upload the resource performed and nothing re-derives it from the stored files, so the number of entries and every value in them are whatever the request supplied. The callback URL is rendered into the page, no prior upload is required, and both GET and POST reach it, so any client that can load the page can have the component report files that were never uploaded, without authenticating beyond whatever the page itself requires and without any user interaction.\n\nUploadInfo#get(), which the class offers as the way to obtain the bytes of an upload, allocates a byte array from UploadInfo#getSize() before it opens the file. The array is therefore sized by the number the request supplied, and the allocation happens even for a file that was never stored. One small request can cost the server close to two gigabytes of heap, and the request is trivially repeatable, so a few of them exhaust the heap for every request the Java virtual machine is serving. A size that the conversion to int turns negative instead throws NegativeArraySizeException, which the exception handler inside that method does not cover, so it escapes into the application.\n\nAn application is affected where it uses FileUploadToResourceField, which is not the ordinary upload path through FileUploadField and Form and has to be extended and mounted deliberately. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself. Where the application denies the ENABLE action on the field through its authorization strategy, the callback is refused like any other listener. The 8.x line does not contain this component and is not affected.\n\nThis issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 8.3,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789 Memory Allocation with Excessive Size Value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-01T22:21:13.833Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/h5lxspxg746pzjd437n3n7mq5t3sfbcb"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Wicket: FileUploadToResourceField accepts a client-asserted upload result and allocates the size it names",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-83594",
    "datePublished": "2026-11-01T22:21:13.833Z",
    "dateReserved": "2026-08-31T20:07:48.970Z",
    "dateUpdated": "2026-11-01T22:21:13.833Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}