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.
5537 vulnerabilities reference this CWE, most recent first.
GHSA-W222-M46C-MGH6
Vulnerability from github – Published: 2025-04-30 16:43 – Updated: 2025-05-01 13:30Overview OpenFGA v1.8.10 or previous (Helm chart <= openfga-0.2.28, docker <= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.
Am I Affected? If you are using OpenFGA v1.8.10 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with an authorization model that has tuple cycle. - Check query cache is enabled, and - There are multiple check / list objects requests involving the tuple cycle within the check query TTL
Fix Upgrade to v1.8.11. This upgrade is backwards compatible.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openfga/openfga"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.6"
},
{
"fixed": "1.8.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46331"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-30T16:43:33Z",
"nvd_published_at": "2025-04-30T19:15:55Z",
"severity": "MODERATE"
},
"details": "Overview\nOpenFGA v1.8.10 or previous (Helm chart \u003c= openfga-0.2.28, docker \u003c= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.\n\nAm I Affected?\nIf you are using OpenFGA v1.8.10 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability:\n- Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has tuple cycle.\n- [Check query cache](https://github.com/openfga/openfga/blob/9b5974458b777707ed2a30ba6303699499e655ee/.config-schema.json#L528) is enabled, and\n- There are multiple check / list objects requests involving the tuple cycle within the check query TTL\n\nFix\nUpgrade to v1.8.11. This upgrade is backwards compatible.",
"id": "GHSA-w222-m46c-mgh6",
"modified": "2025-05-01T13:30:18Z",
"published": "2025-04-30T16:43:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openfga/openfga/security/advisories/GHSA-w222-m46c-mgh6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46331"
},
{
"type": "WEB",
"url": "https://github.com/openfga/openfga/commit/244302e7a8b979d66cc1874a3899cdff7d47862f"
},
{
"type": "PACKAGE",
"url": "https://github.com/openfga/openfga"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "OpenFGA Authorization Bypass"
}
GHSA-W248-FFJ2-4V5Q
Vulnerability from github – Published: 2022-06-09 23:47 – Updated: 2022-06-20 21:59Impact
Authorization headers on requests are sensitive information. On making a request using the https scheme to a server which responds with a redirect to a URI with the http scheme, we should not forward the Authorization header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, https to http downgrades did not result in the Authorization header being removed, only changes to the host.
Patches
Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.
Workarounds
An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.
References
For more information
If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "6.5.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31043"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-09T23:47:23Z",
"nvd_published_at": "2022-06-10T00:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`Authorization` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. This is much the same as to how we don\u0027t forward on the header if the host changes. Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host.\n\n### Patches\n\nAffected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.\n\n### Workarounds\n\nAn alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.\n\n### References\n\n* [RFC9110 Section 15.4](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx)\n\n### For more information\n\nIf you have any questions or comments about this advisory, please get in touch with us in `#guzzle` on the [PHP HTTP Slack](https://php-http.slack.com/). Do not report additional security advisories in that public channel, however - please follow our [vulnerability reporting process](https://github.com/guzzle/guzzle/security/policy).\n",
"id": "GHSA-w248-ffj2-4v5q",
"modified": "2022-06-20T21:59:37Z",
"published": "2022-06-09T23:47:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-w248-ffj2-4v5q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31043"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/commit/e3ff079b22820c2029d4c2a87796b6a0b8716ad8"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/guzzlehttp/guzzle/CVE-2022-31043.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/guzzle/guzzle"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5246"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-core-2022-011"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx"
}
],
"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"
}
],
"summary": "Fix failure to strip Authorization header on HTTP downgrade"
}
GHSA-W24R-5266-9C3C
Vulnerability from github – Published: 2026-04-30 18:20 – Updated: 2026-06-09 10:49Summary
has(), auth.protect(), and related authorization predicates in @clerk/shared, @clerk/nextjs, @clerk/backend, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions.
Sessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. clerkMiddleware continues to authenticate requests correctly, auth() reflects the real authentication state, and token verification is unaffected.
Who is affected
All apps that combine more than one authorization dimension in a single has() or auth.protect() call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade.
This call shape can be bypassed if certain conditions are met: a has() or auth.protect() call that combines a reverification check with any of role, permission, feature, or plan, or that combines a billing check (feature or plan) with a role or permission check.
// Reverification combined with role / permission / feature / plan
await auth.protect({ permission: 'org:settings:delete', reverification: 'strict' });
const canAct = has({ role: 'org:admin', reverification: 'strict' });
// Billing (feature / plan) combined with role / permission
const canAct = has({ permission: 'org:admin', feature: 'premium' });
Single-condition checks are not affected and continue to fail closed as expected:
await auth.protect({ permission: 'org:settings:delete' });
has({ reverification: 'strict' });
The callback form of auth.protect is not affected unless the callback itself invokes one of the affected shapes:
await auth.protect(has => has({ permission: 'org:X' }) && has({ reverification: 'strict' }));
App patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass.
@clerk/shared is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import createCheckAuthorization from @clerk/shared directly, their apps are also affected. Run npm why @clerk/shared (or the app's package manager's equivalent) to check the installed version.
Additional auth.protect() bypass
A second, related bypass lives in @clerk/nextjs: auth.protect() silently discarded authorization params (role, permission, feature, plan, reverification) whenever the same argument object also contained unauthenticatedUrl, unauthorizedUrl, or token.
Recommended actions
Upgrade to the latest patch release of the consuming app's framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the "Affected packages" section above for the exact vulnerable ranges and patched versions per package.
If a consuming app pins @clerk/clerk-js directly, upgrade it to the patched version. Most apps load @clerk/clerk-js from Clerk's CDN through their framework package and will receive the fix automatically, with no upgrade step required.
Workaround
If developers cannot upgrade immediately, split combined has() or auth.protect() calls into sequential single-condition checks:
// Replace
await auth.protect({ permission: 'org:X', reverification: 'strict' });
// With
await auth.protect({ reverification: 'strict' });
await auth.protect({ permission: 'org:X' });
Each single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result.
Timeline
This issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026.
Thanks to AISafe for the responsible disclosure of this vulnerability.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.47.4"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/shared"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.47.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.8.2"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/shared"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.8.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.33.2"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/backend"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.33.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2.13"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/backend"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.2.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.39.2"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/nextjs"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.39.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.2.3"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/nextjs"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.125.9"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/clerk-js"
},
"ranges": [
{
"events": [
{
"introduced": "5.22.0"
},
{
"fixed": "5.125.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.7.4"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/clerk-js"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.7.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.61.5"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/clerk-react"
},
"ranges": [
{
"events": [
{
"introduced": "5.9.0"
},
{
"fixed": "5.61.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.4.2"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/react"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.17.20"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/vue"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.17.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.15"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/vue"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.17.10"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/astro"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.17.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.17"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/astro"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.13.28"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/nuxt"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.13.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.4"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/nuxt"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.2.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.19.35"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/clerk-expo"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.11"
},
{
"fixed": "2.19.36"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2.1"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/expo"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.4.12"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/react-router"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.1"
},
{
"fixed": "2.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.3"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/react-router"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.29.10"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/tanstack-react-start"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.1"
},
{
"fixed": "0.29.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.3"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/tanstack-react-start"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.9.14"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/chrome-extension"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.5"
},
{
"fixed": "2.9.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.14"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/chrome-extension"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.30"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/fastify"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.42"
},
{
"fixed": "2.6.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.15"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/fastify"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.78"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/express"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "1.7.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.1.5"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/express"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.15"
},
"package": {
"ecosystem": "npm",
"name": "@clerk/hono"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.2"
},
{
"fixed": "0.1.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42349"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-30T18:20:02Z",
"nvd_published_at": "2026-05-11T17:16:33Z",
"severity": "HIGH"
},
"details": "### Summary\n\n`has()`, `auth.protect()`, and related authorization predicates in `@clerk/shared`, `@clerk/nextjs`, `@clerk/backend`, and other framework SDKs can return true for certain combined authorization checks when the result should be false, allowing a gated action to proceed for a user who does not satisfy the full set of requested conditions.\n\nSessions are not compromised and no existing user can be impersonated. The bypass is limited to the authorization decision returned by the predicate. `clerkMiddleware` continues to authenticate requests correctly, `auth()` reflects the real authentication state, and token verification is unaffected.\n\n### Who is affected\n\nAll apps that combine more than one authorization dimension in a single `has()` or `auth.protect()` call should upgrade to the patched versions. Patches are drop-in with no API changes. The information below describes the scope of the bypass and helps developers understand whether their apps are potentially affected, but is not a reason to delay the upgrade.\n\nThis call shape can be bypassed if certain conditions are met: a `has()` or `auth.protect()` call that combines a `reverification` check with any of `role`, `permission`, `feature`, or `plan`, or that combines a billing check (`feature` or `plan`) with a role or permission check.\n\n\n```ts\n// Reverification combined with role / permission / feature / plan\nawait auth.protect({ permission: \u0027org:settings:delete\u0027, reverification: \u0027strict\u0027 });\nconst canAct = has({ role: \u0027org:admin\u0027, reverification: \u0027strict\u0027 });\n\n// Billing (feature / plan) combined with role / permission\nconst canAct = has({ permission: \u0027org:admin\u0027, feature: \u0027premium\u0027 });\n```\n\nSingle-condition checks are not affected and continue to fail closed as expected:\n\n```ts\nawait auth.protect({ permission: \u0027org:settings:delete\u0027 });\nhas({ reverification: \u0027strict\u0027 });\n```\n\nThe callback form of `auth.protect` is not affected unless the callback itself invokes one of the affected shapes:\n\n```ts\nawait auth.protect(has =\u003e has({ permission: \u0027org:X\u0027 }) \u0026\u0026 has({ reverification: \u0027strict\u0027 }));\n```\n\nApp patterns that rely only on single-condition checks, or that combine them via the callback form, are unaffected. Authentication, session state, and token verification continue to work correctly regardless of this bypass.\n\n`@clerk/shared` is usually not imported directly in application code, but the fix lives there and reaches an app through its framework package. If developers import `createCheckAuthorization` from `@clerk/shared` directly, their apps are also affected. Run `npm why @clerk/shared` (or the app\u0027s package manager\u0027s equivalent) to check the installed version.\n\n### Additional `auth.protect()` bypass\n\nA second, related bypass lives in `@clerk/nextjs`: `auth.protect()` silently discarded authorization params (`role`, `permission`, `feature`, `plan`, `reverification`) whenever the same argument object also contained `unauthenticatedUrl`, `unauthorizedUrl`, or `token`.\n\n### Recommended actions\n\nUpgrade to the latest patch release of the consuming app\u0027s framework package on its current major. Both Core 2 and Core 3 release lines have patches. See the \"Affected packages\" section above for the exact vulnerable ranges and patched versions per package.\n\nIf a consuming app pins `@clerk/clerk-js` directly, upgrade it to the patched version. Most apps load `@clerk/clerk-js` from Clerk\u0027s CDN through their framework package and will receive the fix automatically, with no upgrade step required.\n\n### Workaround\n\nIf developers cannot upgrade immediately, split combined `has()` or `auth.protect()` calls into sequential single-condition checks:\n\n```ts\n// Replace\nawait auth.protect({ permission: \u0027org:X\u0027, reverification: \u0027strict\u0027 });\n// With\nawait auth.protect({ reverification: \u0027strict\u0027 });\nawait auth.protect({ permission: \u0027org:X\u0027 });\n```\n\nEach single-condition check fails closed as expected, so evaluating them independently and denying if either fails produces the correct result.\n\n### Timeline\n\nThis issue was reported on 18 APR 2026, patched on 22 APR 2026, and publicly disclosed on 22 APR 2026.\n\nThanks to AISafe for the responsible disclosure of this vulnerability.",
"id": "GHSA-w24r-5266-9c3c",
"modified": "2026-06-09T10:49:55Z",
"published": "2026-04-30T18:20:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/clerk/javascript/security/advisories/GHSA-w24r-5266-9c3c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42349"
},
{
"type": "PACKAGE",
"url": "https://github.com/clerk/javascript"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Clerk has an authorization bypass when combining organization, billing, or reverification checks"
}
GHSA-W279-72W5-RRQ7
Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-04-04 08:41An Access Control issue discovered in Extreme Networks Switch Engine (EXOS) before 32.5.1.5, also fixed in 22.7, 31.7.2 allows attackers to gain escalated privileges using crafted telnet commands via Redis server.
{
"affected": [],
"aliases": [
"CVE-2023-43119"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-16T20:15:15Z",
"severity": "CRITICAL"
},
"details": "An Access Control issue discovered in Extreme Networks Switch Engine (EXOS) before 32.5.1.5, also fixed in 22.7, 31.7.2 allows attackers to gain escalated privileges using crafted telnet commands via Redis server.",
"id": "GHSA-w279-72w5-rrq7",
"modified": "2024-04-04T08:41:25Z",
"published": "2023-10-16T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43119"
},
{
"type": "WEB",
"url": "https://extreme-networks.my.site.com/ExtrArticleDetail?an=000114378"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W29C-VPJF-6HX4
Vulnerability from github – Published: 2025-06-09 15:31 – Updated: 2025-10-06 21:30Incorrect authorization vulnerability in TCMAN's GIM v11. This vulnerability allows an attacker, with low privilege level, to change the password of other users through a POST request using the parameters idUser, PasswordActual, PasswordNew and PasswordNewRepeat in /PC/WebService.aspx/validateChangePassword%C3%B1a. To exploit the vulnerability the PasswordActual parameter must be empty.
{
"affected": [],
"aliases": [
"CVE-2025-40668"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-09T13:15:22Z",
"severity": "HIGH"
},
"details": "Incorrect authorization vulnerability in TCMAN\u0027s GIM v11. This vulnerability allows an attacker, with low privilege level, to change the password of other users through a POST request using the parameters idUser, PasswordActual, PasswordNew and PasswordNewRepeat in /PC/WebService.aspx/validateChangePassword%C3%B1a. To exploit the vulnerability the PasswordActual parameter must be empty.",
"id": "GHSA-w29c-vpjf-6hx4",
"modified": "2025-10-06T21:30:43Z",
"published": "2025-06-09T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40668"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-tcman-gim-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-W2FR-4VGX-VQ96
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12Improper authorization in GitLab CE/EE affecting all versions since 13.3 allowed users to view and delete impersonation tokens that administrators created for their account
{
"affected": [],
"aliases": [
"CVE-2021-22250"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-25T19:15:00Z",
"severity": "MODERATE"
},
"details": "Improper authorization in GitLab CE/EE affecting all versions since 13.3 allowed users to view and delete impersonation tokens that administrators created for their account",
"id": "GHSA-w2fr-4vgx-vq96",
"modified": "2022-05-24T19:12:10Z",
"published": "2022-05-24T19:12:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22250"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1205916"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22250.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/332410"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2J3-PQ63-339W
Vulnerability from github – Published: 2022-11-16 12:00 – Updated: 2022-12-15 19:25Support Core Plugin defines the permission Support/DownloadBundle that allows users without Overall/Administer permission to create and download support bundles containing a limited set of diagnostic information.
Support Core Plugin 1206.v14049fa_b_d860 and earlier does not correctly perform permission checks in several HTTP endpoints.
This allows attackers with Support/DownloadBundle permission to download a previously created support bundle containing information limited to users with Overall/Administer permission.
Support Core Plugin 1206.1208.v9b_7a_1d48db_0f deprecates the Support/DownloadBundle permission. The Overall/Administer permission is now required to download support bundles.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1206.v14049fa"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:support-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1206.1208.v9b_7a_1d48db_0f"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-45383"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-21T22:21:38Z",
"nvd_published_at": "2022-11-15T20:15:00Z",
"severity": "MODERATE"
},
"details": "Support Core Plugin defines the permission Support/DownloadBundle that allows users without Overall/Administer permission to create and download support bundles containing a limited set of diagnostic information.\n\nSupport Core Plugin 1206.v14049fa_b_d860 and earlier does not correctly perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Support/DownloadBundle permission to download a previously created support bundle containing information limited to users with Overall/Administer permission.\n\nSupport Core Plugin 1206.1208.v9b_7a_1d48db_0f deprecates the Support/DownloadBundle permission. The Overall/Administer permission is now required to download support bundles.",
"id": "GHSA-w2j3-pq63-339w",
"modified": "2022-12-15T19:25:05Z",
"published": "2022-11-16T12:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45383"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/support-core-plugin/commit/9b7a1d48db0fdfb840ca3393e9462e687e69385b"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/support-core-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-11-15/#SECURITY-2804"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/11/15/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Incorrect permission checks in Jenkins Support Core Plugin"
}
GHSA-W2PM-W3PR-VMC5
Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-08-02 00:00An information disclosure vulnerability in Widevine TA log prior to SMR Oct-2021 Release 1 allows attackers to bypass the ASLR protection mechanism in TEE.
{
"affected": [],
"aliases": [
"CVE-2021-25476"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "An information disclosure vulnerability in Widevine TA log prior to SMR Oct-2021 Release 1 allows attackers to bypass the ASLR protection mechanism in TEE.",
"id": "GHSA-w2pm-w3pr-vmc5",
"modified": "2022-08-02T00:00:33Z",
"published": "2022-05-24T19:16:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25476"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2021\u0026month=10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2R3-453H-7V25
Vulnerability from github – Published: 2025-06-23 21:31 – Updated: 2025-06-23 21:31An incorrect authorization vulnerability exists in multiple WSO2 products that allows unauthorized access to versioned files stored in the registry. Due to flawed authorization logic, a malicious actor with access to the management console can exploit a specific bypass method to retrieve versioned files without proper authorization.
Successful exploitation of this vulnerability could lead to unauthorized disclosure of configuration or resource files that may be stored as registry versions, potentially aiding further attacks or system reconnaissance.
{
"affected": [],
"aliases": [
"CVE-2024-3511"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-23T09:15:21Z",
"severity": "MODERATE"
},
"details": "An incorrect authorization vulnerability exists in multiple WSO2 products that allows unauthorized access to versioned files stored in the registry. Due to flawed authorization logic, a malicious actor with access to the management console can exploit a specific bypass method to retrieve versioned files without proper authorization.\n\nSuccessful exploitation of this vulnerability could lead to unauthorized disclosure of configuration or resource files that may be stored as registry versions, potentially aiding further attacks or system reconnaissance.",
"id": "GHSA-w2r3-453h-7v25",
"modified": "2025-06-23T21:31:55Z",
"published": "2025-06-23T21:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3511"
},
{
"type": "WEB",
"url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2025/WSO2-2024-2702"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2RM-X498-V7F9
Vulnerability from github – Published: 2024-05-23 12:31 – Updated: 2024-05-23 12:31An authorization vulnerability exists within GitLab from versions 16.10 before 16.10.6, 16.11 before 16.11.3, and 17.0 before 17.0.1 where an authenticated attacker could utilize a crafted naming convention to bypass pipeline authorization logic.
{
"affected": [],
"aliases": [
"CVE-2024-5258"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-23T11:15:24Z",
"severity": "MODERATE"
},
"details": "An authorization vulnerability exists within GitLab from versions 16.10 before 16.10.6, 16.11 before 16.11.3, and 17.0 before 17.0.1 where an authenticated attacker could utilize a crafted naming convention to bypass pipeline authorization logic.",
"id": "GHSA-w2rm-x498-v7f9",
"modified": "2024-05-23T12:31:02Z",
"published": "2024-05-23T12:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5258"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/443254"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.