CVE-2024-12225: Quarkus WebAuthn Auth Bypass Vulnerability

CVE-2024-12225 Overview

A critical authentication bypass vulnerability affects the quarkus-security-webauthn module in Quarkus. The module exposes default REST endpoints for user registration and login. These default endpoints remain accessible even when developers implement custom REST endpoints. Attackers can obtain a valid login cookie without a corresponding user account in the application. Depending on application logic, the cookie may also map to an existing legitimate user. This allows anyone to authenticate as an existing user knowing only the target's username. The flaw is tracked as [CWE-288: Authentication Bypass Using an Alternate Path or Channel].

Critical Impact
Remote unauthenticated attackers can impersonate any existing user in a Quarkus application using WebAuthn by knowing only the target username.

Affected Products

Quarkus framework with the quarkus-security-webauthn extension enabled
Applications providing custom WebAuthn REST endpoints alongside Quarkus defaults
Red Hat Build of Quarkus distributions referencing this advisory

Discovery Timeline

2025-05-06 - CVE-2024-12225 published to the National Vulnerability Database
2025-07-31 - Last updated in NVD database

Technical Details for CVE-2024-12225

Vulnerability Analysis

The Quarkus WebAuthn module registers default REST endpoints for user registration and login when the extension is added to an application. These endpoints handle the WebAuthn ceremony and issue a session cookie upon completion. Developers who want custom behavior typically add their own REST endpoints to handle login and registration. The defect is that adding custom endpoints does not disable the built-in ones. Both endpoint sets remain reachable over the network.

An attacker can interact directly with the default endpoint and complete a flow that issues a login cookie. The cookie may reference a non-existent user, or it may reference a real user account depending on how the application validates credentials. The result is an authentication bypass that requires no privileges and no user interaction.

Root Cause

The root cause is an insecure default configuration combined with missing access control on built-in routes. The framework should disable or guard its default WebAuthn endpoints when application code provides custom equivalents. Because both routes are wired into the HTTP router, the secondary built-in path bypasses the developer's authentication logic. This matches the [CWE-288] pattern of authentication using an alternate channel.

Attack Vector

Exploitation occurs over the network without authentication or user interaction. An attacker sends crafted requests to the default WebAuthn registration or login endpoint exposed by the Quarkus application. The server completes the ceremony and returns a session cookie. The attacker replays that cookie against application routes that trust the WebAuthn session. If the application keys authorization decisions on the user name embedded in the cookie, the attacker can act as that user.

No verified public proof-of-concept exists. See the Red Hat CVE-2024-12225 Advisory and Red Hat Bug Report #2330484 for vendor technical details.

Detection Methods for CVE-2024-12225

Indicators of Compromise

Unexpected HTTP requests to default WebAuthn paths such as /q/webauthn/login and /q/webauthn/register from external sources
Issuance of WebAuthn session cookies followed by privileged actions performed under a different source identity
Authentication events for user accounts originating from IP addresses or user agents that do not match historical patterns

Detection Strategies

Review web access logs for traffic to built-in Quarkus WebAuthn routes when the application is intended to expose only custom endpoints
Correlate WebAuthn login events with subsequent session activity to identify sessions that never completed a legitimate hardware authenticator challenge
Alert on successful login responses returned by endpoints that the application owner does not intend to be reachable

Monitoring Recommendations

Forward Quarkus application HTTP logs and authentication events to a central analytics platform for correlation
Track route-level request volumes and flag anomalies on default WebAuthn paths after upgrades or configuration changes
Monitor for session cookies issued without an associated WebAuthn assertion log entry from the custom endpoint

How to Mitigate CVE-2024-12225

Immediate Actions Required

Upgrade Quarkus to a release that disables the default WebAuthn endpoints when custom endpoints are in use, per the Red Hat CVE-2024-12225 Advisory
Audit deployed Quarkus applications for the quarkus-security-webauthn extension and confirm whether default endpoints are reachable
Invalidate existing WebAuthn session cookies and force re-authentication after patching

Patch Information

Red Hat maintains the authoritative remediation guidance in the Red Hat CVE-2024-12225 Advisory and the corresponding Red Hat Bug Report #2330484. Apply the fixed Quarkus version referenced in those resources and rebuild affected applications. Verify that the default WebAuthn endpoints are no longer reachable after deployment.

Workarounds

Block external access to the default Quarkus WebAuthn paths at the reverse proxy or ingress layer until patching is complete
Configure the application to override the default endpoint paths so that built-in handlers are not bound to a reachable route
Add request filters that reject any traffic to built-in WebAuthn endpoints when custom authentication flows are in use

bash

# Example NGINX rule to block built-in WebAuthn endpoints at the edge
location ~ ^/q/webauthn/(login|register|callback) {
    return 404;
}