CVE-2026-71378: Apache Wicket CSRF Vulnerability

CVE-2026-71378 Overview

CVE-2026-71378 is a cross-site request forgery (CSRF) vulnerability [CWE-352] in Apache Wicket's ResourceIsolationRequestCycleListener. The default FetchMetadataResourceIsolationPolicy inherits two unsafe allowances from a reference implementation designed for static resources. Wicket invokes component listeners such as Link.onClick(), form submits, and behavior callbacks through ordinary GET navigations. An attacker-controlled page can navigate a victim's browser to a listener URL, and the listener executes inside the victim's authenticated session. The policy also unconditionally permits Sec-Fetch-Site: same-site, allowing any sibling origin to invoke listeners.

Critical Impact
A cross-site or sibling-origin attacker can trigger authenticated Wicket component listeners, executing actions inside the victim's session with cookies attached.

Affected Products

Apache Wicket 9.1.0 through 9.23.0
Apache Wicket 10.0.0 through 10.10.0
Fixed in Apache Wicket 9.24.0 and 10.11.0

Discovery Timeline

2026-08-31 - CVE-2026-71378 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-71378

Vulnerability Analysis

Apache Wicket's ResourceIsolationRequestCycleListener rejects requests that a resource isolation policy attributes to another origin. The default FetchMetadataResourceIsolationPolicy was derived from a reference implementation guarding static resources. That heritage introduced two allowances that are unsafe when the protected target is a page action rather than a passive resource.

The first allowance accepts any "simple top-level navigation." Every GET request carrying Sec-Fetch-Mode: navigate with Sec-Fetch-Dest other than object or embed is permitted regardless of Sec-Fetch-Site. Wicket triggers component listeners including Link.onClick(), form submissions, and behavior callbacks through standard GET navigations. Browsers attach SameSite=Lax cookies on cross-site top-level GET navigations by default, so the victim's session cookie accompanies the request.

The second allowance accepts Sec-Fetch-Site: same-site without further checks. That value indicates the same registrable domain and scheme but a different origin, such as another subdomain or port. Cookies always accompany same-site requests regardless of SameSite attribute. A hostile sibling origin obtained through subdomain takeover, delegated user content, or XSS on another subdomain can invoke any listener using any method, including POST form submissions.

Root Cause

The root cause is an over-permissive default policy inherited from a reference model built for static resources. Wicket exposes state-changing actions through the same GET navigations that the policy exempts, converting an intended safe-resource allowance into a CSRF gap.

Attack Vector

An attacker hosts a page that navigates the victim's authenticated browser to a Wicket listener URL, or controls a sibling origin that issues cross-origin requests with credentials. The listener runs inside the victim's session and performs whatever action the component defines. Exploitation requires user interaction, such as visiting the attacker's page while authenticated to the Wicket application.

See the Apache Security Mailing List Thread for full technical details.

Detection Methods for CVE-2026-71378

Indicators of Compromise

Wicket listener invocations where the Referer or Origin header points to an unrelated site while a valid session cookie is present.
Requests to Wicket listener URLs carrying Sec-Fetch-Site: cross-site combined with Sec-Fetch-Mode: navigate.
Bursts of listener callbacks originating from subdomains that do not normally interact with the application.

Detection Strategies

Inspect web server and reverse proxy logs for GET requests to Wicket component listener paths that include Fetch Metadata headers indicating cross-site or unexpected same-site origins.
Correlate authenticated session identifiers with cross-origin Referer values on state-changing endpoints.
Alert on listener callbacks that follow user navigation from external domains not on an allowlist.

Monitoring Recommendations

Log Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Origin, and Referer headers at the ingress layer for Wicket endpoints.
Track sibling subdomains and any delegated user-content hosts for anomalous outbound requests to the primary Wicket application.
Monitor for subdomain takeover conditions on records that share a registrable domain with the Wicket application.

How to Mitigate CVE-2026-71378

Immediate Actions Required

Upgrade to Apache Wicket 9.24.0 or 10.11.0, which contain the corrected FetchMetadataResourceIsolationPolicy behavior.
Inventory Wicket applications and identify any deployments in the affected 9.1.0 through 9.23.0 or 10.0.0 through 10.10.0 version ranges.
Audit sibling subdomains and delegated content hosts for takeover risk or existing XSS that could be leveraged as a same-site pivot.

Patch Information

The Apache Wicket project released fixed versions 9.24.0 and 10.11.0. Refer to the Apache Security Mailing List Thread and the Openwall OSS Security Discussion for the official announcement. Releases older than 9.1.0, including the entire 8.x line, are not affected because the resource isolation classes did not exist before WICKET-6786.

Workarounds

Add the legacy CsrfPreventionRequestCycleListener to enforce Origin and Referer checks alongside the resource isolation policy.
Configure the application to reject GET requests to component listener URLs when Sec-Fetch-Site is cross-site or same-site from unexpected origins.
Set explicit SameSite=Strict attributes on session cookies where compatible with the application's navigation flows.
Restrict which subdomains can host user content or third-party code that shares the registrable domain.

bash

# Configuration example: enforce stricter cookie scope and add legacy CSRF listener
# In your Wicket Application init():
#   getRequestCycleListeners().add(new CsrfPreventionRequestCycleListener());
#
# In your servlet container or reverse proxy, harden the session cookie:
Set-Cookie: JSESSIONID=...; Path=/; Secure; HttpOnly; SameSite=Strict