CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
5504 vulnerabilities reference this CWE, most recent first.
GHSA-XQ44-WCJX-G3W9
Vulnerability from github – Published: 2024-11-19 00:32 – Updated: 2025-10-22 00:33Vulnerability in the Oracle Agile PLM Framework product of Oracle Supply Chain (component: Software Development Kit, Process Extension). The supported version that is affected is 9.3.6. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Agile PLM Framework. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Agile PLM Framework accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).
{
"affected": [],
"aliases": [
"CVE-2024-21287"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-18T22:15:05Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle Agile PLM Framework product of Oracle Supply Chain (component: Software Development Kit, Process Extension). The supported version that is affected is 9.3.6. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Agile PLM Framework. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Agile PLM Framework accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).",
"id": "GHSA-xq44-wcjx-g3w9",
"modified": "2025-10-22T00:33:11Z",
"published": "2024-11-19T00:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21287"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-21287"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/alert-cve-2024-21287.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQ89-553H-3J4M
Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-07-13 00:01In all versions of GitLab CE/EE since version 8.0, access tokens created as part of admin's impersonation of a user are not cleared at the end of impersonation which may lead to unnecessary sensitive info disclosure.
{
"affected": [],
"aliases": [
"CVE-2021-39891"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-05T14:15:00Z",
"severity": "MODERATE"
},
"details": "In all versions of GitLab CE/EE since version 8.0, access tokens created as part of admin\u0027s impersonation of a user are not cleared at the end of impersonation which may lead to unnecessary sensitive info disclosure.",
"id": "GHSA-xq89-553h-3j4m",
"modified": "2022-07-13T00:01:38Z",
"published": "2022-05-24T19:16:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39891"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-39891.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/335137"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQ8M-7C5P-C2R6
Vulnerability from github – Published: 2026-04-21 15:21 – Updated: 2026-04-21 15:21Description
In affected versions of the Next.js SDK, simultaneous requests that trigger a nonce retry may cause the proxy cache fetcher to perform improper lookups for the token request results.
Which Projects are Affected?
Users are affected if they meet all of the following preconditions: - Applications using the auth0/nextjs-auth0 SDK, versions 4.12.0 to 4.17.0, and - Applications using the proxy handler /me/ and /my-org/ with DPoP enabled.
Affected product and versions
Auth0/nextjs-auth0 v4.12.0 to 4.17.0
Resolution
Upgrade Auth0/nextjs-auth0 version to v4.18.0 or greater
Acknowledgements
Okta would like to thank Reynaldo Immanuel for their discovery and responsible disclosure.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.17.0"
},
"package": {
"ecosystem": "npm",
"name": "@auth0/nextjs-auth0"
},
"ranges": [
{
"events": [
{
"introduced": "4.12.0"
},
{
"fixed": "4.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40155"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-21T15:21:46Z",
"nvd_published_at": "2026-04-17T21:16:33Z",
"severity": "MODERATE"
},
"details": "### Description\nIn affected versions of the Next.js SDK, simultaneous requests that trigger a nonce retry may cause the proxy cache fetcher to perform improper lookups for the token request results.\n\n### Which Projects are Affected?\nUsers are affected if they meet all of the following preconditions:\n- Applications using the auth0/nextjs-auth0 SDK, versions 4.12.0 to 4.17.0, and\n- Applications using the proxy handler /me/* and /my-org/* with DPoP enabled.\n\n\n### Affected product and versions\nAuth0/nextjs-auth0 v4.12.0 to 4.17.0\n\n### Resolution\nUpgrade Auth0/nextjs-auth0 version to v4.18.0 or greater\n\n### Acknowledgements\nOkta would like to thank Reynaldo Immanuel for their discovery and responsible disclosure.",
"id": "GHSA-xq8m-7c5p-c2r6",
"modified": "2026-04-21T15:21:46Z",
"published": "2026-04-21T15:21:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/nextjs-auth0/security/advisories/GHSA-xq8m-7c5p-c2r6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40155"
},
{
"type": "WEB",
"url": "https://github.com/auth0/nextjs-auth0/commit/98c36dc306970c2230ea1a32efef431d29b99978"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/nextjs-auth0"
},
{
"type": "WEB",
"url": "https://github.com/auth0/nextjs-auth0/releases/tag/v4.18.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Auth0 Next.js SDK has Improper Proxy Cache Lookup"
}
GHSA-XQHM-WM3P-7WV9
Vulnerability from github – Published: 2024-08-13 12:30 – Updated: 2024-08-13 12:30Incorrect Authorization vulnerability in WPWeb Docket (WooCommerce Collections / Wishlist / Watchlist) allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Docket (WooCommerce Collections / Wishlist / Watchlist): from n/a before 1.7.0.
{
"affected": [],
"aliases": [
"CVE-2024-43131"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T11:15:18Z",
"severity": "HIGH"
},
"details": "Incorrect Authorization vulnerability in WPWeb Docket (WooCommerce Collections / Wishlist / Watchlist) allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Docket (WooCommerce Collections / Wishlist / Watchlist): from n/a before 1.7.0.",
"id": "GHSA-xqhm-wm3p-7wv9",
"modified": "2024-08-13T12:30:53Z",
"published": "2024-08-13T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43131"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/woocommerce-collections/wordpress-docket-woocommerce-collections-wishlist-watchlist-plugin-1-6-6-unauthenticated-arbitrary-post-page-deletion-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XQQX-3G3G-99GR
Vulnerability from github – Published: 2024-03-17 09:30 – Updated: 2024-03-17 09:30A vulnerability was found in kishor-23 Food Waste Management System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/admin.php. The manipulation leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257056. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-2557"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-17T09:15:07Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in kishor-23 Food Waste Management System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file /admin/admin.php. The manipulation leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257056. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-xqqx-3g3g-99gr",
"modified": "2024-03-17T09:30:45Z",
"published": "2024-03-17T09:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2557"
},
{
"type": "WEB",
"url": "https://github.com/vanitashtml/CVE-Dumps/blob/main/Execute%20After%20Redirect%20-%20Food%20Management%20System.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.257056"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.257056"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQVX-2258-GFP2
Vulnerability from github – Published: 2023-12-05 03:30 – Updated: 2023-12-05 03:30Improper authorization verification vulnerability in AR Emoji prior to SMR Dec-2023 Release 1 allows attackers to read sandbox data of AR Emoji.
{
"affected": [],
"aliases": [
"CVE-2023-42569"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T03:15:17Z",
"severity": "MODERATE"
},
"details": "Improper authorization verification vulnerability in AR Emoji prior to SMR Dec-2023 Release 1 allows attackers to read sandbox data of AR Emoji.",
"id": "GHSA-xqvx-2258-gfp2",
"modified": "2023-12-05T03:30:23Z",
"published": "2023-12-05T03:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42569"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2023\u0026month=12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQWW-45WW-CW2P
Vulnerability from github – Published: 2024-11-04 15:31 – Updated: 2024-11-06 18:31Akamai SIA (Secure Internet Access Enterprise) ThreatAvert, in SPS (Security and Personalization Services) before the latest 19.2.0 patch and Apps Portal before 19.2.0.3 or 19.2.0.20240814, has incorrect authorization controls for the Admin functionality on the ThreatAvert Policy page. An authenticated user can navigate directly to the /#app/intelligence/threatAvertPolicies URI and disable policy enforcement.
{
"affected": [],
"aliases": [
"CVE-2024-45164"
],
"database_specific": {
"cwe_ids": [
"CWE-732",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-04T14:15:14Z",
"severity": "HIGH"
},
"details": "Akamai SIA (Secure Internet Access Enterprise) ThreatAvert, in SPS (Security and Personalization Services) before the latest 19.2.0 patch and Apps Portal before 19.2.0.3 or 19.2.0.20240814, has incorrect authorization controls for the Admin functionality on the ThreatAvert Policy page. An authenticated user can navigate directly to the /#app/intelligence/threatAvertPolicies URI and disable policy enforcement.",
"id": "GHSA-xqww-45ww-cw2p",
"modified": "2024-11-06T18:31:05Z",
"published": "2024-11-04T15:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45164"
},
{
"type": "WEB",
"url": "https://notes.netbytesec.com/2024/11/cve-2024-45164-broken-access-control.html"
},
{
"type": "WEB",
"url": "https://www.akamai.com/global-services/support/vulnerability-reporting"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XQXC-X6P3-W683
Vulnerability from github – Published: 2025-06-04 21:13 – Updated: 2025-07-02 18:29Summary
deno run --allow-read --deny-read main.ts results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as --allow-* --deny-*.
Details
Caused by the fast exit logic in #22894.
PoC
Run the above command expecting no permissions to be passed.
Impact
This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "deno"
},
"ranges": [
{
"events": [
{
"introduced": "1.41.3"
},
{
"fixed": "2.1.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "deno"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "deno"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "deno_runtime"
},
"ranges": [
{
"events": [
{
"introduced": "0.150.0"
},
{
"fixed": "0.212.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-48888"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-04T21:13:44Z",
"nvd_published_at": "2025-06-04T20:15:23Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`deno run --allow-read --deny-read main.ts` results in allowed, even though \u0027deny\u0027 should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`.\n\n### Details\n\nCaused by the fast exit logic in #22894.\n\n### PoC\n\nRun the above command expecting no permissions to be passed.\n\n### Impact\n\nThis only affects a nonsensical combination of flags, so there shouldn\u0027t be a real impact on the userbase.",
"id": "GHSA-xqxc-x6p3-w683",
"modified": "2025-07-02T18:29:57Z",
"published": "2025-06-04T21:13:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/denoland/deno/security/advisories/GHSA-xqxc-x6p3-w683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48888"
},
{
"type": "WEB",
"url": "https://github.com/denoland/deno/pull/22894"
},
{
"type": "WEB",
"url": "https://github.com/denoland/deno/pull/29213"
},
{
"type": "WEB",
"url": "https://github.com/denoland/deno/commit/2f0fae9d9071dcaf0a689bc7097584b1b9ebc8db"
},
{
"type": "WEB",
"url": "https://github.com/denoland/deno/commit/9d665572d3cd39f997e29e6daac7c1102fc5c04f"
},
{
"type": "WEB",
"url": "https://github.com/denoland/deno/commit/ef315b56c26c9ef5f25284a5100d2ed525a148cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/denoland/deno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Deno run with --allow-read and --deny-read flags results in allowed"
}
GHSA-XQXV-4JC2-X56X
Vulnerability from github – Published: 2026-06-18 13:52 – Updated: 2026-07-15 21:51Summary
Zitadel's OAuth2 / OIDC CodeExchange and RefreshToken implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.
Impact
This flaw creates potential vulnerabilities in two main authentication phases, provided specific external preconditions are met:
- Authorization Code Injection: An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (
ClientB) registered on the same Zitadel instance. Zitadel will authenticateClientBand issue tokens for the victim user without verifying the client binding. - Refresh Token Cross-Use: An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token's format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.
- Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.
Scope and Mitigation Factors:
- External Preconditions: It is critical to note that exploiting either vector requires a pre-existing vulnerability or data leak within the target application environment to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.
- Multi-tenant risk: On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant's clients if they are successfully intercepted.
- PKCE protection: Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the
code_verifier. However, PKCE does not protect against refresh token cross-use.
Affected Versions
Systems running one of the following versions are affected:
- 4.x:
4.0.0through4.15.1(including RC versions) - 3.x:
3.0.0through3.4.11(including RC versions)
Patches
The vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the CodeExchange and RefreshToken grants.
Please upgrade to one of the following secure versions:
Workarounds
The recommended solution is to upgrade to a patched version.
To reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of PKCE for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to kodareef5, Shubham Raj / Causal Security, and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/zitadel/zitadel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.80.0-v2.20.0.20260616131956-0973b074b488"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55672"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:52:18Z",
"nvd_published_at": "2026-07-10T18:16:23Z",
"severity": "HIGH"
},
"details": "### Summary\n\nZitadel\u0027s OAuth2 / OIDC `CodeExchange` and `RefreshToken` implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.\n\n### Impact\n\nThis flaw creates potential vulnerabilities in two main authentication phases, **provided specific external preconditions are met**:\n\n* **Authorization Code Injection:** An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (`ClientB`) registered on the same Zitadel instance. Zitadel will authenticate `ClientB` and issue tokens for the victim user without verifying the client binding.\n* **Refresh Token Cross-Use:** An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token\u0027s format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.\n* Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.\n\n**Scope and Mitigation Factors:**\n\n* **External Preconditions:** It is critical to note that exploiting either vector **requires a pre-existing vulnerability or data leak within the target application environment** to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.\n* **Multi-tenant risk:** On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant\u0027s clients if they are successfully intercepted.\n* **PKCE protection:** Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the `code_verifier`. However, PKCE does not protect against refresh token cross-use.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n\n* **4.x:** `4.0.0` through `4.15.1` (including RC versions)\n* **3.x:** `3.0.0` through `3.4.11` (including RC versions)\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the `CodeExchange` and `RefreshToken` grants.\n\nPlease upgrade to one of the following secure versions:\n\n- **4.x**: Upgrade to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n- **3.x**: Update to $\\ge$[3.4.12](https://github.com/zitadel/zitadel/releases/tag/v3.4.12)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version.\n\nTo reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of **PKCE** for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to [kodareef5](https://github.com/kodareef5), Shubham Raj / [Causal Security](https://causalsecurity.com/), and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.",
"id": "GHSA-xqxv-4jc2-x56x",
"modified": "2026-07-15T21:51:58Z",
"published": "2026-06-18T13:52:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-xqxv-4jc2-x56x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55672"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/commit/0973b074b48816757c47fe732b06d2488d3d284c"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/commit/562403079a98cf2059cdac11865a45e2f285be71"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/commit/5b1708e0e650398f0ebc3341714f0798b0118917"
},
{
"type": "PACKAGE",
"url": "https://github.com/zitadel/zitadel"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/releases/tag/v3.4.12"
},
{
"type": "WEB",
"url": "https://github.com/zitadel/zitadel/releases/tag/v4.15.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": " ZITADEL: Missing client_id binding in OIDC authorization code exchange and refresh token flows (RFC 6749 Section 4.1.3 violation)"
}
GHSA-XR38-W74Q-R8JV
Vulnerability from github – Published: 2021-12-06 23:57 – Updated: 2024-09-23 16:02Impact
Invenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. cannot change a record from restricted to public.
Details
The service's publish() method contains the following permission check:
def publish(..):
self.require_permission(identity, "publish")
However, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner.
def publish(..):
self.require_permission(identity, "publish", record=record)
The bug is activated in Invenio-RDM-Records which has a need generator called RecordOwners(), which when no record is passed in defaults to allow any authenticated user:
class RecordOwners(Generator):
def needs(self, record=None, **kwargs):
if record is None:
return [authenticated_user]
# ...
Patches
The problem is patched in Invenio-Drafts-Resources v0.13.7 and 0.14.6+, which is part of InvenioRDM v6.0.1 and InvenioRDM v7.0 respectively.
You can verify the version installed of Invenio-Drafts-Resources via PIP:
cd ~/src/my-site
pipenv run pip freeze | grep invenio-drafts-resources
References
For more information
If you have any questions or comments about this advisory: * Chat with us on Discord: https://discord.gg/8qatqBC
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-drafts-resources"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.13.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-app-rdm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-rdm-records"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.32.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-drafts-resources"
},
"ranges": [
{
"events": [
{
"introduced": "0.14.0"
},
{
"fixed": "0.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-rdm-records"
},
"ranges": [
{
"events": [
{
"introduced": "0.33.0"
},
{
"fixed": "0.33.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "invenio-app-rdm"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0.dev0"
},
{
"fixed": "7.0.0.dev5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-43781"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-12-06T22:15:02Z",
"nvd_published_at": "2021-12-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nInvenio-Drafts-Resources does not properly check permissions when a record is published. The vulnerability is exploitable in a default installation of InvenioRDM. An authenticated user is able via REST API calls to publish draft records of other users if they know the record identifier and the draft validates (e.g. all require fields filled out). An attacker is not able to modify the data in the record, and thus e.g. *cannot* change a record from restricted to public.\n\n### Details\n\nThe service\u0027s ``publish()`` method contains the following permission check:\n\n```python\ndef publish(..):\n self.require_permission(identity, \"publish\")\n```\nHowever, the record should have been passed into the permission check so that the need generators have access to e.g. the record owner.\n\n```python\ndef publish(..):\n self.require_permission(identity, \"publish\", record=record)\n```\nThe bug is activated in Invenio-RDM-Records which has a need generator called ``RecordOwners()``, which when no record is passed in defaults to allow any authenticated user:\n\n```python\nclass RecordOwners(Generator):\n def needs(self, record=None, **kwargs):\n if record is None:\n return [authenticated_user]\n # ...\n```\n\n### Patches\n\nThe problem is patched in Invenio-Drafts-Resources v0.13.7 and 0.14.6+, which is part of InvenioRDM v6.0.1 and InvenioRDM v7.0 respectively.\n\nYou can verify the version installed of Invenio-Drafts-Resources via PIP:\n\n```console\ncd ~/src/my-site\npipenv run pip freeze | grep invenio-drafts-resources\n```\n\n### References\n\n- [Security policy](https://invenio.readthedocs.io/en/latest/community/security-policy.html)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Chat with us on Discord: https://discord.gg/8qatqBC\n\n",
"id": "GHSA-xr38-w74q-r8jv",
"modified": "2024-09-23T16:02:05Z",
"published": "2021-12-06T23:57:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/inveniosoftware/invenio-drafts-resources/security/advisories/GHSA-xr38-w74q-r8jv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43781"
},
{
"type": "WEB",
"url": "https://github.com/inveniosoftware/invenio-drafts-resources/commit/039b0cff1ad4b952000f4d8c3a93f347108b6626"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-app-rdm/PYSEC-2021-837.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-drafts-resources/PYSEC-2021-836.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Permissions not properly checked in Invenio-Drafts-Resources"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.