Every CVE Search/ Get API key

CVE-2026-27840

ZITADEL's truncated opaque tokens are still valid

4.3 MediumFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
Required

What an attacker can affect

Confidentiality
None
Integrity
Low
Availability
None

Exploit likelihood

0.16%Up 0.1 points since Feb 26, 2026
90%50%10%1%

What each source reports

CVE List Score used 4.3

ZITADEL's truncated opaque tokens are still valid

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.

Record
CVE-2026-27840
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Weakness
CWE-302
Updated
2026-11-02
EUVDEUVD-2026-8789 4.3

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.

Record
EUVD-2026-8789
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-6mq3-xmgp-pjm5 4.3

ZITADEL's truncated opaque tokens are still valid

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 <token_id>:<user_id>. v2 tokens distinguished further where the token_id is of the format v2_<oidc_session_id>-at_<access_token_id>. 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 3.x: Update to >=3.4.7 2.x: Update to >=3.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 [email protected]

Credits

ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.

Record
GHSA-6mq3-xmgp-pjm5
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Weakness
CWE-302
Updated
2026-11-02
NVD 4.3

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.

Record
CVE-2026-27840
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Weakness
CWE-302
Updated
2026-11-02
OSV 4.3

ZITADEL's truncated opaque tokens are still valid

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.

Record
CVE-2026-27840
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Weakness
CWE-302
Updated
2026-11-02
OSVGHSA-6mq3-xmgp-pjm5 4.3

ZITADEL's truncated opaque tokens are still valid

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 <token_id>:<user_id>. v2 tokens distinguished further where the token_id is of the format v2_<oidc_session_id>-at_<access_token_id>. 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 3.x: Update to >=3.4.7 2.x: Update to >=3.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 [email protected]

Credits

ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.

Record
GHSA-6mq3-xmgp-pjm5
CVSS 3.1
4.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Weakness
CWE-302
Updated
2026-11-02
OSVGO-2026-4573 No score

ZITADEL's truncated opaque tokens are still valid in github.com/zitadel/zitadel

ZITADEL's truncated opaque tokens are still valid in github.com/zitadel/zitadel.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The additional affected modules and versions are: github.com/zitadel/zitadel from v3.0.0 before v3.4.7; github.com/zitadel/zitadel from v4.0.0 before v4.11.0.

Record
GO-2026-4573
Updated
2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
  • GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
  • GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
  • GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
  • GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
  • GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
  • GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
  • GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
  • GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
  • GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
  • GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
  • GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
  • GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
  • GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
  • GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
  • GO-2026-5933 GHSA-3g4q-2f67-2gvh
  • GO-2026-5934 GHSA-59qp-cfj3-rp64
  • GO-2026-5935 GHSA-7856-g3gv-9wq8
  • GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
  • GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
  • GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
  • GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
  • GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
  • GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
  • GO-2026-5942 CVE-2026-46600
  • GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
  • GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
  • GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
  • GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
  • GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
  • GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
  • GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
  • GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
  • GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
  • GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
  • GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
  • GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
  • GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
  • GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
  • GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
  • GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
  • GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
  • GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
  • GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
  • GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
  • GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
  • GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
  • GO-2026-5969 GHSA-g936-7jqj-mwv8
  • GO-2026-5970 CVE-2026-56852
  • GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
  • GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
  • GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
  • GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
  • GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
  • GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
  • GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
  • GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
  • GO-2026-5981 GHSA-mqxv-9rm6-w8qc
  • GO-2026-5982 GHSA-pqg7-v6wh-3pfp
  • GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
  • GO-2026-5985 GHSA-7rx3-5wx3-5v76
  • GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
  • GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
  • GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
  • GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
  • GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
  • GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
  • GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
  • GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
  • GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
  • GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
  • GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
  • GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
  • GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
  • GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
  • GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
  • GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
