HOL LogoGuard

Explore HOL

  • HOL home
  • AI agent registry
  • AI plugins
  • Open standards
  • HOL members
  • Sponsor HOL
  • Advertise with HOL

Guard product

  • Guard overviewLocal security and control for AI agents and the tools they use.
  • FeaturesRuntime protection, policy routing, review, and evidence.

Explore Guard

  • Product previewWalk through Guard surfaces in read-only demo mode.
  • ComparisonCompare Guard with native controls and AI security vendors.

AI tools

  • All AI toolsEvery supported AI tool and how Guard applies policy to it.
  • Codex
  • Claude Code
  • Cursor
  • Antigravity CLI
  • OpenCode
  • Hermes
  • OpenClaw
  • GitHub Copilot CLI
  • Antigravity
  • Kimi
  • Grok
  • Pi / Oh My Pi
  • Zcode

Extensions

  • All extensionsBrowse command and MCP coverage with owners and stated limits.
  • Command coverageShell command protection across clouds, databases, backups, and packages.
  • MCP server coverageSee how Guard maps risk state across MCP tools and servers.
  • Core safetyThe safety floor listings that ship with Guard.
  • Data and resilienceBackup and storage command protection.
  • Cloud and infrastructureAWS, Azure, GCP, Kubernetes, and more.

Security

  • AI security hubSecurity research, advisories, and agent safety coverage.
  • AI tool securitySecurity profiles for each supported coding agent.
  • Safe labsHands-on attack simulations with safe boundaries.
  • Redacted warningsReal blocked actions with sensitive details removed.
  • AdvisoriesCoordinated disclosure reports for AI tooling.
  • Active CVEsSearch active CVEs affecting AI tooling.

Learn

  • Security guidesPractical guides for securing AI agent workflows.
  • DocsInstall, configure, and operate Guard with confidence.
  • ResearchPublished security research, benchmarks, and methodology.

Community

  • ReleasesVersion history, shipped changes and upgrade notes.
  • ContributorsThe people and contributions behind HOL Guard.
  • AffiliatesShare Guard with your audience and earn from referrals.
  • SponsorFund agreed research, implementation and shared testing through the HOL Partner Program.
  • AdvertiseCompare README logo placements, previews and monthly prices, or promote a plugin or extension.
PricingEnterpriseOpen AppInstall Guard
  1. Guard
  2. Security
  3. CVEs
  4. CVE 2026 83594 apache wicket fileuploadtoresourcefield accepts a
HOL Guard

Public security guidance for teams protecting AI harnesses, MCP servers, skills, prompts, and local tool execution.

Install Guard

AI Security

  • Prompt injection
  • MCP security
  • OWASP MCP mapping
  • Supply chain

Resources

  • Trust packet
  • Harness setup
  • Redacted warnings
  • Safe labs

Product

  • Install Guard
  • Pricing
  • Open dashboard
Guard
  • Guard Overview
  • Releases
  • Contributors
  • Install Guard
  • Pricing
Docs
  • Documentation Index
  • Developer Hub
  • API Reference
  • Root OpenAPI
  • Registry OpenAPI
  • Run in Postman
  • Standards
  • Submit ERC-8004 Contract
  • Feature Your Agent
Best Plugins
  • Browse Plugins
  • Plugin Launches
  • Best Claude Plugins
  • Best Codex Plugins
  • Best Grok Plugins
  • Best Kimi Plugins
  • Best DeepSeek Plugins
  • Best Antigravity Plugins
  • Best MCP Servers
  • Best Cursor Plugins
  • Best OpenCode Plugins
Best Agents
  • Best ERC-8004 Agents
  • Best Virtuals Agents
  • Best MCP Servers
  • Best A2A Agents
  • Best x402 Payable
  • All Categories
Community
  • Telegram
  • X
More
  • About HOL
  • Sponsor
  • Advertise
  • Affiliate program
  • Contact
  • Blog
  • GitHub
  • Privacy
  • Terms of Service
Settings

Copyright © 2026 HOL DAO LLC. All rights reserved.

Back to active CVEs
High · CVSS 8.3CVE-2026-83594

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

Answer in brief

CVE-2026-83594 records a High severity (CVSS 8.3) vulnerability in Apache Wicket: FileUploadToResourceField accepts a client-asserted upload result and allocates the size it names. The current sources do not mark it as known exploited. The current feed maps Apache Software Foundation/org.apache.wicket:wicket-core (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Nov 1, 2026Updated Nov 1, 2026Source checked Nov 2, 2026First seen by HOL Nov 1, 2026Material review Nov 1, 2026
Upstream Advisory

Key facts

Risk
High · CVSS 8.3
Exploitation
Not marked as known exploited
Affected software
1 mapped package or product
Fix availability
Not reported

Why this deserves its current priority

CVSS is 8.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Apache Software Foundation/org.apache.wicket:wicket-core (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
PackageAffected rangeFixed version
Apache Software Foundation/org.apache.wicket:wicket-coregeneric>=9.14.0 <=9.24.0 || >=10.0.0 <=10.11.0Not reported

Recommended response

  1. 1Check inventory. Check lockfiles and deployed manifests for Apache Software Foundation/org.apache.wicket:wicket-core.
  2. 2Review the reported fix. Monitor this advisory for an available fix and review any installs of the affected package.

Evidence timeline and material changes

  1. Published upstream

    Nov 1, 2026

    Evidence: source:cvelist:source_dates:source-dates:record
  2. Source modified

    Nov 1, 2026

    Evidence: source:cvelist:source_dates:source-dates:record
  3. First seen by HOL

    Nov 1, 2026

Sources and claim methodology

  • Source referencelists.apache.org
Upstream source 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.

Quoted source text, attributed separately from HOL analysis.

Related CVEs

  • Apache Wicket: XSS via a resource bundle text written unescaped into generated JavaScript and markupSame apache software foundation/org.apache.wicket package
  • Apache Wicket: A disabled or invisible form submitting component is still invoked on a plain form submissionSame apache software foundation/org.apache.wicket package
  • Apache Wicket: A listener is invoked on a page instance the request itself created and never configuredSame apache software foundation/org.apache.wicket package
  • Apache Wicket: The configured authorization strategy is not applied to an IResource embedded in a componentSame apache software foundation/org.apache.wicket package
  • Apache Wicket: A cross-origin listener invocation stopped by a login wall is replayed after the user signs inSame apache software foundation/org.apache.wicket package
  • Apache Wicket: XSS in AjaxNewWindowNotifyingBehavior via the client-supplied window nameSame apache software foundation/org.apache.wicket package

Record context

Vulnerability class
Vulnerability
EPSS
Not reported
CWE IDs
CWE-789
Source
CVE List V5
Source checked
Nov 2, 2026
References
1 linked source
Open source record