Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-83594

Apache Wicket: FileUploadToResourceField accepts a client-asserted upload result and allocates the size it names

Products / packages Apache Software Foundation Apache Wicket

Published

Share

Severity and exploitation

Not in CISA KEV

KEV coverage does not rule out exploitation.

KEV checked 15/11/2026, 00:05:31 UTC
apache · CVSS:4.0 · 8.3
Assessment vectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

Severity

high8.3

CVSS measures technical severity, not the likelihood of an attack.

Known exploitation

Not listed in the checked CISA KEV catalog

Absence from CISA KEV does not rule out attacks.

Public exploit

Not established by this record

Missing evidence does not mean no public exploit exists.

Remediation

Fix status not established

No structured fix or guidance is available here. Check the latest publisher advisory.

What this means

Apache Wicket's FileUploadToResourceField allocates memory based on client-supplied size values, potentially leading to excessive memory allocation. This affects versions 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0. An attacker with access to the page can trigger this issue without authentication or user interaction.

Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.

Attack conditions

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. The allocation additionally requires the application to call UploadInfo#get() rather than reading UploadInfo#getFile() itself.

Excerpt from the original source description below.

Review supporting sources →

Affected versions

Check the exact model, release, and any platform requirements against your installation.

Apache Software Foundation · apache

Apache Wicket

2 ranges

Package identity

pkg:maven/org.apache.wicket/wicket-coreExplore org.apache.wicket:wicket-core →

Identity supplied by apache. Version matching requires compatible range evidence.

Compare with this publisher’s ranges. This does not inspect your installation.

affected

9.14.0 → through 9.24.0

semver versions

10.0.0 → through 10.11.0

semver versions

unaffected

unknown

Other versions: unaffected

Automatic dependency matching is unavailable for this record. Use the product evidence and publisher’s instructions to check your installation.

What to do

Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.

No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.

cve.new guidance unless attributed to a publisher. This page does not inspect your installation.

Public exploit evidence

No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.

Original source description

Read the full publisher 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.

References

1 sources

Inside the record

Evidence available

Package identity
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-83594

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

CWE-789 ↗

CWE-789 Memory Allocation with Excessive Size Value

apache

Related →
Contributing organizations · 2
apache

Assigning organization

2026-11-01
CISA-ADP

Additional data publisher

2026-11-06

Timeline

All times UTC
  1. Advisory published

    Publication date supplied by the source.

  2. Source updated

    Latest modification date supplied by the source.

  3. Last imported by cve.new

    Latest catalog import, not the date we first saw this advisory.

What changed

Follow changes
  1. CVE · CVE-2026-83594

    Observed 2026-11-06T15:17:21.002Z · upstream updated 2026-11-06T14:57:19.281Z

    Prioritization updated

    before

    []

    after

    [
      {
        "source": "CISA-ADP",
        "type": "SSVC",
        "role": "CISA Coordinator",
        "timestamp": "2026-11-06T14:56:53.436718Z",
        "decisions": [
          {
            "name": "Exploitation",
            "value": "none"
          },
          {
            "name": "Automatable",
            "value": "no"
          },
          {
            "name": "Technical Impact",
            "value": "partial"
          }
        ]
      }
    ]

Large field values are marked as truncated previews. Original source snapshots remain retained.

Showing up to 50 most recent observed changes.