CVE-2026-82557

Received Received - Intake

Missing Authorization Bypass in Apache Wicket

Publication date: 2026-11-01

Last updated on: 2026-11-01

Assigner: Apache Software Foundation

Description

Missing authorization in Apache Wicket. org.apache.wicket.markup.html.form.Form resolves the component that submitted a form from the request parameters in Form#onRequest() and passes the result directly to Form#onFormSubmitted(IFormSubmitter). The check that the submitting component is visible and enabled in its hierarchy runs only when onFormSubmitted() is given no submitter, so it no longer runs for an ordinary form submission, and it is the only point at which Wicket verifies that the application actually offered the named control to the caller. Form#findSubmitter() matches on the request parameter name alone and applies no visibility or enablement filter, and the request handler checks only the form itself, which is visible and enabled. A request that names a submit button the application withheld therefore reaches that button's onSubmit() and onAfterSubmit(), and its onError() when form validation fails; where the button sets setDefaultFormProcessing(false) it reaches onSubmit() and onAfterSubmit() without any form validation. An application is affected where a form submitting component, such as a Button or a SubmitLink, is unavailable to the caller while the enclosing form remains available. How the component was made unavailable does not matter: the component's own setVisible(false), setEnabled(false) or setVisibilityAllowed(false), an overridden isVisible() or isEnabled(), an invisible or disabled parent container anywhere above it, and a RENDER or ENABLE denial from IAuthorizationStrategy — for example through MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation — are all enforced by that one check, and all of them are bypassed. A component that renders as disabled carries its own input name in the markup the caller already holds. Submissions made through AjaxFormSubmitBehavior, and therefore through AjaxButton and AjaxSubmitLink, are not affected: those are invoked as a behaviour on the button itself, the behaviour's invocation is authorized against that button, and the non-Ajax callbacks of those two classes do nothing. Restrictions applied to the form or to the page rather than to the submitting component are unaffected. The 9.x and 8.x release lines, and the unsupported lines before them, are not affected; the behaviour was introduced in 10.3.0. This issue affects Apache Wicket: from 10.3.0 through 10.11.0. Users are recommended to upgrade to version 10.12.0, which fixes the issue.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-11-01

Last Modified

2026-11-01

Generated

2026-11-02

AI Q&A

2026-11-02

EPSS Evaluated

N/A

NVD

CVE-2026-82557

Affected Vendors & Products

Vendor	Product	Version / Range
Apache Software Foundation	Apache Wicket	10.3.0

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-862	The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

Attack-Flow Graph

Executive Summary

This vulnerability in Apache Wicket (CVE-2026-82557) involves missing authorization checks. When a form is submitted, the system fails to verify if the submitting component (like a button) was visible or enabled to the user. This allows attackers to submit forms using components that should be inaccessible, potentially triggering unintended actions such as form validation bypass or executing submit handlers without proper validation.

Detection Guidance

Detecting this vulnerability requires checking if your Apache Wicket version is between 10.3.0 and 10.11.0. Use commands like 'mvn dependency:tree' for Maven projects or inspect your application's dependency files to verify the Wicket version.

Impact Analysis

If you use Apache Wicket versions 10.3.0 through 10.11.0, an attacker could exploit this to submit forms using hidden or disabled buttons, leading to unauthorized actions. For example, they might bypass form validation or trigger actions that should only be available to authorized users, potentially causing data corruption or unintended system behavior.

Compliance Impact

This vulnerability allows unauthorized form submissions by bypassing visibility and authorization checks for submit buttons or links. For GDPR, this could lead to unauthorized data processing or access if forms handle personal data. For HIPAA, it may permit unauthorized changes to protected health information if forms are involved in such transactions. The lack of proper authorization checks undermines compliance with data protection and security requirements in these standards.

Mitigation Strategies

Upgrade Apache Wicket to version 10.12.0 or later immediately. Remove or disable any form submitting components that are not intended to be accessible to users, as they may bypass authorization checks.

Hi! I’m here to help you understand CVE-2026-82557. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70

EPSS Chart

Security Radar

News mentioning this vulnerability

Loading related security news...