Apache Wicket Fixes High-Severity XSS Vulnerability Affecting Versions 8, 9 and 10

Apache has disclosed a high-severity cross-site scripting (XSS) vulnerability in Apache Wicket that could allow attacker-controlled JavaScript to execute in an application's origin when a vulnerable page loads.

Tracked as CVE-2026-95863, the vulnerability affects Apache Wicket versions 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, and 10.0.0 through 10.11.0.

The issue occurs because Wicket writes certain component identifiers and form input names into generated JavaScript and markup without properly neutralising characters that have special meaning in those contexts.

An application can become vulnerable when a component ID or markup ID contains characters such as a single quote or backslash. These characters can break out of a JavaScript string literal, allowing subsequent content to be interpreted as executable script.

Apache recommends upgrading to Wicket 8.20.0, 9.25.0 or 10.12.0, which contain fixes for the issue.

What Is CVE-2026-95863?

CVE-2026-95863 is an improper input neutralisation vulnerability in Apache Wicket's web page generation process.

Wicket generates JavaScript that refers to elements rendered on a page. During this process, it inserts two values into JavaScript string literals:

• A component's markup ID.

• The input name of a form component, derived from the IDs of components between the form and the form component.

The problem is that these values are placed inside single-quoted JavaScript strings without being escaped for that specific context.

If an identifier contains a single quote or a backslash, it can break the JavaScript string literal. The content that follows may then be interpreted as script and execute in the application's origin when the page loads.

The vulnerability does not mean that every Apache Wicket application is automatically exploitable. An application is affected when a component ID or markup ID contains one of the characters that can trigger the unsafe output.

How the XSS Vulnerability Occurs

Apache Wicket uses component IDs and markup IDs to connect server-side components with elements rendered in a web page.

The vulnerability arises when values that are valid in one context are reused in another without the necessary protection.

For example, an application can supply a markup ID through org.apache.wicket.Component#setMarkupId(String), define an ID in component markup, or use an ID generated by Wicket.

The first two sources are controlled by the application. Wicket correctly escapes these values when writing them into an HTML id attribute. However, the same protection is not applied when the values are inserted into generated JavaScript string literals.

Component IDs are also used to derive form input names. The advisory explains that component IDs were previously rejected only for : and ~, leaving other characters that could interfere with generated JavaScript.

Consequently, an identifier that is valid in the application's HTML context could still become unsafe when Wicket uses it inside JavaScript.

Why JavaScript Context Matters

HTML attribute escaping and JavaScript string escaping serve different purposes.

A character that is permitted in an HTML attribute is not necessarily safe inside a JavaScript string. When an application-provided identifier is reused in generated script, it must be validated or handled according to the JavaScript context.

In this vulnerability, the unescaped values could terminate a single-quoted string literal. The remaining content could then be interpreted as JavaScript and execute when the generated page loads.

Affected Apache Wicket Components and Modules

The advisory identifies multiple locations in Wicket Core and Wicket Extensions where identifiers or input names are written into generated JavaScript or markup without the required escaping.

Affected Wicket Core Components

In Apache Wicket 9.x and 10.x, org.apache.wicket.markup.head.OnEventHeaderItem#forMarkupId(String, String, CharSequence) places the supplied ID into a Wicket.Event.add call.

Components in both Wicket Core and Wicket Extensions can reach this method through #forComponent(Component, String, CharSequence).

The advisory also identifies the following affected components across the vulnerable versions:

Additional version-specific issues affect form submission:

• In Wicket 8.x, Form also writes an input name into the action of a submitting link.

• In Wicket 8.x and 9.x, Form#appendDefaultButtonField writes an input name into a name attribute without escaping it. A value containing a double quote can therefore escape the attribute and affect the generated markup.

Affected Wicket Extensions Components

The advisory confirms that wicket-extensions is affected in its own right, not only through its dependency on wicket-core.

The identified components are:

• AjaxEditableLabel

• AjaxIndicatorAppender

• AjaxDisableComponentListener

• UploadProgressBar

• KittenCaptchaPanel

• Palette

• FilterForm

• TrapFocusBehavior in Wicket 9.x and 10.x

• AjaxListPanel in Wicket 9.x and 10.x

These components build JavaScript containing markup IDs, creating additional locations where unsafe identifiers can enter generated script.

Content Security Policy Does Not Prevent the Vulnerability

A Content Security Policy (CSP) is commonly used to restrict which scripts a browser can execute.

However, Apache Wicket's advisory specifically warns that the default CSP sent by Wicket 9.x and 10.x does not prevent this vulnerability.

The generated script is written inside a script element that carries the per-response nonce. Because the injected content becomes part of a script element already authorised by the policy, the CSP does not block its execution.

This is an important distinction for organisations that rely on the default Wicket CSP configuration. Having a nonce-based policy does not remove the need to fix the unsafe identifier handling.

Which Apache Wicket Versions Are Affected?

Apache has confirmed that the following release ranges are vulnerable:

Users running Apache Wicket 7.x or older are also advised to upgrade because those versions are no longer supported.

Apache's Fix Restricts Unsafe Identifiers

The fixed releases address the issue by validating identifiers when they enter the framework, rather than attempting to escape them separately at every location where they are written.

Under the updated restrictions, component IDs and markup IDs may no longer contain:

• Quotes

• Backquotes

• Backslashes

• Braces

• Angle brackets

• Semicolons

• Ampersands

• Control characters

Markup IDs have additional restrictions and may not contain parentheses or square brackets.

If a component is constructed with a prohibited component ID or is assigned a prohibited markup ID, the fixed versions throw an exception.

This approach prevents unsafe values from entering the framework through these identifiers in the first place.

What Organisations Should Do

Organisations using Apache Wicket should identify whether their applications run an affected version and upgrade to the corresponding fixed release.

Recommended actions based on the Apache advisory include:

1. Identify affected dependencies: Check whether applications use Wicket 8.x, 9.x or 10.x within the affected version ranges.

2. Upgrade to a fixed release: Move to Wicket 8.20.0, 9.25.0 or 10.12.0, as appropriate.

3. Review application-defined identifiers: Examine component IDs, markup IDs and IDs derived from application data for characters that are no longer permitted.

4. Check Wicket Extensions usage: Review applications that use the affected components in wicket-extensions, not just Wicket Core.

5. Review older deployments: Organisations running Wicket 7.x or older should move to a supported version.

The fixed releases enforce identifier restrictions at the point where component IDs and markup IDs enter the framework. Applications that rely on previously permitted characters may therefore need adjustments before or during the upgrade.

Apache's advisory does not provide a separate workaround for organisations that cannot upgrade. Additional details were not disclosed in the announcement.

Conclusion

CVE-2026-95863 exposes a cross-site scripting weakness in Apache Wicket's generated JavaScript and markup. The issue occurs when the application inserts component IDs, markup IDs, or derived form input names into JavaScript string literals without appropriate context-specific protection.

The vulnerability affects Apache Wicket 8.x, 9.x and 10.x within the specified release ranges, including components in both Wicket Core and Wicket Extensions. The framework's default nonce-based CSP in versions 9.x and 10.x does not prevent the injected script from executing.

Apache addressed the issue with stricter identifier validation in Wicket 8.20.0, 9.25.0, and 10.12.0. Organisations using affected releases should upgrade and review application-defined identifiers to avoid compatibility issues.