CVE-2026-27840 in Zitadel
Zusammenfassung
von VulDB • 30.05.2026
ZITADEL ist eine Open-Source-Identitätsmanagementplattform. Ab Version 2.31.0 und vor den Versionen 3.4.7 und 4.11.0 werden opaque OIDC-Zugriffstoken im v2-Format, die auf 80 Zeichen abgeschnitten wurden, weiterhin als gültig betrachtet. Zitadel verwendet für opaque Tokens eine symmetrische AES-Verschlüsselung. Der Klartext-Payload ist eine Verkettung mehrerer Identifikatoren, wie einer Token-ID und einer Benutzer-ID. Intern verfügt Zitadel über zwei verschiedene Versionen von Token-Payloads. v1-Tokens werden nicht mehr erstellt, aber weiterhin überprüft, um zu verhindern, dass bestehende Sitzungen nach einem Upgrade ungültig werden. Der Klartext-Payload hat das Format `<token_id>:<user_id>`. v2-Tokens unterscheiden sich weiter darin, dass die `token_id` das Format `v2_<oidc_session_id>-at_<access_token_id>` aufweist. Die authZ/N-Sitzungsdaten für v1-Tokens werden aus der Datenbank unter Verwendung des (einfachen) `token_id`-Werts und des `user_id`-Werts abgerufen. Die `user_id` (in einigen Teilen unseres Codes als `subject` bezeichnet) wurde als vertrauenswürdige Benutzer-ID verwendet. Die authZ/N-Sitzungsdaten für v2-Tokens werden aus der Datenbank unter Verwendung der `oidc_session_id` und der `access_token_id` abgerufen; in diesem Fall wird die `user_id` aus dem Token ignoriert und aus den Sitzungsdaten in der Datenbank übernommen. Durch das Abschneiden des Tokens auf 80 Zeichen fehlt die user_id nun im Klartext des v2-Tokens. Der Back-End-Server akzeptiert dies aus den oben genannten Gründen weiterhin. Dieses Problem gilt nicht als ausnutzbar, kann bei der Reproduktion jedoch seltsam wirken. Der Patch in den Versionen 4.11.0 und 3.4.7 behebt das Problem, indem die `user_id` aus dem Token gegen die Sitzungsdaten aus der Datenbank überprüft wird. Es sind keine bekannten Workarounds verfügbar.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.