NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐘 Packagist
Not in CISA KEV

Craft CMS: Passkey login accepts replayed WebAuthn assertionsGHSA-wg23-69c2-gjc8

Fix: craftcms/cms@d71a66d

GHSA-wg23-69c2-gjc8 is a CWE-294 vulnerability in craftcms/cms. A fix is available for craftcms/cms — see the affected versions and patch details below.

Also known asCVE-2026-72780
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 11, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-wg23-69c2-gjc8.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs33th percentile — riskier than 33% of all scored CVEsHighest risk
0.00%0.29%0.59%0.89%0.2%0.4%0.4%Sep 26Oct 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐘craftcms/cms

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Craft CMS passkey login accepts WebAuthn requestOptions from the unauthenticated login request body and does not persist the updated credential counter returned by the WebAuthn assertion validator. A captured passkey login request body can therefore be replayed because the old challenge is accepted again, and the stored credential counter remains stale.

Craft CMS 5.10.3 and current 5.x HEAD accept PublicKeyCredentialRequestOptions from the unauthenticated users/login-with-passkey request body and do not persist the updated PublicKeyCredentialSource returned/mutated by web-auth/webauthn-lib after assertion validation.

As a result, a captured passkey login request body is not one-time-use. Reposting the same requestOptions and response can result in validation against the same stale credential counter and create another Craft session for that user. This weakens passkeys from a fresh, server-challenged authentication ceremony into a replayable bearer artifact if one successful assertion body is exposed.

Attack Scenario

  1. A victim successfully logs in with a passkey.
  2. The POST /actions/users/login-with-passkey body containing requestOptions and response is captured from an application/request log, debugging proxy, browser extension, compromised analytics layer, or another request-body disclosure point.
  3. The attacker reposts the same body to users/login-with-passkey.
  4. Craft deserializes the attacker-supplied requestOptions, so the old challenge remains accepted for validation.
  5. The WebAuthn validator compares the assertion's signCount against the stale stored credential counter.
  6. Because Craft did not persist the updated credential source on the original login, the same stale stored counter is used again.
  7. The same captured assertion validates and Craft creates another authenticated session for the victim account.

This is exactly what WebAuthn's challenge and signature-counter lifecycle is meant to prevent: a successful assertion should be bound to a server-issued challenge and should update server-side credential state so it cannot be used again.

Impact

An attacker who obtains one successful passkey login request body can replay it to create additional authenticated Craft sessions for that user. This defeats WebAuthn’s intended one-time challenge and signature-counter replay protection, reducing a passkey assertion to a reusable bearer artifact if exposed through request logging, a debugging proxy, a compromised same-origin script layer, or another request-body disclosure path.

The impact is an account/session takeover of the affected passkey account after a single assertion body is captured. The issue is in Craft’s native passkey login flow and affects fresh Craft installations with passkeys enabled.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistcraftcms/cms≥ 5.0.0-RC1&&< 5.10.55.10.5composer require craftcms/cms:^5.10.5

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update craftcms/cms to 5.10.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wg23-69c2-gjc8 is resolved across your whole dependency graph.

  3. Workarounds

    Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Frequently Asked Questions

Craft CMS passkey login accepts WebAuthn requestOptions from the unauthenticated login request body and does not persist the updated credential counter returned by the WebAuthn assertion validator. A captured passkey login request body can therefore be replayed because the old challenge is accepted again, and the stored credential counter remains stale. Craft CMS 5.10.3 and current `5.x` HEAD accept `PublicKeyCredentialRequestOptions` from the unauthenticated `users/login-with-passkey` request body and do not persist the updated `PublicKeyCredentialSource` returned/mutated by `web-auth/webaut
O3 Security · Impact-Aware SCA

Is GHSA-wg23-69c2-gjc8 in your dependencies?

Find it across Packagist, including transitive dependencies.

Scan my dependencies How O3 SCA works
Craft CMS: Passkey login accepts replayed WebAuthn…