Yubico hat am 12. Mai 2026 die Sicherheits-Advisory YSA-2026-02 veröffentlicht — und sie betrifft ausgerechnet die Open-Source-Library webauthn-server-core, die viele Self-Hoster und SaaS-Anbieter als Backend für ihre Passkey- und Yubikey-Anmeldung einsetzen. Die gute Nachricht: Keine Yubikey-Hardware ist von dieser Lücke betroffen. Die schlechte: Wer den Library-Bug nicht patched, riskiert User-Impersonation auf seiner eigenen Plattform.
WAS bedeutet User-Impersonation hier?
Die Library wertet WebAuthn-Assertions aus — also die kryptographischen Antworten, die ein Authenticator (Yubikey, Passkey im Browser, Hardware-Token) bei einer Anmeldung zurückschickt. Unter bestimmten Umständen konnte ein Angreifer durch manipulierte Eingaben eine Assertion so platzieren, dass die Server-Library sie als VALIDIERTEN Login für einen ANDEREN Benutzer akzeptiert. Account-Takeover ohne Diebstahl des Hardware-Tokens.
WER ist betroffen?
Du nutzt webauthn-server-core, wenn du:
- eine selbst gehostete WebAuthn-Authentifizierungs-Schnittstelle in Java/Kotlin betreibst,
- ein Bibliotheks-Dependency-Tree mit
com.yubico:webauthn-server-corein deinem POM/Build-File hast, - als SaaS-Anbieter Passkey-/Hardware-Token-Login implementiert hast und dafür die Yubico-Open-Source-Library als Backend nutzt.
Wer ausschließlich CAP- oder FIDO2-Hardware ohne eigenen Server betreibt — also reine Konsumenten-Yubikeys an fremden Diensten — ist NICHT betroffen.
SO PATCHST du in 5 MINUTEN
Bibliothek im Build-File aktualisieren auf die in YSA-2026-02 genannte Mindest-Version (siehe Yubicos Advisory-Seite), Build neu laufen lassen, Production-Deploy. Wer eine längere CI/CD-Kette hat, sollte den Patch in dieser Wartungs-Nacht durchziehen und nicht warten — User-Impersonation ist eine der gefährlichsten Klassen, weil die Logs sauber aussehen.
<!-- Maven -->
<dependency>
<groupId>com.yubico</groupId>
<artifactId>webauthn-server-core</artifactId>
<version><!-- aktuelle Patch-Version laut Advisory --></version>
</dependency>UNGLAUBLICH: Yubikey-Hardware bleibt unangetastet
Das ist das, was den Vorfall vom echten Hardware-Disaster trennt. Die Yubikeys selbst sind nicht verwundbar. Es geht ausschließlich um den Server-Code, der Authentifizierungs-Antworten validiert. Hardware-Token aus Schubladen graben, Firmware checken, panisch ersetzen — all das brauchst du NICHT. Library patchen, fertig.
EXTRA-TIPP: Library-SBOM regelmäßig checken
Wenn du noch keinen automatischen SBOM-Scan in deiner CI hast — der nächste Schritt nach diesem Patch sollte genau das sein. Dependabot, Snyk, Renovate oder ein simpler mvn versions:display-dependency-updates in der Build-Pipeline würde solche Advisories beim Library-Upstream sofort sichtbar machen.
FAZIT
Ein Library-Bug, kein Hardware-Drama. Wer schnell patched, schließt das Loch ohne Aufsehen. Wer es liegen lässt, gibt potenziellen Angreifern einen Werkzeugkasten gegen die eigene Login-Kette in die Hand.
Quellen: Yubico Security Advisory YSA-2026-02, Help Net Security, Yubico Blog 2026, GitHub yubico/java-webauthn-server.
Häufige Fragen
Sind meine Yubikeys jetzt unsicher?
Wie finde ich heraus, ob meine Plattform die Library nutzt?
com.yubico:webauthn-server-core (Maven, Gradle, sbt). Wer Java oder Kotlin im Backend hat, fragt am besten kurz das Dev-Team. SaaS-Konsumenten ohne eigenes Auth-Backend sind nicht betroffen.