CVE-2024-27439: Apache Wicket CSRF Protection Bypass

CVE-2024-27439 Overview

CVE-2024-27439 is a Cross-Site Request Forgery (CSRF) protection bypass in Apache Wicket, a component-based Java web application framework. The flaw stems from an error in how Wicket evaluates fetch metadata headers, which are used to distinguish legitimate same-origin requests from cross-site requests. An attacker can craft requests that pass the flawed metadata check, defeating the built-in CSRF defenses. The issue affects Apache Wicket 9.1.0 through 9.16.0 and the 10.0 milestone releases. Apache Wicket 8.x does not implement CSRF protection via fetch metadata and is not affected. The Apache Wicket project released fixed versions 9.17.0 and 10.0.0 to remediate the flaw.

Critical Impact
Attackers can bypass Apache Wicket's fetch-metadata-based CSRF protection, enabling forged state-changing requests against authenticated users of affected web applications.

Affected Products

Apache Wicket 9.1.0 through 9.16.0
Apache Wicket 10.0.0-M1 (milestone1)
Apache Wicket 10.0.0-M2 (milestone2)

Discovery Timeline

2024-03-19 - CVE-2024-27439 published to the National Vulnerability Database (NVD)
2024-03-19 - Apache project announcement posted to the Apache Mailing List Discussion and the OpenWall OSS Security Update
2026-06-17 - Last updated in the NVD database

Technical Details for CVE-2024-27439

Vulnerability Analysis

Apache Wicket implements CSRF protection by inspecting the browser-supplied Sec-Fetch-* headers (Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest). These headers indicate whether a request was initiated from the same origin, a cross-site context, or a user-initiated navigation. The framework uses this information to reject cross-site requests targeting state-changing endpoints.

The vulnerability, classified under [CWE-352] Cross-Site Request Forgery, arises from an error in the header evaluation logic. Under specific conditions the framework treats a request as safe when it should be rejected. An attacker who lures an authenticated user to a malicious page can issue forged requests that invoke Wicket components and listener interfaces on behalf of that user.

Successful exploitation impacts the confidentiality and integrity of user-scoped data handled by the vulnerable application. The vulnerability requires no authentication or user interaction beyond visiting attacker-controlled content in an authenticated session.

Root Cause

The root cause is faulty conditional logic within the fetch metadata evaluation routine used by Wicket's CSRF preventing request cycle listener. Certain header combinations that should be classified as cross-site are accepted as same-origin, allowing the request to proceed to the target Wicket page or listener without CSRF rejection.

Attack Vector

Exploitation is network-based and does not require prior authentication on the attacker's part. The victim must hold an authenticated session with a Wicket application on an affected version. An attacker hosts a page that triggers a request against the target Wicket endpoint using a method and header set that satisfies the flawed metadata check. When the victim browses the malicious page, the browser attaches session cookies and issues the request, and Wicket processes it as if it originated from a legitimate same-origin interaction.

No public proof-of-concept exploit code has been published for CVE-2024-27439. Refer to the Apache Mailing List Discussion for the vendor's technical description of the flaw.

Detection Methods for CVE-2024-27439

Indicators of Compromise

Wicket application requests carrying unexpected Sec-Fetch-Site: cross-site or Sec-Fetch-Mode: no-cors values that still reach state-changing listener interfaces
HTTP Referer values pointing to external origins on requests targeting Wicket page URLs that include component listener parameters such as ?wicket:interface= or ?-1.IBehaviorListener
Server-side application logs showing successful component or form processing initiated from unauthenticated third-party origins

Detection Strategies

Inventory all deployed Apache Wicket versions and flag any instance in the 9.1.0 through 9.16.0 range or the 10.0 milestone series
Enable web application firewall rules that log or block requests to Wicket listener endpoints when fetch metadata headers indicate a cross-site initiator
Correlate authentication session identifiers with request origin headers to identify anomalous cross-origin activity against authenticated Wicket applications

Monitoring Recommendations

Ingest Wicket application access logs and fronting reverse-proxy logs into a centralized analytics platform to enable retrospective hunting for CSRF-style patterns
Alert on spikes in form submissions or listener invocations with absent or inconsistent Origin and Referer headers
Track dependency manifests (pom.xml, build.gradle) in source control to detect pinned vulnerable Wicket versions during build pipelines

How to Mitigate CVE-2024-27439

Immediate Actions Required

Upgrade Apache Wicket to version 9.17.0 for the 9.x branch or 10.0.0 for the 10.x branch, which contain the corrected fetch metadata evaluation logic
Audit all internal and public-facing Java applications for embedded Wicket dependencies, including transitive dependencies pulled in by other libraries
Invalidate long-lived authenticated sessions after patching to reduce the window in which a stolen or forged interaction could be replayed

Patch Information

The Apache Wicket project fixed the fetch metadata evaluation error in versions 9.17.0 and 10.0.0. Details are published in the Apache Mailing List Discussion and the OpenWall OSS Security Update. No backport exists for Apache Wicket 8.x because that branch does not implement fetch-metadata-based CSRF protection and is not affected.

Workarounds

Deploy a reverse proxy or web application firewall rule that rejects requests to Wicket listener URLs when Sec-Fetch-Site is cross-site and the HTTP method is not GET
Enforce SameSite=Strict or SameSite=Lax on session cookies to reduce the effectiveness of cross-origin forged requests
Restrict sensitive Wicket endpoints behind additional server-side origin validation until the upgrade to 9.17.0 or 10.0.0 is completed

bash

# Example Maven dependency upgrade to the fixed 9.x release
mvn versions:use-dep-version -Dincludes=org.apache.wicket:wicket-core -DdepVersion=9.17.0 -DforceVersion=true
mvn clean verify