CVE-2026-87718 in Wicket
Summary
by MITRE • 11/02/2026
Apache Wicket 10.10.0, 10.11.0 and 9.24.0 do not set the Content-Security-Policy headers on a page whose render request handler is wrapped in more than one IRequestHandlerDelegate. The framework unwraps only a single delegate level when deciding whether a request renders a page, so with a deeper chain, for example an application-provided delegating request mapper combined with CryptoMapper, the page is served without any CSP header even though CSP is enabled, and no error or warning is raised. The nonce-based protection Wicket applies to inline scripts and styles, together with any other CSP directives configured by the application, is thereby lost for those pages, exposing them to content injection the policy was meant to prevent. Applications on stock Wicket that do not wrap request handlers themselves are not affected. Versions before 10.10.0 and 9.24.0 handled nested delegates correctly. Users are recommended to upgrade to version 10.12.0 or 9.25.0, which fix the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Apache Wicket versions 10.10.0 through 10.11.0 and 9.24.0 represents a significant configuration logic error within the framework's request handling pipeline that directly compromises web security controls. Specifically, the flaw resides in how the application determines whether to append Content-Security-Policy headers to outgoing responses when nested request handler delegates are utilized. In standard operation, Apache Wicket is designed to enforce strict content policies by injecting CSP headers into HTTP responses for pages rendered through its framework. This mechanism relies on a specific check within the render logic that inspects the chain of IRequestHandlerDelegate objects wrapping the final page rendering component. The intended behavior requires iterating through all levels of delegation to accurately identify if the ultimate target is a page requiring security headers, but the implementation in these affected versions contains a critical oversight where it only unwraps and checks a single level of delegate nesting.
This technical flaw manifests when an application employs multiple layers of request handler wrapping, such as combining an application-provided delegating request mapper with external libraries like CryptoMapper or other custom interceptors that implement the IRequestHandlerDelegate interface. In these scenarios, the framework's logic fails to traverse deeper than one level into the delegate chain. Consequently, even if Content-Security-Policy is explicitly enabled in the Wicket configuration and correctly applied for standard requests, the response generated for pages served through this nested delegation structure will lack any CSP headers entirely. The system does not raise errors or warnings during this process, making the failure silent and difficult to detect without specialized security testing tools that inspect HTTP response headers against expected policy configurations.
The operational impact of this vulnerability is severe due to its direct relationship with Content Injection attacks. By omitting the Content-Security-Policy header, the application effectively disables several critical protections provided by CSP standards defined in RFC 9206 and commonly referenced under CWE-798: Use of Hard-coded Credentials or CWE-1021: Improper Restriction of Rendered UI Layers and Frames. Most notably, Wicket utilizes nonces to protect inline scripts and styles from being executed unless they originate from trusted sources. Without the CSP header containing these nonce values, browsers will not enforce restrictions on script execution based on source validation. This exposes users to Cross-Site Scripting (XSS) attacks where an attacker could inject malicious JavaScript payloads into page content or URL parameters that are subsequently rendered and executed by victim browsers. The absence of other potential directives such as X-Frame-Options equivalents or restrictive default-src policies further widens the attack surface for clickjacking, data exfiltration via beaconing scripts, and other code injection vectors.
This issue is particularly dangerous because it affects applications that rely on complex request routing architectures rather than simple direct page rendering. Many enterprise applications use custom mappers to handle encryption, localization, or multi-tenancy by wrapping the core Wicket components in additional delegate layers. These legitimate architectural patterns inadvertently trigger the vulnerability, creating a false sense of security where developers believe CSP is active while it is silently disabled for specific subsets of their application traffic. The flaw was introduced between versions 9.23.x and 10.10.0, meaning earlier versions handled nested delegates correctly by fully unwrapping them to determine the final handler type. This regression highlights a gap in integration testing regarding complex request handling chains within the framework's security module.
To mitigate this vulnerability, organizations running Apache Wicket must immediately upgrade to version 10.12.0 or 9.25.0, where the logic for unwrapping delegate chains has been corrected to ensure all levels are inspected before deciding on header inclusion. For applications that cannot be upgraded instantly due to dependency constraints, a temporary workaround involves ensuring that no custom IRequestHandlerDelegate implementations wrap page render handlers in more than one layer of depth. Developers should audit their request mapping configurations and refactor any multi-layered delegation logic into single-level wrappers or alternative architectural patterns such as servlet filters or Wicket components that do not rely on the delegate interface for this specific purpose. Additionally, implementing server-side monitoring to detect responses missing expected CSP headers can help identify affected endpoints in production environments while remediation efforts are underway. This incident underscores the importance of rigorous testing around security header injection logic when integrating third-party libraries that modify request handling flows within web frameworks.