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.
5541 vulnerabilities reference this CWE, most recent first.
GHSA-WC47-GHMC-28V7
Vulnerability from github – Published: 2021-12-08 00:01 – Updated: 2022-07-13 00:01There is an Improper access control vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may affect service confidentiality.
{
"affected": [],
"aliases": [
"CVE-2021-37038"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-07T16:15:00Z",
"severity": "HIGH"
},
"details": "There is an Improper access control vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may affect service confidentiality.",
"id": "GHSA-wc47-ghmc-28v7",
"modified": "2022-07-13T00:01:32Z",
"published": "2021-12-08T00:01:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37038"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2021/9"
}
],
"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-WC66-56FW-MMP9
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02An improper authorization handling flaw was found in Foreman. The Shellhooks plugin for the smart-proxy allows Foreman clients to execute actions that should be limited to the Foreman Server. This flaw allows an authenticated local attacker to access and delete limited resources and also causes a denial of service on the Foreman server. The highest threat from this vulnerability is to integrity and system availability.
{
"affected": [],
"aliases": [
"CVE-2021-3457"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-12T15:15:00Z",
"severity": "MODERATE"
},
"details": "An improper authorization handling flaw was found in Foreman. The Shellhooks plugin for the smart-proxy allows Foreman clients to execute actions that should be limited to the Foreman Server. This flaw allows an authenticated local attacker to access and delete limited resources and also causes a denial of service on the Foreman server. The highest threat from this vulnerability is to integrity and system availability.",
"id": "GHSA-wc66-56fw-mmp9",
"modified": "2022-05-24T19:02:12Z",
"published": "2022-05-24T19:02:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3457"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1940990"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-WC8C-QW6V-H7F6
Vulnerability from github – Published: 2026-03-04 20:05 – Updated: 2026-03-06 22:43Summary
When using @hono/node-server's static file serving together with route-based middleware protections (e.g. protecting /admin/*), inconsistent URL decoding can allow protected static resources to be accessed without authorization.
In particular, paths containing encoded slashes (%2F) may be evaluated differently by routing/middleware matching versus static file path resolution, enabling a bypass where middleware does not run but the static file is still served.
Details
The routing layer and the node-server static handler normalize request paths differently. The router preserves %2F as a literal string when matching routes, while the static handler decodes %2F into / before resolving the filesystem path.
Example request:
/admin%2Fsecret.html
This may:
- fail to match middleware intended for /admin/*, but
- still be resolved by the static handler as /admin/secret.html under the configured static root.
This does not allow access outside the configured static root and is not a path traversal vulnerability.
Impact
An unauthenticated attacker could bypass route-based authorization protections for protected static resources by supplying paths containing encoded slashes.
Applications relying solely on route-based middleware to protect static subpaths under the same static root may have exposed those resources.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@hono/node-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29087"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T20:05:49Z",
"nvd_published_at": "2026-03-06T18:16:19Z",
"severity": "HIGH"
},
"details": "## Summary\n\nWhen using @hono/node-server\u0027s static file serving together with route-based middleware protections (e.g. protecting `/admin/*`), inconsistent URL decoding can allow protected static resources to be accessed without authorization.\n\nIn particular, paths containing encoded slashes (`%2F`) may be evaluated differently by routing/middleware matching versus static file path resolution, enabling a bypass where middleware does not run but the static file is still served.\n\n## Details\n\nThe routing layer and the node-server static handler normalize request paths differently. The router preserves `%2F` as a literal string when matching routes, while the static handler decodes `%2F` into `/` before resolving the filesystem path.\n\nExample request:\n\n- `/admin%2Fsecret.html`\n\nThis may:\n- fail to match middleware intended for `/admin/*`, but\n- still be resolved by the static handler as `/admin/secret.html` under the configured static root.\n\nThis does not allow access outside the configured static root and is not a path traversal vulnerability.\n\n## Impact\n\nAn unauthenticated attacker could bypass route-based authorization protections for protected static resources by supplying paths containing encoded slashes.\n\nApplications relying solely on route-based middleware to protect static subpaths under the same static root may have exposed those resources.",
"id": "GHSA-wc8c-qw6v-h7f6",
"modified": "2026-03-06T22:43:58Z",
"published": "2026-03-04T20:05:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/node-server/security/advisories/GHSA-wc8c-qw6v-h7f6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29087"
},
{
"type": "WEB",
"url": "https://github.com/honojs/node-server/commit/455015be1697dd89974a68b70350ea7b2d126d2e"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/node-server"
}
],
"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": "@hono/node-server has authorization bypass for protected static paths via encoded slashes in Serve Static Middleware"
}
GHSA-WCCP-C983-J22Q
Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34A vulnerability in the authorization subsystem of Cisco Adaptive Security Appliance (ASA) Software could allow an authenticated, but unprivileged (levels 0 and 1), remote attacker to perform privileged actions by using the web management interface. The vulnerability is due to improper validation of user privileges when using the web management interface. An attacker could exploit this vulnerability by sending specific HTTP requests via HTTPS to an affected device as an unprivileged user. An exploit could allow the attacker to retrieve files (including the running configuration) from the device or to upload and replace software images on the device.
{
"affected": [],
"aliases": [
"CVE-2018-15465"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-24T14:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the authorization subsystem of Cisco Adaptive Security Appliance (ASA) Software could allow an authenticated, but unprivileged (levels 0 and 1), remote attacker to perform privileged actions by using the web management interface. The vulnerability is due to improper validation of user privileges when using the web management interface. An attacker could exploit this vulnerability by sending specific HTTP requests via HTTPS to an affected device as an unprivileged user. An exploit could allow the attacker to retrieve files (including the running configuration) from the device or to upload and replace software images on the device.",
"id": "GHSA-wccp-c983-j22q",
"modified": "2022-05-13T01:34:14Z",
"published": "2022-05-13T01:34:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15465"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181219-asa-privesc"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2018-46"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106256"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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"
}
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.