Record
openSUSE-SU-2026:21483-1
Updated
2026-11-02
OSVSUSE-SU-2026:1042-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260317T205859 2026-03-17T20:58:59Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:
    • GO-2026-4360 CVE-2026-0528 GHSA-w2gr-585j-r428
    • GO-2026-4513
    • GO-2026-4514
    • GO-2026-4518
    • GO-2026-4526
    • GO-2026-4549 CVE-2026-24005 GHSA-9fj4-3849-rv9g
    • GO-2026-4550 CVE-2026-1229 GHSA-q9hv-hpm4-hj6x
    • GO-2026-4551 CVE-2026-27575 GHSA-3ccg-x393-96v8
    • GO-2026-4552 CVE-2026-27116 GHSA-4qgr-4h56-8895
    • GO-2026-4553 CVE-2026-27616 GHSA-7jp5-298q-jg98
    • GO-2026-4554 CVE-2026-27730 GHSA-p2v6-84h2-5x4r
    • GO-2026-4556 CVE-2026-27819 GHSA-42wg-38gx-85rh
    • GO-2026-4557 CVE-2026-26186 GHSA-49xw-vfc4-7p43
    • GO-2026-4558 CVE-2026-27808 GHSA-mpf7-p9x7-96r3
    • GO-2026-4560 CVE-2026-27465 GHSA-2v6m-6xw3-6467
    • GO-2026-4561 CVE-2026-25963 GHSA-5jvp-m9h4-253h
    • GO-2026-4562 CVE-2026-27900 GHSA-5rc7-2jj6-mp64
    • GO-2026-4563 CVE-2026-24004 GHSA-9pm7-6g36-6j78
    • GO-2026-4564 CVE-2026-23999 GHSA-ppwx-5jq7-px2w
    • GO-2026-4565 CVE-2026-22728 GHSA-465p-v42x-3fmj
    • GO-2026-4566 CVE-2026-27899 GHSA-5rmx-256w-8mj9
    • GO-2026-4567 CVE-2026-27965 GHSA-8g8j-r87h-p36x
    • GO-2026-4568 GHSA-gj6x-q8rh-wj6x
    • GO-2026-4569 CVE-2026-27896 GHSA-wvj2-96wp-fq3f
    • GO-2026-4570 CVE-2026-27969 GHSA-r492-hjgh-c9gw
    • GO-2026-4571 CVE-2026-27734 GHSA-phwh-4f42-gwf3
    • GO-2026-4572 CVE-2026-27946 GHSA-282g-fhmx-xf54
    • GO-2026-4573 CVE-2026-27840 GHSA-6mq3-xmgp-pjm5
    • GO-2026-4574 CVE-2026-27945 GHSA-7777-fhq9-592v
    • GO-2026-4575 CVE-2026-28268 GHSA-rfjg-6m84-crj2
    • GO-2026-4576 CVE-2026-28280 GHSA-4rv8-5cmm-2r22
    • GO-2026-4577 CVE-2026-28407 GHSA-945p-3jhm-6rcp
    • GO-2026-4578 CVE-2025-14443 GHSA-gxvv-45f6-3ch8
    • GO-2026-4579 CVE-2026-28279 GHSA-rchw-322g-f7rm
    • GO-2026-4580 CVE-2026-28406 GHSA-6rxq-q92g-4rmf
    • GO-2026-4581 GHSA-xfx2-prg5-jq3g
    • GO-2026-4583 GHSA-54p8-x2m9-c593
    • GO-2026-4584 CVE-2026-28342 GHSA-pc8g-78pf-4xrp
    • GO-2026-4585 CVE-2026-28492 GHSA-mr74-928f-rw69
    • GO-2026-4586 CVE-2026-28789 GHSA-45m3-398w-m2m9
    • GO-2026-4587 CVE-2026-28790 GHSA-4fqm-6fmh-82mq
    • GO-2026-4588 CVE-2026-29049 GHSA-7rp8-r62p-q6wc
    • GO-2026-4589 CVE-2021-25320 GHSA-gqf8-rvrh-g7w6
    • GO-2026-4590 GHSA-hwm2-4ph6-w6m5
    • GO-2026-4591 CVE-2025-62879 GHSA-wj3p-5h3x-c74q
    • GO-2026-4592 CVE-2026-29073 GHSA-jqwg-75qf-vmf9
    • GO-2026-4593 CVE-2026-26998 GHSA-fw45-f5q2-2p4x
    • GO-2026-4594 CVE-2026-26999 GHSA-xw98-5q62-jx94
    • GO-2026-4595 CVE-2026-3351 GHSA-crmg-9m86-636r
    • GO-2026-4596 CVE-2026-29183 GHSA-6865-qjcf-286f
    • GO-2026-4597 CVE-2026-29054 GHSA-92mv-8f8w-wq52
    • GO-2026-4598 CVE-2026-29042 GHSA-95fj-3w7g-4r27
    • GO-2026-4599 CVE-2026-27137
    • GO-2026-4600 CVE-2026-27138
    • GO-2026-4601 CVE-2026-25679
    • GO-2026-4602 CVE-2026-27139
    • GO-2026-4603 CVE-2026-27142
    • GO-2026-4604 CVE-2026-29193 GHSA-25rw-g6ff-fmg8
    • GO-2026-4605 CVE-2026-29192 GHSA-6rx5-m2rc-hmf7
    • GO-2026-4606 CVE-2026-29188 GHSA-79pf-vx4x-7jmm
    • GO-2026-4607 CVE-2026-29191 GHSA-pr34-2v5x-6qjq
    • GO-2026-4608 CVE-2026-29771 GHSA-rhr9-hgcm-x289
    • GO-2026-4609 CVE-2026-29781 GHSA-hx52-cv84-jr5v
    • GO-2026-4610 CVE-2025-15558 GHSA-p436-gjf2-799p
    • GO-2026-4612 CVE-2026-28683 GHSA-3c22-5j5m-4jq7
    • GO-2026-4613 CVE-2026-28682 GHSA-c36c-7pc2-f2ph
    • GO-2026-4614 CVE-2026-27944 GHSA-g9w5-qffc-6762
    • GO-2026-4615 CVE-2026-29060 GHSA-m2hx-wjxc-9fp4
    • GO-2026-4616 CVE-2026-25921 GHSA-cj4v-437j-jq4c
    • GO-2026-4617 CVE-2026-26194 GHSA-v9vm-r24h-6rqm
    • GO-2026-4618 CVE-2026-26195 GHSA-vgvf-m4fw-938j
    • GO-2026-4619 CVE-2026-26196 GHSA-x9p5-w45c-7ffc
    • GO-2026-4620 CVE-2026-26022 GHSA-xrcr-gmf5-2r8j
    • GO-2026-4621 GHSA-fwhj-785h-43hh
    • GO-2026-4622 CVE-2026-30223 GHSA-g962-2j28-3cg9
    • GO-2026-4623 CVE-2026-30224 GHSA-gq2m-77hf-vwgh
    • GO-2026-4624 CVE-2026-29084 GHSA-hcff-qv74-7hr4
    • GO-2026-4625 CVE-2026-30225 GHSA-p443-p7w5-2f7f
    • GO-2026-4626 CVE-2026-29061…
Record
SUSE-SU-2026:1042-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/zitadel/zitadel
Go
 4.0.0 up to 4.11.0
4.11.0
github.com/zitadel/zitadel
Go
 3.0.0 up to 3.4.7
3.4.7
github.com/zitadel/zitadel
Go
 2.31.0 to 2.71.19 None known
github.com/zitadel/zitadel
Go
 before 1.80.0-v2.20.0.20260216092519-feab8e1fa371
1.80.0-v2.20.0.20260216092519-feab8e1fa371
github.com/zitadel/zitadel
Go
 All versions None known
govulncheck-vulndb
openSUSE:Leap 15.6
From an advisory covering 124 CVEs
 before 0.0.20260317T205859-150000.1.152.1
0.0.20260317T205859-150000.1.152.1
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 1734 CVEs
 before 0.0.20260723T184607-160000.1.1
0.0.20260723T184607-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-27840 is a medium vulnerability (CVSS 4.3) in Zitadel, published February 26, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.16%, the 5th percentile. Fixed in github.com/zitadel/zitadel 4.11.0.

References

Show 194 moreShow less
This page doesn't list everything

Left out here: 1,544 references and the rest of 2 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open