Read the docs
TI-2026-67287 Aliases GHSA-6hxq-p678-4hr2

SimpleWebAuthn: Registration verification does not sufficiently ensure that attestation…

Priority LOW 38CWE-295Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
Spoofing
Confidentiality · integrity · availability
—
Fix status
Fixed

No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-295.

Summary

## Summary `validateCertificatePath()` does not verify that an attestation's certificate chain actually terminates at a configured trust anchor. When walking the chain it stops at the first self-signed certificate it finds (which could be user-supplied), and exits early. This happens before the configured Apple/Google/etc trust anchor (which is concatenated to the end of the chain) is reached. A user can therefore register a credential and have the server accept it as if it were backed by a genuine Apple / Android SafetyNet / Yubikey / etc. ## Details `packages/server/src/helpers/validateCertificatePath.ts`: The configured trust anchor is appended to the end of the untrusted chain (line **83**): ```ts const x5cWithTrustAnchor = x5cCertsParsed.concat([anchor]); ``` The walk then verifies each cert was signed by the next, but breaks on the first self-signed cert (lines **104–116**): ```ts if (issuer.subject === issuer.issuer) { // Root cert detected, make sure it signed itself const issuerSignedIssuer = await issuer.verify( { publicKey: issuer.publicKey, signatureOnly: true }, WebCrypto, ); if (!issuerSignedIssuer) { throw new InvalidSubjectAndIssuer(); } break; // <-- exits before the appended trust anchor is ever checked if user supplied self-signed cert comes first } ``` The success condition is therefore "the certs form an internally-consistent chain ending in some self-signed cert" Rather than "the chain terminates at one of the configured trust anchors." ## Exploit shape ``` attacker sends: x5c = [ forgedLeaf (signed by attacker root), attackerSelfSignedRoot ] library builds: [ forgedLeaf, attackerSelfSignedRoot, <configured Apple/Google/etc root> ] walk: forgedLeaf -> attackerSelfSignedRoot (verifies, attacker controls both) attackerSelfSignedRoot is self-signed -> break attackerSelfSignedRoot -> configured root (NEVER CHECKED) ``` `return true`. The configured anchor never gets checked. As far as observed, all attestation enforcement uses validateCertificatePath when using MDS etc.

Why it matters now

Fix Fixed @simplewebauthn/server (npm): 13.3.2

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
—@simplewebauthn/server (npm)before 13.3.213.3.2Patch availableGHSA-6hxq-p678-4hr2
  • @simplewebauthn/server (npm) Vendor— Affected before 13.3.2 Fixed in 13.3.2 Patch available GHSA-6hxq-p678-4hr2

Remediation

  • Fix · GHSA-6hxq-p678-4hr2 @simplewebauthn/server (npm) Fixed in 13.3.2 Advisory →

Timeline

  1. 2026-10-03 Threatist record created from GHSA-6hxq-p678-4hr2

References

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences