EUVD-2026-114887
GHSA-vprr-p32v-2q45
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAccess page with withheld non-Ajax submit control
-
DeliveryRead withheld button's input name from markup
-
ExploitCraft form POST naming that button
-
ExecutionBypass visibility/authorization check in findSubmitter
-
PersistInvoke button onSubmit/onAfterSubmit server-side
-
ImpactPerform withheld privileged action
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable only where a non-Ajax form submitting component (a Button or SubmitLink) is made unavailable to the caller - via its own setVisible(false)/setEnabled(false)/setVisibilityAllowed(false), an overridden isVisible()/isEnabled(), an invisible or disabled parent container, or a RENDER/ENABLE denial from IAuthorizationStrategy (e.g. MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation) - while the enclosing form stays available; the control must have rendered (as disabled, carrying its input name in markup) so the caller holds the name to submit. LIMITING FACTORS: Ajax submissions through AjaxFormSubmitBehavior, AjaxButton and AjaxSubmitLink are NOT affected because the behaviour invocation is authorized against the button; restrictions applied to the form or page rather than to the submitting component are NOT bypassed; and only versions 10.3.0 through 10.11.0 are affected (the behaviour was introduced in 10.3.0 and fixed in 10.12.0). |
| Impact | This is a CWE-862 missing-authorization flaw rated CVSS 4.0 6.9 (Medium). The vendor vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N indicates a network-reachable, low-complexity, no-interaction bypass whose only impact is limited integrity (VI:L) with no confidentiality (VC:N) or availability (VA:N) impact. The PR:N signal reflects that the enclosing form is reachable without the withheld control's authorization, but it overstates exposure because real impact depends entirely on the application: it is only exploitable where an app places visibility/enablement or IAuthorizationStrategy restrictions on the submitting component itself rather than on the form or page. There is no CISA KEV listing, no EPSS score was provided in the input, and the sole reference is an Apache advisory thread - so there is no public exploit identified at time of analysis. The vuln.today decision label is 'this_month', not act_now/emergency, consistent with a medium-severity, not-yet-exploited authorization gap. Net: a credible, patch-this-month issue for applications using component-level gating on non-Ajax submitters, not a high-CVSS-but-illusory concern, but its blast radius is bounded by limited integrity impact and by a narrow affected window (10.3.0-10.11.0 only). |
| Exploit ScenarioDerived | An application renders a sensitive non-Ajax control - for example an admin-only Delete Button or SubmitLink - as hidden or disabled (or RENDER/ENABLE-denied by an authorization strategy) for ordinary users while keeping the enclosing form available to them. Because a component that renders as disabled still carries its input name in the markup the caller holds, a user crafts a form POST naming that withheld button; Form#findSubmitter() matches it on name alone and invokes its onSubmit() and onAfterSubmit() (and onError() on validation failure), performing the withheld action. No public exploit code is identified; the attack follows directly from the described mechanism, and for buttons using setDefaultFormProcessing(false) no form validation runs at all. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 01, 2026
Missing authorization in Apache Wicket 10.3.0 through 10.11.0 allows a remote unauthenticated caller to invoke the server-side callbacks of a form submit control that the application deliberately withheld from them, because Form#findSubmitter() resolves the submitter from the request parameter name alone and the visible/enabled check runs only when no submitter is supplied. Where a Button or SubmitLink is hidden, disabled, or denied by IAuthorizationStrategy while the enclosing form stays available, a request naming that control still reaches its onSubmit() and onAfterSubmit(), and its onError() when validation fails - reaching onSubmit()/onAfterSubmit() with no validation at all when the button sets setDefaultFormProcessing(false). No public exploit code has been identified at time of analysis; Ajax submissions through AjaxFormSubmitBehavior, AjaxButton and AjaxSubmitLink are not affected, restrictions on the form or page are not bypassed, and the 9.x and 8.x lines are unaffected because the behaviour was introduced in 10.3.0.
RemediationAI
Upgrade to Apache Wicket 10.12.0, the vendor-released fix that restores submitter resolution behaviour; no patch is offered for the 10.3.0-10.11.0 range, and the vuln.today decision label for this issue is this_month, so schedule the upgrade within the current cycle. Where an immediate upgrade is not possible, the specific compensating control indicated by the analysis is to convert conditionally available submit controls from Button/SubmitLink to AjaxButton/AjaxSubmitLink, since Ajax submissions are invoked as a behaviour on the button itself and that invocation is authorized against the button - the trade-off is a behavioural change in the client, since these controls now submit via Ajax rather than as ordinary form posts and any JavaScript-free fallback is lost. Because framework-level visibility and IAuthorizationStrategy RENDER/ENABLE denials on the submitting component cannot be relied upon in affected versions, add an explicit authorization check at the start of every onSubmit() and onAfterSubmit() handler (and any onError() handler) so that a callback reached by a crafted parameter names the same decision the UI made; the trade-off is duplicated authorization logic that must be kept in sync with the rendering conditions. Note that setVisible(false), setEnabled(false) and the Ajax exemption are the only mitigations the sources identify - restrictions placed on the form or page remain effective and are not a workaround for component-level restrictions, and hiding or disabling a button is not a substitute for the upgrade while running 10.3.0 through 10.11.0.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Wicket is a Java component-oriented web framework in which server-side components are organised in a hierarchy and each rendered control carries a request parameter name in the markup the client already holds. This is a CWE-862 missing-authorization flaw in the form request-handling path: Form#onRequest() resolves the submitting component from the request parameters and passes it directly to Form#onFormSubmitted(IFormSubmitter). The framework's check that the submitter is visible and enabled within its hierarchy runs only when onFormSubmitted() receives no submitter, so an ordinary submission skips it - and that check was the single point at which Wicket verified the application actually offered the named control to the caller. Form#findSubmitter() matches on the parameter name alone with no visibility or enablement filter, while the request handler validates only the form component itself, which is legitimately visible and enabled. The affected mechanism covers every enforcement route: 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 RENDER or ENABLE denials from IAuthorizationStrategy such as MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation. A control that renders as disabled still emits its own input name in the markup, giving the caller the value needed to craft the request. Ajax submission paths are architecturally exempt: AjaxFormSubmitBehavior, and therefore AjaxButton and AjaxSubmitLink, invoke behaviour on the button itself, that invocation is authorized against that button, and the non-Ajax callbacks of those two classes do nothing. The trigger requires a form submitting component that is unavailable while its enclosing form remains available; the sources do not describe any additional precondition such as a race or memory condition.
Know when Apache Wicket gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
A crafted network request reaches a withheld submit handler without interaction; PR:N since the form may be public (PR:L where the form itself requires auth); impact is limited integrity only, no confidentiality or availability.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Apache Wicket
View allPath traversal vulnerability in Apache Wicket's FolderUploadsFileManager allows unauthenticated attackers to read arbitr
Apache Wicket's form-less upload endpoint (AbstractFileUploadResource, the server side of FileUploadToResourceField, or
Heap-exhaustion denial of service in Apache Wicket 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0, reachable without a
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 allows text
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 lets a value
Stored cross-site scripting in Apache Wicket's AjaxNewWindowNotifyingBehavior allows a client-supplied browser window na
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0 lets remote attackers get script executed in the application'
Apache Wicket's public JavaScriptUtils.escapeQuotes() helper fails to escape backslashes before quotes, so attacker-infl
Cross-site scripting in Apache Wicket's SmartLinkLabel and SmartLinkMultiLineLabel components turns attacker-influenced
Session fixation in Apache Wicket's role-based authentication module leaves the container session id unchanged when an a
Missing authorization in Apache Wicket 8.x, 9.x and 10.x allows unauthenticated remote attackers to invoke a component's
Unauthenticated remote attackers can partially read and modify data in Apache Wicket versions 9.0.0 through 9.23.0 and 1
Exploit-DB