CVE-2026-27840
ZITADEL is an open source identity management platform. Starting in version 2.31.0 and prior to versions 3.4.7 and 4.11.0, opaque OIDC access tokens in the v2 format truncated to 80 characters are still considered valid. Zitadel uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade. The cleartext payload has a format of <token_id>:<user_id>. v2 tokens distinguished further where the token_id is of the format v2_<oidc_session_id>-at_<access_token_id>. V1 token authZ/N session data is retrieved from the database using the (simple) token_id value and user_id value. The user_id (called subject in some parts of our code) was used as being the trusted user ID. V2 token authZ/N session data is retrieved from the database using the oidc_session_id and access_token_id and in this case the user_id from the token is ignored and taken from the session data in the database. By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token. The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. The patch in versions 4.11.0 and 3.4.7 resolves the issue by verifying the user_id from the token against the session data from the database. No known workarounds are available.
| Software | From | Fixed in |
|---|---|---|
github.com/zitadel/zitadel
|
4.0.0 | 4.11.0 |
|
github.com/zitadel/zitadel
|
3.0.0 | 3.4.7 |
|
github.com/zitadel/zitadel
|
2.31.0 | 2.71.19.x |
|
github.com/zitadel/zitadel
|
- | 1.80.0-v2.20.0.20260216092519-feab8e1fa371 |
| zitadel / zitadel | 2.31.0 | 2.71.19.x |
| zitadel / zitadel | 3.0.0 | 3.4.7 |
| zitadel / zitadel | 4.0.0 | 4.11.0 |
- https://github.com/zitadel/zitadel/commit/feab8e1fa371f3ad654640fc869b2c14f2fdb602
- https://github.com/zitadel/zitadel/releases/tag/v2.71.19
- https://github.com/zitadel/zitadel/releases/tag/v3.4.7
- https://github.com/zitadel/zitadel/releases/tag/v4.11.0
- https://github.com/zitadel/zitadel/security/advisories/GHSA-6mq3-xmgp-pjm5
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.