CVE-2026-82956
| Severity | 7.6 High CVSS 4.0 |
|---|---|
| Weakness | Cross-site scripting (CWE-79) |
| Published | 1 Nov 2026 |
| Updated | 6 Nov 2026 |
Published 13 days ago. NVD often adds the list of affected products days or weeks after a CVE is published, and the other sources we check lag too. The scope and status here may change.
Description
Improper neutralization of input during web page generation in Apache Wicket. org.apache.wicket.ajax.AjaxNewWindowNotifyingBehavior notices that a page instance has been opened in a second browser window or tab. It asks the browser for the value of window.name, which reaches the server as the request parameter windowName, and remembers what the browser reported in a field of the behaviour. That field is part of the page's serialized state, so the remembered value stays in the page store for as long as the page instance does. On every later render of that page instance the behaviour builds the precondition of its Ajax call by substituting the remembered value into a single-quoted JavaScript string literal, and Wicket writes that precondition into the page as raw JavaScript, because the precondition of an Ajax call listener is script supplied by the caller and is emitted without quoting or escaping. Nothing on that path escapes the value. The window name is client-supplied and Wicket applies no validation to it, so a remembered name containing a single quote ends the literal and the rest of it runs as script in the application's origin, every time that page instance is rendered. An application is affected only where it has explicitly added AjaxNewWindowNotifyingBehavior to a component. No part of the framework installs the behaviour, so an application that does not use it is not affected. The name the behaviour generates for itself, when the browser reports no name at all, is a random UUID and is not client-supplied. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
Exploitation status
No public exploit
No exploit has been reported in the sources we check.
Exploitation status
- CISA KEV not listed
- VulnCheck KEV not listed
- CISA Vulnrichment exploitation: none
- Indexed PoC none indexed
- EPSS 0.30% chance in 30 days
Waratek protection
Within Waratek scope. In the sources we check, nobody has published exploit code for this CVE or reported it being exploited.
VRT has not found a public code change for this CVE yet.
- Protection none
- Action not pursued
- Review automated Upstream data
- Record active
| Decided by | Nothing to build a rule from yet: no published exploit, no CISA record of exploitation and no source-level change to read |
|---|---|
| Finding | This CVE affects a known product, but nothing published names a fix and nothing published shows an exploit. That is a statement about the evidence, not about the defect — it does not mean the vulnerability is unimportant or unreachable, only that neither of the two things VRT can act on exists. |
References
| URL | Tags |
|---|---|
| https://lists.apache.org/thread.html/fs3vdddt9bwshdstj952psj49s5w4vqm |
Timeline
Timeline
| Published | 2026-11-01 | By the CVE Program. |
|---|---|---|
| NVD record modified | 2026-11-06 | NVD's own last-modified date for this record. |