GHSA-WG23-69C2-GJC8: Passkey Login Replay Vulnerability in Craft CMS

Craft CMS versions 5.0.0-RC1 through 5.10.4.1 contain an authentication bypass vulnerability within the native Passkey (WebAuthn) login implementation. This flaw allows an attacker to reuse a captured WebAuthn authentication assertion to establish unauthorized sessions. The vulnerability represents a failure to enforce core WebAuthn security specifications on the server side.

The vulnerable component resides in the core authentication handling logic, specifically within the controller and service classes responsible for validating WebAuthn assertions. Under normal conditions, WebAuthn relies on strict cryptographic challenge-response mechanisms and monotonically increasing counters to prevent replay attacks. These protections ensure that each login assertion is unique and used exactly once.

Due to implementation errors in Craft CMS, both the session challenge validation and the signature counter tracking were rendered ineffective. Consequently, any attacker capable of intercepting a valid passkey authentication request can replay the payload to achieve full account takeover. The flaw requires no special privileges and bypasses standard multi-factor authentication controls.

The vulnerability is a classic representation of CWE-294 (Authentication Bypass by Capture-replay) and is caused by two distinct software design failures. First, the application's passkey login controller deserialized the cryptographic challenge options directly from the client's unauthenticated HTTP request body. It did not verify them against a server-side session variable.

By trusting the client-supplied requestOptions parameter, the application allowed an attacker to supply a historic challenge value alongside a historic signature. The server validated the signature against the self-supplied challenge within the request, neutralizing the security guarantee of the challenge-response mechanism. This eliminated the temporal uniqueness constraint required by WebAuthn.

Second, the application failed to persist the updated signature counter (signCount) returned by the WebAuthn validation library. While the library successfully verified the assertion and returned an updated credential source object with an incremented counter, the application discarded this returned object. As a result, the database copy of the signature counter remained permanently static, rendering clone detection and replay prevention checks non-functional.

The execution flow for the vulnerability involves the controller extracting client parameters and passing them directly to the verification service. The diagram below illustrates how the validation checks succeed despite using replayed data.

The vulnerable controller code in src/controllers/UsersController.php extracted the challenge options directly from the POST request body:

// Vulnerable: Reads challenge options from client request
$requestOptions = $this->request->getRequiredBodyParam('requestOptions');

The patch resolves this by reading the challenge parameters directly from the user's secure session and deleting the variable to prevent subsequent reuse:

// Patched: Extracts and removes options from server-side session
$requestOptions = SessionHelper::remove(Craft::$app->getAuth()->passkeyRequestOptionsParam);
if (!$requestOptions) {
    return $this->asFailure(Craft::t('app', 'Passkey authentication failed.'));
}

In src/services/Auth.php, the verification function initially verified the key but failed to capture or persist the updated key source:

// Vulnerable: Output of check() containing updated counter is discarded
$this->webauthnServer()->getAuthenticatorAssertionResponseValidator()->check(
    $publicKeyCredentialSource,
    $authenticatorAssertionResponse,
    $publicKeyCredentialRequestOptions,
    Craft::$app->getRequest()->getHostName(),
    $userEntity->id,
);

The patched service captures the output and caches it in the session temporarily:

// Patched: Captures and caches the updated credential source
$updatedPublicKeyCredentialSource = $this->webauthnServer()->getAuthenticatorAssertionResponseValidator()->check(
    $publicKeyCredentialSource,
    $authenticatorAssertionResponse,
    $publicKeyCredentialRequestOptions,
    Craft::$app->getRequest()->getHostName(),
    $userEntity->id,
);
SessionHelper::set($this->passkeyCredSourceParam, $updatedPublicKeyCredentialSource);

Finally, src/elements/User.php retrieves the updated source from the session and commits the new signature counter to the database:

// Patched: Commits the new counter to the repository
$updatedPublicKeyCredentialSource = Session::remove($authService->passkeyCredSourceParam);
$authService->webauthnServer()->getCredentialRepository()->saveCredentialSource($updatedPublicKeyCredentialSource);

Exploiting this vulnerability requires the interception of a single valid Passkey authentication payload. An attacker must monitor or retrieve the raw HTTP request body transmitted during a legitimate user's login sequence to /actions/users/login-with-passkey. This can be achieved through network monitoring, server log exposure, or client-side compromise.

Once the payload is captured, the attacker can replay the identical JSON request body to the target application. Because the application uses the request's own client-supplied challenge options, the cryptographic verification succeeds. The server assumes the assertion is fresh because it is matched against the accompanying replayed challenge.

Because the application does not persist the updated signature counter, the server-side validator compares the replayed counter against a static database value. This allows the request to bypass both WebAuthn challenge verification and signature-counter freshness checks. The server then generates a new session cookie for the attacker, resulting in immediate session takeover.

The impact of this vulnerability is classified as critical, carrying a CVSS v4 score of 9.1. An attacker who successfully replays a captured assertion gains full access to the target user account, which may include administrative privileges depending on the compromised user's role. This bypasses the multi-factor authentication guarantees typically provided by physical security keys.

This vulnerability undermines the primary security assumption of WebAuthn and Passkeys, which are designed to resist replay and credential-harvesting attacks. If passkey authentication is the primary factor of authentication, the bypass allows direct administrative access to the Craft CMS control panel.

With administrative access, an attacker can modify template files, execute arbitrary code via server configuration parameters, extract database contents, or completely deface the hosted web application. The lack of a corresponding CVE does not minimize the severity of this flaw, as it represents a complete authentication failure within a core identity component.

The primary remediation path is upgrading the Craft CMS framework to version 5.10.5 or later. Administrators can perform this update via Composer by running the command composer update craftcms/cms --with-dependencies inside their root project directory.

If an immediate upgrade is not possible, administrators should disable the native Passkey (WebAuthn) login feature within the application's authentication configuration. This restricts users to standard password-based login or alternative multi-factor authentication methods that do not rely on the vulnerable WebAuthn wrapper.

Security teams can detect potential historical exploitation by querying the database table webauthnrecords. A signature counter that remains static across multiple successful login events for a single passkey indicates that the vulnerable code path was executed without updating the state.