# CVE-2026-27840: zitadel — Fixed in 4.11.0 🐹 🐹 Go Not in CISA KEV MEDIUM severity # CVE-2026-27840 — zitadel MEDIUM [Fix: zitadel/zitadel@feab8e1](https://github.com/zitadel/zitadel/commit/feab8e1fa371f3ad654640fc869b2c14f2fdb602) CVE-2026-27840 is a medium-severity (CVSS 4.3) CWE-302 vulnerability in github.com/zitadel/zitadel. A fix is available for github.com/zitadel/zitadel — see the affected versions and patch details below. ZITADEL's truncated opaque tokens are still valid Also known as[GHSA-6mq3-xmgp-pjm5](/vulnerability/GHSA-6mq3-xmgp-pjm5)GO-2026-4573 Published Feb 26, 2026 Updated Oct 28, 2026 Affected 4 pkgs Patched 3 / 4 Exploits None indexed Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### No confirmed exploitation observed yet - CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27840. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.2%probability of exploitation in next 30 days Lower Risk0.00% Lower risk than most CVEs5th percentile — riskier than 5% of all scored CVEsHighest risk 0.00%0.24%0.49%0.73%0.0%0.2%May 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 4 pkgs affected 🐹`github.com/zitadel/zitadel`🐹`github.com/zitadel/zitadel`🐹`github.com/zitadel/zitadel`🐹`github.com/zitadel/zitadel` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems. ## Description #### Summary Opaque OIDC access tokens in 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 `:`. v2 tokens distinguished further where the `token_id` is of the format `v2_-at_`. This is an example of such a cleartext: `V2_354201447279099906-at_354201447279165442:354201364702363650` #### Impact 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: `V2_354201447279099906-at_354201447279165442:` The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. #### Affected Versions All versions within the following ranges, including release candidates (RCs), are affected: - **v4.x**: `4.0.0` through `4.10.1` - **3.x**: `3.0.0` through `3.4.6` - **2.x**: `2.31.0` through `2.71.19` #### Patches The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the `user_id` from the token against the session data from the database 4.x: Upgrade to >=[4.11.0](https://github.com/zitadel/zitadel/releases/tag/v4.11.0) 3.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7) 2.x: Update to >=[3.4.7](https://github.com/zitadel/zitadel/releases/tag/v3.4.7) #### Workarounds The recommended solution is to update ZITADEL to a patched version. #### Questions If there any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com) #### Credits ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability. ## Affected Packages 4 total 3 fixed Ecosystem Package Vulnerable range Fix 🐹Go `github.com/zitadel/zitadel` ≥ 4.0.0&&< 4.11.0 4.11.0`go get github.com/zitadel/zitadel@v4.11.0` 🐹Go `github.com/zitadel/zitadel` ≥ 3.0.0&&< 3.4.7 3.4.7`go get github.com/zitadel/zitadel@v3.4.7` 🐹Go `github.com/zitadel/zitadel` ≥ 2.31.0 No fix 🐹Go `github.com/zitadel/zitadel` all versions 1.80.0-v2.20.0.20260216092519-feab8e1fa371`go get github.com/zitadel/zitadel@v1.80.0-v2.20.0.20260216092519-feab8e1fa371` ## Affected Products 1 product · 3 configurations Application `zitadel`zitadel ≥ 4.0.0 && ≤ 2.71.19 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/zitadel/zitadel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update github.com/zitadel/zitadel to 4.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27840 is resolved across your whole dependency graph. 3. ### Workarounds If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands. ## Frequently Asked Questions \### Summary Opaque OIDC access tokens in 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 \`:\`. v2 tokens distinguished further where the \`token\_id\` is of the format \`v2\_-at\_ O3 Security · Impact-Aware SCA ### Is CVE-2026-27840 in your dependencies? Find it across Go, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)