Repository navigation
10000
No milestoneNone yetNo branches or pull requests
[CVE-2026-6856] Acceptable AAGUID policy bypass via packed self-attestation in WebAuthn registration #48388
Description
Description
WebAuthn AAGUID policy bypass via packed self-attestation. Similar to CVE-2025-12150. When direct attestation is requested but the authenticator sends self-attestation (no x5c), the AAGUID is unverified, allowing bypass of the acceptable AAGUID allowlist.
Additional notes
By default, for a simple implementation, attestation and AAGUIDs may not be considered necessary. It's considered a high level security setting that the company uses to enforce specific authenticators or because they don't trust in users.
Acknowledgement
We acknowledge Pelissier, Sylvain (SICPA) for reporting this issue to the Keycloak security team.
This issue was originally tracked in the private repository. Migrated by @ahus1.
Reacted by Martin Bartoš, Sylvain Pelissier and Takashi Norimatsu
Metadata
Metadata
Assignees
Labels
Type
Fields
No fields configured for cve.
Projects
- Status
Activity
sylvainpelissier commentedon Apr 23, 2026
There is another think I noticed while reviewing the patch, The default truststore is the JVM's cacerts file, which contains hundreds of public commercial CAs (DigiCert, GlobalSign, Sectigo, etc.). This means every one of those CAs is implicitly trusted as a FIDO attestation CA. Webauthn4j does validate some attestation fields like Subject-OU must be "Authenticator Attestation" or CA=false Basic Constraint, which makes a standard TLS cert unusable directly. But the architectural problem is that the trust boundary for TLS and for FIDO attestation is conflated, meaning any operator or attacker with access to add entries to the TLS truststore gains implicit power over FIDO attestation validation. In my opinion, the two trust stores should be separated.
rmartinc commentedon Apr 23, 2026
The TLS trust-store can be separated to another file (https://www.keycloak.org/server/mutual-tls), but your suggestion is a very big change that probably should be managed when re-thinking the certificates per realm #33273. In general the trust-store is used for everything and there can be different usages.
This issue is just to cover the corner cases that allowed to pass a untrusted AAGUIDs.
sylvainpelissier commentedon Apr 23, 2026
Ok maybe this is another issue but by default FIDO CA certificates have to be in a separate trust store else the AAGUID filtering may be also bypassed.
ahus1 commentedon Apr 23, 2026
@sylvainpelissier - I think this is a good point. Please create a new issue of type "enhancement" and mention it here to link it.
It might then be handled in a bigger context as @rmartinc mentioned, or separately when it receives a lot of community interest.
21 remaining items
Make acceptable AAGUID ckeck in WebAuthn stricter
Check Acceptable AAGUIDs sets a attestation preference different to N…
Changes for rebase and review.