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-84170

Apache Wicket: Configured upload limits are not enforced by the standalone file upload resource

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 14/11/2026, 23:55: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 versions 9.14.0 through 9.24.0 and 10.0.0 through 10.9.1 have a weakness where configured upload limits are not enforced by the standalone file upload resource, allowing unauthenticated requests to consume excessive disk or heap space. The issue affects applications using FileUploadToResourceField or mounted FileUploadResourceReference. No authorization is required for exploitation.

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

Attack conditions

No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.

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.9.1

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

Allocation of resources without limits or throttling in Apache Wicket.

org.apache.wicket.markup.html.form.upload.resource.AbstractFileUploadResource is the server side of the form-less upload offered by FileUploadToResourceField, which posts the selected files to a separately mounted resource rather than through a Form. The resource is an application-wide singleton with no component to consult, so newResourceResponse() takes the three limits that bound the upload - the total request size, the maximum size of a single part and the maximum number of parts - from the request parameters maxSize, fileMaxSize and fileCountMax, and hands them to the multipart parser as they arrive. Nothing binds those numbers to the field that is supposed to be uploading. A request naming a very large maxSize is therefore parsed with no effective ceiling on the total size, and omitting fileMaxSize and fileCountMax leaves the per-part and part-count limits unset as well. The values the application configured through FileUploadToResourceField#setMaxSize(), #setFileMaxSize() and #setFileCountMax() are consulted only when the client omits the corresponding parameter, so against a client that supplies one they have no effect at all.

Parts above the parser's in-memory threshold are spooled to the container's temporary directory, and the file parts are then copied into the folder the application's IUploadsFileManager owns, under a sub-folder the request names, where they remain. A part that is not a file is read into the heap in full while the request is parsed. One request, repeatable, can therefore consume as much disk or as much heap as the client chooses to send. The resource carries no authorization annotation and the default authorization strategy permits every resource request, so unless the application authorizes the resource itself the request needs no authentication, no session, no prior page view and no user interaction.

An application is affected where it uses FileUploadToResourceField, or mounts FileUploadResourceReference itself. This is not the ordinary upload path: the resource is a singleton that has to be created and mounted deliberately. An application that configures no upload limit at all loses nothing, because Wicket applies no total-size limit of its own by default; what the defect removes is a limit the application set. Uploads through Form with FileUploadField, and through AjaxFileDropBehavior, are not affected, because both read their limits from the component rather than from the request. The upload resource does not exist in the 8.x line.

This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.9.1. 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-84170

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-770 ↗

CWE-770 Allocation of Resources Without Limits or Throttling

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-84170

    Observed 2026-11-06T15:01:58.613Z · upstream updated 2026-11-06T14:44:59.262Z

    Prioritization updated

    before

    []

    after

    [
      {
        "source": "CISA-ADP",
        "type": "SSVC",
        "role": "CISA Coordinator",
        "timestamp": "2026-11-06T14:44:37.230714Z",
        "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.