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-WCCV-R56Q-VWMW
Vulnerability from github – Published: 2022-02-12 00:00 – Updated: 2023-06-23 21:30Improper access control vulnerability in Samsung SearchWidget prior to versions 2.3.00.6 in China models allows untrusted applications to load arbitrary URL and local files in webview.
{
"affected": [],
"aliases": [
"CVE-2022-24923"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-11T18:15:00Z",
"severity": "LOW"
},
"details": "Improper access control vulnerability in Samsung SearchWidget prior to versions 2.3.00.6 in China models allows untrusted applications to load arbitrary URL and local files in webview.",
"id": "GHSA-wccv-r56q-vwmw",
"modified": "2023-06-23T21:30:26Z",
"published": "2022-02-12T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24923"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2022\u0026month=2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WCGJ-F865-C7J7
Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-11 15:48Description
When using affected versions of the Next.js SDK, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results.
Am I Affected?
You are affected if you meet the following preconditions: - Applications using the auth0/nextjs-auth0 SDK with a singleton client instance, versions 4.11.0, 4.11.1, and 4.12.0.
Affected product and versions
Auth0/nextjs-auth0 v4.11.0, v4.11.1, and v4.12.0.
Resolution
Upgrade Auth0/nextjs-auth0 version to v4.11.2 or v4.12.1
Acknowledgements
Okta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@auth0/nextjs-auth0"
},
"ranges": [
{
"events": [
{
"introduced": "4.11.0"
},
{
"fixed": "4.11.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@auth0/nextjs-auth0"
},
"ranges": [
{
"events": [
{
"introduced": "4.12.0"
},
{
"fixed": "4.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67490"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-10T21:31:24Z",
"nvd_published_at": "2025-12-10T23:15:48Z",
"severity": "MODERATE"
},
"details": "### Description\nWhen using affected versions of the Next.js SDK, simultaneous requests on the same client may result in improper lookups in the TokenRequestCache for the request results.\n\n### Am I Affected?\nYou are affected if you meet the following preconditions:\n- Applications using the auth0/nextjs-auth0 SDK with a singleton client instance, versions 4.11.0, 4.11.1, and 4.12.0.\n\n### Affected product and versions\nAuth0/nextjs-auth0 v4.11.0, v4.11.1, and v4.12.0.\n\n### Resolution\nUpgrade Auth0/nextjs-auth0 version to v4.11.2 or v4.12.1\n\n### Acknowledgements\nOkta would like to thank Joshua Rogers (MegaManSec) for their discovery and responsible disclosure.",
"id": "GHSA-wcgj-f865-c7j7",
"modified": "2025-12-11T15:48:10Z",
"published": "2025-12-10T21:31:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/nextjs-auth0/security/advisories/GHSA-wcgj-f865-c7j7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67490"
},
{
"type": "WEB",
"url": "https://github.com/auth0/nextjs-auth0/commit/26cc8a7c60f4b134700912736f991a25bd6bbf0b"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/nextjs-auth0"
}
],
"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": "Improper Request Caching Lookup in the Auth0 Next.js SDK"
}
GHSA-WCQR-6GJ6-96WC
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2025-11-04 00:32The issue was addressed with improved permissions logic. This issue is fixed in macOS Sequoia 15.2, macOS Sonoma 14.7.2. An app may be able to modify protected parts of the file system.
{
"affected": [],
"aliases": [
"CVE-2024-54495"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:15:30Z",
"severity": "MODERATE"
},
"details": "The issue was addressed with improved permissions logic. This issue is fixed in macOS Sequoia 15.2, macOS Sonoma 14.7.2. An app may be able to modify protected parts of the file system.",
"id": "GHSA-wcqr-6gj6-96wc",
"modified": "2025-11-04T00:32:14Z",
"published": "2024-12-12T03:33:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54495"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121839"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121840"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/7"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WCR3-9X4C-F5GJ
Vulnerability from github – Published: 2026-06-26 22:31 – Updated: 2026-06-26 22:31Blnk API key endpoints had an authorization issue that allowed non-master API keys to perform key-management actions outside their intended authorization boundary.
In affected versions, API key operations trusted caller-controlled request values for owner and scope decisions. As a result, a non-master API key could potentially manage keys for another owner by supplying a different owner value, or create a more privileged API key by requesting broader scopes than it already had.
This has been fixed by deriving the effective owner from the authenticated API key and enforcing scope coverage checks when creating new keys.
Details
The API key authorization flow previously trusted request data supplied by the caller when deciding which owner a key-management operation applied to and which scopes could be granted.
This meant a non-master API key could potentially:
- create API keys for another owner
- list API keys belonging to another owner
- revoke API keys belonging to another owner
- create a new API key with broader scopes than the caller’s own scopes
The patched version changes this behavior for non-master API keys:
- the effective owner is derived from the authenticated API key
- caller-supplied owner values are no longer trusted for authorization decisions
- cross-owner key operations are rejected with
403 Forbidden - requested scopes must be covered by the caller’s existing scopes
- master-key behavior is unchanged
Impact
A non-master API key with access to API key management endpoints could potentially perform unauthorized key-management operations across owners or escalate its permissions by creating a new API key with broader scopes.
Deployments using API keys for programmatic key creation, listing, or revocation should upgrade.
Affected versions
Versions up to and including v0.14.2 are affected.
Patched versions
This issue is fixed in v0.14.3.
Users should upgrade to v0.14.3 or later.
Workarounds
If developers cannot upgrade their applications immediately, restrict access to API key management endpoints to trusted master keys only.
Where possible, disable or block non-master API key access to key creation, listing, and revocation endpoints until the patched version is deployed.
Credits
Blank thanks @Shivam8584 for identifying and fixing this issue.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.14.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/blnkfinance/blnk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:31:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Blnk API key endpoints had an authorization issue that allowed non-master API keys to perform key-management actions outside their intended authorization boundary.\n\nIn affected versions, API key operations trusted caller-controlled request values for owner and scope decisions. As a result, a non-master API key could potentially manage keys for another owner by supplying a different owner value, or create a more privileged API key by requesting broader scopes than it already had.\n\nThis has been fixed by deriving the effective owner from the authenticated API key and enforcing scope coverage checks when creating new keys.\n\n## Details\n\nThe API key authorization flow previously trusted request data supplied by the caller when deciding which owner a key-management operation applied to and which scopes could be granted.\n\nThis meant a non-master API key could potentially:\n\n- create API keys for another owner\n- list API keys belonging to another owner\n- revoke API keys belonging to another owner\n- create a new API key with broader scopes than the caller\u2019s own scopes\n\nThe patched version changes this behavior for non-master API keys:\n\n- the effective owner is derived from the authenticated API key\n- caller-supplied owner values are no longer trusted for authorization decisions\n- cross-owner key operations are rejected with `403 Forbidden`\n- requested scopes must be covered by the caller\u2019s existing scopes\n- master-key behavior is unchanged\n\n## Impact\n\nA non-master API key with access to API key management endpoints could potentially perform unauthorized key-management operations across owners or escalate its permissions by creating a new API key with broader scopes.\n\nDeployments using API keys for programmatic key creation, listing, or revocation should upgrade.\n\n## Affected versions\n\nVersions up to and including `v0.14.2` are affected.\n\n## Patched versions\n\nThis issue is fixed in `v0.14.3`.\n\nUsers should upgrade to `v0.14.3` or later.\n\n## Workarounds\n\nIf developers cannot upgrade their applications immediately, restrict access to API key management endpoints to trusted master keys only.\n\nWhere possible, disable or block non-master API key access to key creation, listing, and revocation endpoints until the patched version is deployed.\n\n## Credits\n\nBlank thanks @Shivam8584 for identifying and fixing this issue.",
"id": "GHSA-wcr3-9x4c-f5gj",
"modified": "2026-06-26T22:31:03Z",
"published": "2026-06-26T22:31:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/blnkfinance/blnk/security/advisories/GHSA-wcr3-9x4c-f5gj"
},
{
"type": "PACKAGE",
"url": "https://github.com/blnkfinance/blnk"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Blnk has an API key authorization bypass in owner and scope enforcement"
}
GHSA-WCWW-4VRG-9H35
Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49Apps Manager included in Pivotal Application Service, versions 1.12.x prior to 1.12.22, 2.0.x prior to 2.0.13, and 2.1.x prior to 2.1.4 contains an authorization enforcement vulnerability. A member of any org is able to create invitations to any org for which the org GUID can be discovered. Accepting this invitation gives unauthorized access to view the member list, domains, quotas and other information about the org.
{
"affected": [],
"aliases": [
"CVE-2018-1278"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-11T20:29:00Z",
"severity": "MODERATE"
},
"details": "Apps Manager included in Pivotal Application Service, versions 1.12.x prior to 1.12.22, 2.0.x prior to 2.0.13, and 2.1.x prior to 2.1.4 contains an authorization enforcement vulnerability. A member of any org is able to create invitations to any org for which the org GUID can be discovered. Accepting this invitation gives unauthorized access to view the member list, domains, quotas and other information about the org.",
"id": "GHSA-wcww-4vrg-9h35",
"modified": "2022-05-13T01:49:38Z",
"published": "2022-05-13T01:49:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1278"
},
{
"type": "WEB",
"url": "https://pivotal.io/security/cve-2018-1278"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104227"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WCXR-59V9-RXR8
Vulnerability from github – Published: 2026-03-13 20:55 – Updated: 2026-04-01 00:06Summary
The built-in session_status tool did not enforce the intended session-visibility boundary. A sandboxed subagent could supply another session's sessionKey and inspect or modify state outside its own sandbox scope.
Impact
This allowed a sandboxed child session to read parent or sibling session data and, in affected releases, update the target session's persisted model override.
Affected versions
openclaw <= 2026.3.8
Patch
Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. Session visibility checks now enforce the sandbox boundary before reading or mutating session state.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.8"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32918"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T20:55:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe built-in `session_status` tool did not enforce the intended session-visibility boundary. A sandboxed subagent could supply another session\u0027s `sessionKey` and inspect or modify state outside its own sandbox scope.\n\n### Impact\n\nThis allowed a sandboxed child session to read parent or sibling session data and, in affected releases, update the target session\u0027s persisted model override.\n\n### Affected versions\n\n`openclaw` `\u003c= 2026.3.8`\n\n### Patch\n\nFixed in `openclaw` `2026.3.11` and included in later releases such as `2026.3.12`. Session visibility checks now enforce the sandbox boundary before reading or mutating session state.",
"id": "GHSA-wcxr-59v9-rxr8",
"modified": "2026-04-01T00:06:27Z",
"published": "2026-03-13T20:55:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-wcxr-59v9-rxr8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32918"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-session-sandbox-escape-via-session-status-tool"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "`OpenClaw: session_status` let sandboxed subagents access parent or sibling session state"
}
GHSA-WF4M-RQ68-3MFC
Vulnerability from github – Published: 2023-01-12 06:30 – Updated: 2023-01-18 21:30Incorrect Authorization check affecting all versions of GitLab EE from 13.11 prior to 15.5.7, 15.6 prior to 15.6.4, and 15.7 prior to 15.7.2 allows group access tokens to continue working even after the group owner loses the ability to revoke them.
{
"affected": [],
"aliases": [
"CVE-2022-4167"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-12T04:15:00Z",
"severity": "HIGH"
},
"details": "Incorrect Authorization check affecting all versions of GitLab EE from 13.11 prior to 15.5.7, 15.6 prior to 15.6.4, and 15.7 prior to 15.7.2 allows group access tokens to continue working even after the group owner loses the ability to revoke them.",
"id": "GHSA-wf4m-rq68-3mfc",
"modified": "2023-01-18T21:30:21Z",
"published": "2023-01-12T06:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4167"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-4167.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/367740"
}
],
"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-WF74-667M-QG32
Vulnerability from github – Published: 2022-06-07 00:00 – Updated: 2022-06-15 00:00Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution.
{
"affected": [],
"aliases": [
"CVE-2022-30586"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-06T19:15:00Z",
"severity": "HIGH"
},
"details": "Gradle Enterprise through 2022.2.2 has Incorrect Access Control that leads to code execution.",
"id": "GHSA-wf74-667m-qg32",
"modified": "2022-06-15T00:00:23Z",
"published": "2022-06-07T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30586"
},
{
"type": "WEB",
"url": "https://security.gradle.com"
},
{
"type": "WEB",
"url": "https://security.gradle.com/advisory/2022-09"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WFFG-FW64-5MVQ
Vulnerability from github – Published: 2025-11-11 15:31 – Updated: 2025-11-11 15:31A security issue was discovered within Verve Asset Manager allowing unauthorized read-only users to read, update, and delete users via the API.
{
"affected": [],
"aliases": [
"CVE-2025-11862"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T14:15:34Z",
"severity": "HIGH"
},
"details": "A security issue was discovered within Verve Asset Manager allowing unauthorized read-only users to read, update, and delete users via the API.",
"id": "GHSA-wffg-fw64-5mvq",
"modified": "2025-11-11T15:31:20Z",
"published": "2025-11-11T15:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11862"
},
{
"type": "WEB",
"url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1759.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:L/SA:H/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-WFH5-X68W-HVW2
Vulnerability from github – Published: 2022-05-24 22:29 – Updated: 2025-11-04 21:30Bluetooth Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device (participating in the provisioning protocol) to identify the AuthValue used given the Provisioner’s public key, and the confirmation number and nonce provided by the provisioning device. This could permit a device without the AuthValue to complete provisioning without brute-forcing the AuthValue.
{
"affected": [],
"aliases": [
"CVE-2020-26559"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-24T18:15:00Z",
"severity": "HIGH"
},
"details": "Bluetooth Mesh Provisioning in the Bluetooth Mesh profile 1.0 and 1.0.1 may permit a nearby device (participating in the provisioning protocol) to identify the AuthValue used given the Provisioner\u2019s public key, and the confirmation number and nonce provided by the provisioning device. This could permit a device without the AuthValue to complete provisioning without brute-forcing the AuthValue.",
"id": "GHSA-wfh5-x68w-hvw2",
"modified": "2025-11-04T21:30:25Z",
"published": "2022-05-24T22:29:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26559"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/799380"
},
{
"type": "WEB",
"url": "https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/reporting-security"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/799380"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"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.