# GHSA-6hxq-p678-4hr2: `validateCertificatePath()` does not verify that an attestation's certificate chain actually terminates at a configured trust anchor.

> Attackers can bypass WebAuthn attestation verification by supplying a self-signed certificate, allowing registration of unverified credentials.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 4 Sep 2026

## What is GHSA-6hxq-p678-4hr2?

GHSA-6hxq-p678-4hr2 is a vulnerability in @simplewebauthn/server, published on 4 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## 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.

## Which versions are affected by GHSA-6hxq-p678-4hr2?

2 open source packages ship an affected version, including @simplewebauthn/server.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@simplewebauthn/server` | npm | All versions | 13.3.2 |
| `@simplewebauthn/server` | npm | All versions | 13.3.2 |

## How do I fix GHSA-6hxq-p678-4hr2?

Upgrade @simplewebauthn/server to 13.3.2 or later.

## Is GHSA-6hxq-p678-4hr2 being exploited?

There is no known exploitation of GHSA-6hxq-p678-4hr2 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-6hxq-p678-4hr2 and fix it if it is affected.

What it is: GHSA-6hxq-p678-4hr2 is a vulnerability in @simplewebauthn/server, published on 4 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-6hxq-p678-4hr2 in the wild and no public exploit code.

Affected packages and fixed versions:
- @simplewebauthn/server (npm): affected all versions; fixed in 13.3.2
- @simplewebauthn/server (npm): affected all versions; fixed in 13.3.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-6hxq-p678-4hr2/ (Markdown: https://insights.sbomify.com/GHSA-6hxq-p678-4hr2/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-6hxq-p678-4hr2

---
From sbomify Insights: https://insights.sbomify.com/GHSA-6hxq-p678-4hr2/
Summaries are generated and may contain mistakes; the official description above is the record.