VulnerabilityPublished 6 May 2026

webauthn-rs-core/webauthn-authenticator-rs: Origin validation mismatch possible when subdomains are allowed

Affects webauthn-rs-coreSource GCVE Database

CVSS 2.3 Low : upgrade to 0.5.5 when convenient.

Data as of 27 Oct 2026, 00:07 UTC

CVSS 4.0 base score

2.3Low

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 0.5.5, 0.6.1-dev

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Attack Vector: Network
Attack Complexity: High
Attack Requirements: Present
Privileges Required: None
User Interaction: Passive
Vulnerable system confidentiality: Low
Vulnerable system integrity: Low
Vulnerable system availability: None
Subsequent system confidentiality: None
Subsequent system integrity: None
Subsequent system availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: High: The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques, for example, circumvention of address space randomization (ASLR) or data execution prevention (DEP) must be performed for the attack to be successful; Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Attack Requirements: Present: The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: a race condition must be won to successfully exploit the vulnerability (the successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker, or the attack may need to be launched multiple times against a single target before being successful); the attacker must inject themselves into the logical network path between the target and the resource requested by the victim (e.g. vulnerabilities requiring an on-path attacker).
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction: Passive: Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable system and the attacker’s payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable system.
Vulnerable system confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Vulnerable System.
Vulnerable system integrity: Low: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Vulnerable System.
Vulnerable system availability: None: There is no impact to availability within the Vulnerable System.
Subsequent system confidentiality: None: There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Subsequent system integrity: None: There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Subsequent system availability: None: There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.

Definitions: FIRST CVSS v4.0 specification.

What to do

Upgrade webauthn-rs-core and webauthn-authenticator-rs to 0.5.5; webauthn-authenticator-rs and webauthn-rs-core to 0.6.1-dev.

Affected software

Product	Affected	Fixed in
crates.iowebauthn-rs-core	Affected <0.5.5	Fixed in 0.5.5
crates.iowebauthn-authenticator-rs	Affected >=0.6.0-dev <0.6.1-dev =0.6.0-dev	Fixed in 0.6.1-dev
crates.iowebauthn-rs-core	Affected >=0.6.0-dev <0.6.1-dev =0.6.0-dev	Fixed in 0.6.1-dev
crates.iowebauthn-authenticator-rs	Affected <0.5.5	Fixed in 0.5.5

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

### Summary `webauthn-rs-core` ([Relying Party][rp]) and `webauthn-authenticator-rs` ([client][]) checked that [an `Origin` in `CollectedClientData`][origin] is valid for [an RP ID][rpid] with [`str::ends_with()`][ends-with], [without checking for a dot (`.`) before the RP ID when allowing subdomains][registerable-suffix]. This check is flawed, and could allow requests from an attacker-controlled domain such as `hermit-crab.example` to be accepted for the RP ID `crab.example` (assuming `.example` was publicly-registerable TLD) when the RP allows authenticating from a subdomain (disabled by default in `webauthn-rs-core` and `webauthn-rs`). [registerable-suffix]: https://html.spec.whatwg.org/multipage/browsers.html#is-a-registrable-domain-suffix-of-or-is-equal-to [ends-with]: https://doc.rust-lang.org/stable/std/primitive.str.html#method.ends_with [client]: https://www.w3.org/TR/webauthn-3/#client [rp]: https://www.w3.org/TR/webauthn-3/#relying-party [rpid]: https://www.w3.org/TR/webauthn-3/#rp-id [origin]: https://www.w3.org/TR/webauthn-3/#dom-collectedclientdata-origin * In `webauthn-rs-core`, this **only** applies when: * [`WebauthnCore::allow_subdomains_origin`](https://docs.rs/webauthn-rs-core/0.5.4/webauthn_rs_core/struct.WebauthnCore.html#method.new_unsafe_experts_only) is `true` (the default is `false`), *and* * the attacker could register a domain that ends with the RP ID as a raw string, *and*, * the client does not implement these checks correctly either `webauthn-rs` can set `allow_subdomains_origin` via [`WebauthnBuilder::allow_subdomains`](https://docs.rs/webauthn-rs/0.5.4/webauthn_rs/struct.WebauthnBuilder.html#method.allow_subdomains). Fixing the bug in `webauthn-rs-core` also fixes it in `webauthn-rs`. * In `webauthn-authenticator-rs`, the flawed check is in [`WebauthnAuthenticator::do_registration()`](https://docs.rs/webauthn-authenticator-rs/0.5.4/webauthn_authenticator_rs/struct.WebauthnAuthenticator.html#method.do_registration) and [`do_authentication()`](https://docs.rs/webauthn-authenticator-rs/0.5.4/webauthn_authenticator_rs/struct.WebauthnAuthenticator.html#method.do_registration). A conforming [Relying Party][rp] implementation would reject such requests, but `webauthn-rs-core` did not. An application can still provide an incorrect `origin` parameter to `webauthn-authenticator-rs`, or use lower-level APIs that bypass these checks entirely, and this is by design. These issues are a violation of [WebAuthn Level 3 §13.4.9](https://www.w3.org/TR/webauthn-3/#sctn-validating-origin), [§5.1.3 Step 8](https://www.w3.org/TR/webauthn-3/#CreateCred-DetermineRpId) and [§5.1.4.1 Step 7](https://www.w3.org/TR/webauthn-3/#GetAssn-DetermineRpId). ### Details * `webauthn-rs-core/src/core.rs` line 1213: https://github.com/kanidm/webauthn-rs/blob/197cddf8487a2dbdd5d374e50d80aa1e4682f3ab/webauthn-rs-core/src/core.rs#L1211-L1216 * `webauthn-authenticator-rs/src/lib.rs` line 274: https://github.com/kanidm/webauthn-rs/blob/197cddf8487a2dbdd5d374e50d80aa1e4682f3ab/webauthn-authenticator-rs/src/lib.rs#L274-L277 * `webauthn-authenticator-rs/src/lib.rs` line 335: https://github.com/kanidm/webauthn-rs/blob/197cddf8487a2dbdd5d374e50d80aa1e4682f3ab/webauthn-authenticator-rs/src/lib.rs#L335-L338 [`str::ends_with()`][ends-with] performs a raw string suffix match _without_ [enforcing a domain label boundary][registerable-suffix]: Origin | RP ID | Expected result | Result with incorrect `ends_with` check -- | -- | -- | -- `hermit-crab.example` | `crab.example` | rejected | accepted **(bug!)** `auth.crab.example` | `crab.example` | accepted | accepted (subdomain) `crab.example` | `crab.example` | accepted | accepted (exact match) `hermit-crab.example` | `auth.crab.example` | rejected | rejected `auth.crab.example` | `auth.crab.example` | accepted | accepted (exact match) ### Fix When `webauthn-rs-core` v0.5.5 checks if an `Origin` is a valid subdomain of an RP ID, it will check that it ends with the RP ID prefixed with a dot (`.{rp_id}`). `webauthn-rs` v0.5.5 will be fixed by depending on `webauthn-rs-core` v0.5.5. `webauthn-authenticator-rs` v0.5.5 now uses `webauthn-rs-core`'s checks in `WebauthnAuthenticator`. Regression tests for this bug have been added to both libraries. ### Impact With a **both** a non-conforming [client][] implementation and vulnerable version of `webauthn-rs-core` configured to allow subdomains (not the default), this bug would allow an attacker at `hermit-crab.example` to phish a target's credential for the RP ID `crab.example` by directly proxying a legitimate `navigator.credentials.get()` request on the attacker's domain. However, _conforming_ [client implementations][client] (ie: all web browsers) will refuse to process WebAuthn requests for an RP ID that does not match the `Origin` of the current page and is not [a related `Origin`](https://www.w3.org/TR/webauthn-3/#sctn-related-origins). In the scenario above with _conforming_ client-side che

CWE-1289Improper Validation of Unsafe Equivalence in Input (opens in a new tab)
Base weakness
The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.
Implementation · Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
OWASP Cheat Sheets
XML Security (opens in a new tab)
Mass Assignment (opens in a new tab)
OWASP ASVS 4.0.3
V13.3.1 (opens in a new tab)
V5.1.4 (opens in a new tab)
V5.1.3 (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

WeaknessesCWE-1289

Technical details

References

Community reviews

Related threats