The Apache Wicket project has disclosed 19 vulnerabilities affecting its 8.x, 9.x and 10.x release lines, including cross-site scripting, missing authorization checks and denial-of-service bugs in file uploads. Nine of the flaws are rated high severity, and fixes are available in Wicket 8.20.0, 9.25.0 and 10.12.0.
Breakdown of the 19 Wicket Vulnerabilities by Type
The disclosure on November 1 covers six cross-site scripting flaws, five missing authorization checks and two upload denial-of-service bugs. The remainder includes session fixation, file exposure and a missing Content-Security-Policy header. Versions before 8.20.0, 9.25.0 and 10.12.0 are affected, depending on release line.
No exploitation or public proof-of-concept has been confirmed for any of the flaws.
Upload Field Flaws That Let One Request Consume Nearly 2 GB of Heap
The two worst bugs score 8.3 on CVSS v4. They let request parameters set the size limits on a form-less upload field. A single small request can then consume nearly 2 GB of heap memory, and uploaded parts can fill the server’s disk. Because the limits come from the request rather than from server configuration, a visitor to a page with such a field can influence resource use.
Wicket XSS Flaws CVE-2026-111089 and CVE-2026-83559
The cross-site scripting bugs score between 7.4 and 7.6. CVE-2026-111089 involves localized labels. CVE-2026-83559 stems from the escapeQuotes() function, which does not escape backslashes.
CVE-2026-82557 and the Hidden Submit Button
CVE-2026-82557 lets a request trigger a submit button that is hidden from the user. In an application where hiding a control is treated as a form of access control, an attacker could invoke an action the interface never offers to them. The five missing authorization checks in the same release point to related gaps in how components decide who may act.
Why a Framework Bug Reaches Every Dependent Java Application
Wicket is a framework, so the flaws live in a library that enterprise Java applications bundle and ship. Each application built on a vulnerable release inherits the issues until its maintainers upgrade the dependency and redeploy. The spread across three release lines matters because organizations often stay on older versions for compatibility, and each line needed its own fix.
The remediation step is the same for all of them: move to 8.20.0, 9.25.0 or 10.12.0, according to the line in use. With no confirmed exploitation, teams have time to test the upgrades, but nine high-severity findings out of 19 make the disclosure relevant to anyone who scans dependency lists for known vulnerable versions.
Wicket applications render pages from reusable components, so a flaw in label localization or quote escaping appears wherever those helpers are used. The missing Content-Security-Policy header is a different kind of finding: it is not an exploitable bug on its own, but its absence removes a browser-side limit on what an injected script can do. Session fixation is a weakness that can let an attacker who plants a known session identifier take over the session at login.
Wicket Upload Denial-of-Service Bugs and Authorization Gaps Explained
The two upload denial-of-service bugs differ from the other findings because they target availability rather than data. One small request can cost nearly 2 GB of heap, and uploaded parts can fill the disk, so an attacker could take down a Wicket application with little effort. Nothing in the disclosure suggests the flaws have been chained.
The five missing authorization checks and the hidden submit button flaw, CVE-2026-82557, concern what a request is allowed to trigger. In a component-based framework, the server decides which components may respond to a request, so a gap at that decision point lets an attacker reach behavior the page never presents. The 19-flaw total, with nine rated high, gives security teams a defined list to match against the Wicket versions in their dependency trees.
The release numbers differ by line, which matters for planning. A team on 8.x moves to 8.20.0, a team on 9.x to 9.25.0 and a team on 10.x to 10.12.0, each staying inside its current major version.
