# WebAuthn assertion accepted for an invalid account or ceremony context

The relying party accepts a passkey assertion without the required account, challenge, signature, origin, or verification binding.

**Candidate CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html) · [CWE-347](https://cwe.mitre.org/data/definitions/347.html)

## Test hypothesis

Start from a working local WebAuthn ceremony. Compare one consumed assertion, one invalid signature, and a validly signed fixture violating one server-side policy. For username-first login, check credential ownership; for discoverable login, check that the user handle and credential resolve to the same account.

## Evidence required

Expected relying-party policy, credential owner, altered validation condition, server acceptance, and resulting protected identity. Identify the verifier check that failed; editing signed bytes alone does not isolate semantic validation.

## Rule out false positives

Valid passwordless login to the credential owner, supported related origins, no attestation requirement, or a zero/non-increasing counter by itself does not prove bypass or cloning.

## Playbook and command references

- [MFA and passkeys: enrollment, proof, replacement, and recovery](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/authenticator-lifecycle.html) — Follow each authenticator from account binding to removal, and validate WebAuthn assertions without mistaking client UI or counter behavior for a security guarantee.
- [Authentication, recovery, federation, and session lifecycle](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/modules/identity-session.html) — Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

[Find the associated command snippets](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/commands.html?q=MFA%20and%20passkeys%3A%20enrollment%2C%20proof%2C%20replacement%2C%20and%20recovery)

## Referenced by these target playbooks

[Web & API](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/web-api.html) · [OSS & self-hosted](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/oss.html) · [Mobile](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/mobile.html) · [Desktop & extensions](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/desktop.html) · [Cloud & containers](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/cloud.html)

## Report checklist

- [ ] Capture the affected version, configuration, identities, and object ownership.
- [ ] Preserve a valid baseline and a negative control.
- [ ] Reproduce the forbidden data access, action, or state change on controlled fixtures.
- [ ] Explain the intended security rule and why the observed behavior violates it.
- [ ] State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.

## Conditional ATT&CK mapping

No direct ATT&CK mapping selected. Record the weakness and demonstrated impact without forcing an adversary-behavior classification. See the [mapping guide](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/attack.html).

## Primary references

- [W3C WebAuthn Level 3 Recommendation, 25 August 2026](https://www.w3.org/TR/2026/REC-webauthn-3-20260825/)
- [Yubico WebAuthn Client Authentication](https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Authentication.html)

[Back to the complete vulnerability catalog](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/vulnerabilities.html)