CVE-2024-12225: Quarkus WebAuthn Auth Bypass Vulnerability

CVE-2024-12225 Overview

A critical authentication bypass vulnerability was discovered in the Quarkus quarkus-security-webauthn module. The vulnerability exists because the Quarkus WebAuthn module publishes default REST endpoints for user registration and login while simultaneously allowing developers to provide custom REST endpoints. When developers implement custom REST endpoints, the default endpoints remain accessible, creating a dangerous security gap. This flaw potentially allows attackers to obtain a login cookie without a corresponding user in the Quarkus application, or more critically, could allow an attacker to log in as an existing user simply by knowing that user's username.

Critical Impact

Attackers can bypass authentication and gain unauthorized access to applications by exploiting exposed default WebAuthn endpoints, potentially impersonating legitimate users with no additional credentials required.

Affected Products

• Quarkus (all versions with quarkus-security-webauthn module)
• Applications using custom WebAuthn REST endpoints alongside default endpoints
• Red Hat products incorporating vulnerable Quarkus versions

Discovery Timeline

• May 6, 2025 - CVE-2024-12225 published to NVD
• July 31, 2025 - Last updated in NVD database

Technical Details for CVE-2024-12225

Vulnerability Analysis

This vulnerability is classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel). The core issue stems from architectural oversight in the Quarkus WebAuthn module where the module's default REST endpoints for user registration and authentication remain active even when developers implement their own custom endpoints.

In typical Quarkus WebAuthn implementations, developers may create custom REST endpoints to handle user registration and login flows with application-specific logic. However, the framework fails to disable or restrict access to the built-in default endpoints when custom implementations are detected. This creates two parallel authentication paths—the intended custom path and the unintended default path.

An attacker can exploit this by directly accessing the default endpoints, bypassing any custom security logic, validation, or business rules implemented in the custom endpoints. The impact is severe: attackers can either create sessions for non-existent users or, depending on application design, authenticate as existing users by only knowing their username.

Root Cause

The root cause lies in the Quarkus WebAuthn module's failure to implement mutual exclusivity between default and custom REST endpoints. When a developer registers custom endpoints for WebAuthn authentication flows, the framework should automatically disable or protect the default endpoints. Instead, both sets of endpoints remain simultaneously active and accessible, creating an alternate authentication path that attackers can abuse.

This design flaw means that any application-specific security measures, such as additional verification steps, rate limiting, or multi-factor authentication implemented in custom endpoints, can be completely bypassed by targeting the default endpoints directly.

Attack Vector

The attack is network-based and requires no authentication or user interaction to execute. An attacker targeting a vulnerable Quarkus application would:

1. Identify that the application uses the Quarkus WebAuthn module
2. Enumerate the default WebAuthn REST endpoints that remain exposed
3. Submit authentication requests directly to the default endpoints, bypassing custom security controls
4. Obtain a valid session cookie by providing only a username of a legitimate user
5. Use the obtained cookie to access the application with the privileges of the impersonated user

The attack complexity is low because the default endpoints follow predictable patterns, and no special privileges or credentials are required beyond knowledge of a valid username.

Detection Methods for CVE-2024-12225

Indicators of Compromise

• Unexpected authentication requests to default WebAuthn endpoints such as /q/webauthn/login or /q/webauthn/register
• Session cookies issued without corresponding custom endpoint activity in application logs
• User accounts reporting unauthorized access despite using strong WebAuthn credentials
• Anomalous login patterns where users appear to authenticate from unfamiliar locations or devices without standard WebAuthn challenge-response sequences

Detection Strategies

• Implement monitoring for HTTP requests targeting default Quarkus WebAuthn REST endpoints
• Configure web application firewalls (WAF) to alert on requests to /q/webauthn/* paths if custom endpoints are in use
• Enable detailed authentication logging to track the source endpoint of all session creation events
• Deploy SentinelOne Singularity Platform to monitor for suspicious authentication patterns and lateral movement following potential authentication bypass

Monitoring Recommendations

• Audit all incoming requests to WebAuthn-related endpoints and correlate with expected custom endpoint traffic patterns
• Set up alerts for session cookie creation events that do not follow the expected custom authentication flow
• Monitor for high-frequency authentication attempts that may indicate automated exploitation
• Review application logs for authentication events that lack the expected custom validation markers

How to Mitigate CVE-2024-12225

Immediate Actions Required

• Review your Quarkus application to determine if the quarkus-security-webauthn module is in use with custom REST endpoints
• Explicitly disable or restrict access to default WebAuthn endpoints at the application or reverse proxy level
• Implement network segmentation to limit access to authentication endpoints from untrusted sources
• Audit authentication logs for any evidence of exploitation via default endpoints

Patch Information

Organizations should consult the Red Hat CVE Advisory for official patch information and guidance. Additional technical details and tracking information are available in the Red Hat Bug Report. Update to the latest patched version of Quarkus as soon as it becomes available and verify that default WebAuthn endpoints are properly secured after patching.

Workarounds

• Configure explicit access controls to block requests to default WebAuthn endpoints such as /q/webauthn/login and /q/webauthn/register
• Use a reverse proxy or WAF to filter and deny traffic to default WebAuthn paths
• Implement IP allowlisting for authentication endpoints if upgrading is not immediately possible
• Consider temporarily disabling the WebAuthn module entirely if custom authentication alternatives are available

# Example: Block default WebAuthn endpoints using reverse proxy (nginx)
location ~ ^/q/webauthn/ {
    deny all;
    return 403;
}