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.
5841 vulnerabilities reference this CWE, most recent first.
GHSA-659R-JW2P-4VQJ
Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35A vulnerability in the role-based access control (RBAC) functionality of Cisco Prime Infrastructure could allow an authenticated, remote attacker to perform a privilege escalation in which one virtual domain user can view and modify another virtual domain configuration. The vulnerability is due to a failure to properly enforce RBAC for virtual domains. An attacker could exploit this vulnerability by sending an authenticated, crafted HTTP request to a targeted application. An exploit could allow the attacker to bypass RBAC policies on the targeted system to modify a virtual domain and access resources that are not normally accessible. Cisco Bug IDs: CSCvg36875.
{
"affected": [],
"aliases": [
"CVE-2018-0096"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-18T06:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the role-based access control (RBAC) functionality of Cisco Prime Infrastructure could allow an authenticated, remote attacker to perform a privilege escalation in which one virtual domain user can view and modify another virtual domain configuration. The vulnerability is due to a failure to properly enforce RBAC for virtual domains. An attacker could exploit this vulnerability by sending an authenticated, crafted HTTP request to a targeted application. An exploit could allow the attacker to bypass RBAC policies on the targeted system to modify a virtual domain and access resources that are not normally accessible. Cisco Bug IDs: CSCvg36875.",
"id": "GHSA-659r-jw2p-4vqj",
"modified": "2022-05-13T01:35:50Z",
"published": "2022-05-13T01:35:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0096"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180117-cpi"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102727"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1040242"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-65F3-3278-7M65
Vulnerability from github – Published: 2022-03-12 00:00 – Updated: 2023-06-30 22:10Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-gw5h-h6hj-f56g. This link is maintained to preserve external references.
Original Description
Impact
Expired PAM accounts and accounts with expired passwords are continued to be seen as valid. Installations use PAM as authentication sources are affected.
Patches
Expired PAM accounts and accounts with expired passwords are no longer being seen as valid. Users should upgrade to 0.12.5 or the latest 0.13.0+dev.
Workarounds
In addition to marking PAM accounts as expired, also disable/lock them. Running usermod -L <username> will add an exclamation mark to the password hash and would result in wrong passwords responses when trying to login.
References
https://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62/
For more information
If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6810.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "gogs.io/gogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-03-14T22:58:34Z",
"nvd_published_at": "2022-03-11T12:15:00Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-gw5h-h6hj-f56g. This link is maintained to preserve external references.\n\n## Original Description\n### Impact\n\nExpired PAM accounts and accounts with expired passwords are continued to be seen as valid. Installations use PAM as authentication sources are affected.\n\n### Patches\n\nExpired PAM accounts and accounts with expired passwords are no longer being seen as valid. Users should upgrade to 0.12.5 or the latest 0.13.0+dev.\n\n### Workarounds\n\nIn addition to marking PAM accounts as expired, also disable/lock them. Running `usermod -L \u003cusername\u003e` will add an exclamation mark to the password hash and would result in wrong passwords responses when trying to login. \n\n### References\n\nhttps://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62/\n\n### For more information\n\nIf you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6810.\n",
"id": "GHSA-65f3-3278-7m65",
"modified": "2023-06-30T22:10:59Z",
"published": "2022-03-12T00:00:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0871"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/commit/64102be2c90e1b47dbdd379873ba76c80d4b0e78"
},
{
"type": "PACKAGE",
"url": "https://github.com/gogs/gogs"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/ea82cfc9-b55c-41fe-ae58-0d0e0bd7ab62"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: Improper Authorization in Gogs",
"withdrawn": "2023-06-30T22:10:59Z"
}
GHSA-65GC-65C8-RC75
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An exploitable improper authorization vulnerability exists in admin_peers API of cpp-ethereum's JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-12114"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-19T22:29:00Z",
"severity": "MODERATE"
},
"details": "An exploitable improper authorization vulnerability exists in admin_peers API of cpp-ethereum\u0027s JSON-RPC (commit 4e1015743b95821849d001618a7ce82c7c073768). A JSON request can cause an access to the restricted functionality resulting in authorization bypass. An attacker can send JSON to trigger this vulnerability.",
"id": "GHSA-65gc-65c8-rc75",
"modified": "2022-05-13T01:01:38Z",
"published": "2022-05-13T01:01:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12114"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0466"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102475"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-65H8-27JH-Q8WV
Vulnerability from github – Published: 2026-03-26 19:08 – Updated: 2026-04-10 20:19Summary
Nostr inbound DM handling could perform crypto and dispatch work before sender and pairing policy enforcement, enabling unauthorized pre-auth computation.
Affected Packages / Versions
- Package:
openclaw(npm) - Affected: < 2026.3.22
- Fixed: >= 2026.3.22
- Latest released tag checked:
v2026.3.23-2(630f1479c44f78484dfa21bb407cbe6f171dac87) - Latest published npm version checked:
2026.3.23-2
Fix Commit(s)
1ee9611079e81b9122f4bed01abb3d9f56206c77
Release Status
The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.
Code-Level Confirmation
- extensions/nostr/src/channel.ts now performs authorization before decrypting and dispatching inbound DM content.
- extensions/nostr/src/nostr-bus.ts adds pre-crypto authorization, size, and rate guardrails before expensive decrypt work.
OpenClaw thanks @kuranikaran for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35627"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T19:08:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nNostr inbound DM handling could perform crypto and dispatch work before sender and pairing policy enforcement, enabling unauthorized pre-auth computation.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: \u003c 2026.3.22\n- Fixed: \u003e= 2026.3.22\n- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)\n- Latest published npm version checked: `2026.3.23-2`\n\n## Fix Commit(s)\n- `1ee9611079e81b9122f4bed01abb3d9f56206c77`\n\n## Release Status\nThe fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.\n\n## Code-Level Confirmation\n- extensions/nostr/src/channel.ts now performs authorization before decrypting and dispatching inbound DM content.\n- extensions/nostr/src/nostr-bus.ts adds pre-crypto authorization, size, and rate guardrails before expensive decrypt work.\n\nOpenClaw thanks @kuranikaran for reporting.",
"id": "GHSA-65h8-27jh-q8wv",
"modified": "2026-04-10T20:19:14Z",
"published": "2026-03-26T19:08:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-65h8-27jh-q8wv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35627"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/1ee9611079e81b9122f4bed01abb3d9f56206c77"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-unauthenticated-cryptographic-work-in-nostr-inbound-dm-handling"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Nostr inbound DMs could trigger unauthenticated crypto work before sender policy enforcement"
}
GHSA-65HF-C38W-3RRH
Vulnerability from github – Published: 2025-12-17 21:30 – Updated: 2025-12-17 21:30The Ultimate Member plugin for WordPress is vulnerable to Profile Privacy Setting Bypass in all versions up to, and including, 2.11.0. This is due to a flaw in the secure fields mechanism where field keys are stored in the allowed fields list before the required_perm check is applied during rendering. This makes it possible for authenticated attackers with Subscriber-level access to modify their profile privacy settings (e.g., setting profile to "Only me") via direct parameter manipulation, even when the administrator has explicitly disabled the option for their role.
{
"affected": [],
"aliases": [
"CVE-2025-14081"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-17T19:16:01Z",
"severity": "MODERATE"
},
"details": "The Ultimate Member plugin for WordPress is vulnerable to Profile Privacy Setting Bypass in all versions up to, and including, 2.11.0. This is due to a flaw in the secure fields mechanism where field keys are stored in the allowed fields list before the `required_perm` check is applied during rendering. This makes it possible for authenticated attackers with Subscriber-level access to modify their profile privacy settings (e.g., setting profile to \"Only me\") via direct parameter manipulation, even when the administrator has explicitly disabled the option for their role.",
"id": "GHSA-65hf-c38w-3rrh",
"modified": "2025-12-17T21:30:48Z",
"published": "2025-12-17T21:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14081"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ultimate-member/tags/2.10.6/includes/core/class-account.php#L610"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ultimate-member/tags/2.10.6/includes/core/um-actions-account.php#L322"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3421362"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/aad57a68-c385-491f-a5a2-32906df4b52b?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-65PV-GQPG-397F
Vulnerability from github – Published: 2022-08-16 00:00 – Updated: 2022-08-17 00:00The WP-DBManager WordPress plugin before 2.80.8 does not prevent administrators from running arbitrary commands on the server in multisite installations, where only super-administrators should.
{
"affected": [],
"aliases": [
"CVE-2022-2354"
],
"database_specific": {
"cwe_ids": [
"CWE-863",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-15T11:21:00Z",
"severity": "HIGH"
},
"details": "The WP-DBManager WordPress plugin before 2.80.8 does not prevent administrators from running arbitrary commands on the server in multisite installations, where only super-administrators should.",
"id": "GHSA-65pv-gqpg-397f",
"modified": "2022-08-17T00:00:22Z",
"published": "2022-08-16T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2354"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/1c8c5861-ce87-4813-9e26-470d63c1903a"
}
],
"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-65V5-9W4X-XH53
Vulnerability from github – Published: 2023-06-19 06:30 – Updated: 2024-03-21 03:35In KeePassXC through 2.7.5, a local attacker can make changes to the Database security settings, including master password and second-factor authentication, within an authenticated KeePassXC Database session, without the need to authenticate these changes by entering the password and/or second-factor authentication to confirm changes.
{
"affected": [],
"aliases": [
"CVE-2023-35866"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-19T06:15:09Z",
"severity": "MODERATE"
},
"details": "In KeePassXC through 2.7.5, a local attacker can make changes to the Database security settings, including master password and second-factor authentication, within an authenticated KeePassXC Database session, without the need to authenticate these changes by entering the password and/or second-factor authentication to confirm changes.",
"id": "GHSA-65v5-9w4x-xh53",
"modified": "2024-03-21T03:35:24Z",
"published": "2023-06-19T06:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35866"
},
{
"type": "WEB",
"url": "https://github.com/keepassxreboot/keepassxc/issues/9339"
},
{
"type": "WEB",
"url": "https://github.com/keepassxreboot/keepassxc/issues/9339#issuecomment-1598219482"
},
{
"type": "WEB",
"url": "https://github.com/keepassxreboot/keepassxc/issues/9391"
},
{
"type": "WEB",
"url": "https://keepassxc.org/docs/#faq-yubikey-2fa"
},
{
"type": "WEB",
"url": "https://medium.com/%40cybercitizen.tech/keepassxc-vulnerability-cve-2023-35866-dc7d447c4903"
},
{
"type": "WEB",
"url": "https://medium.com/@cybercitizen.tech/keepassxc-vulnerability-cve-2023-35866-dc7d447c4903"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-663R-G5G6-HGX7
Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-12-17 21:30A permissions issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to cause a denial-of-service.
{
"affected": [],
"aliases": [
"CVE-2025-43397"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T02:15:46Z",
"severity": "MODERATE"
},
"details": "A permissions issue was addressed by removing the vulnerable code. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to cause a denial-of-service.",
"id": "GHSA-663r-g5g6-hgx7",
"modified": "2025-12-17T21:30:33Z",
"published": "2025-11-04T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43397"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125634"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125635"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125636"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-664H-GPGQ-H6XX
Vulnerability from github – Published: 2026-06-17 13:55 – Updated: 2026-06-17 13:55Impact
Three mutating endpoints in the evaluation test runs controller authorized state-changing actions using workflow:read instead of the action-appropriate workflow:execute scope. An authenticated user with project:viewer role on a project could start new evaluation test runs, cancel in-flight runs, and delete run records for workflows they only had read access to.
This issue only affects instances with Advanced Permissions (Enterprise/Cloud) where projects and viewer roles are in use.
Patches
The issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict project membership to fully trusted users only. - Avoid granting viewer access to projects containing sensitive workflows.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.123.55"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "2.26.0"
},
{
"fixed": "2.26.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-rc.0"
},
{
"fixed": "2.25.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T13:55:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\nThree mutating endpoints in the evaluation test runs controller authorized state-changing actions using `workflow:read` instead of the action-appropriate `workflow:execute` scope. An authenticated user with `project:viewer` role on a project could start new evaluation test runs, cancel in-flight runs, and delete run records for workflows they only had read access to.\n\nThis issue only affects instances with Advanced Permissions (Enterprise/Cloud) where projects and viewer roles are in use.\n\n## Patches\nThe issue has been fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Restrict project membership to fully trusted users only.\n- Avoid granting viewer access to projects containing sensitive workflows.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
"id": "GHSA-664h-gpgq-h6xx",
"modified": "2026-06-17T13:55:59Z",
"published": "2026-06-17T13:55:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-664h-gpgq-h6xx"
},
{
"type": "PACKAGE",
"url": "https://github.com/n8n-io/n8n"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "n8n: Wrong OAuth Scope on Evaluation Test Runs Endpoints"
}
GHSA-667W-MMH7-MRR4
Vulnerability from github – Published: 2026-03-10 18:16 – Updated: 2026-03-10 18:45Summary
The /studiocms_api/dashboard/api-tokens endpoint allows any authenticated user (at least Editor) to generate API tokens for any other user, including owner and admin accounts. The endpoint fails to validate whether the requesting user is authorized to create tokens on behalf of the target user ID, resulting in a full privilege escalation.
Details
The API token generation endpoint accepts a user parameter in the request body that specifies which user the token should be created for. The server-side logic authenticates the session (via auth_session cookie) but does not verify that the authenticated user matches the target user ID nor checks if the caller has sufficient privileges to perform this action on behalf of another user. This is a classic BOLA vulnerability: the authorization check is limited to "is the user logged in?" instead of "is this user authorized to perform this action on this specific resource?"
Vulnerable Code
The following is the server-side handler for the POST /studiocms_api/dashboard/api-tokens endpoint: File: packages/studiocms/frontend/pages/studiocms_api/dashboard/api-tokens.ts (lines 16–57) Version: studiocms@0.3.0
POST: (ctx) =>
genLogger('studiocms/routes/api/dashboard/api-tokens.POST')(function* () {
const sdk = yield* SDKCore;
// Check if demo mode is enabled
if (developerConfig.demoMode !== false) {
return apiResponseLogger(403, 'Demo mode is enabled, this action is not allowed.');
}
// Get user data
const userData = ctx.locals.StudioCMS.security?.userSessionData; // [1]
// Check if user is logged in
if (!userData?.isLoggedIn) { // [2]
return apiResponseLogger(403, 'Unauthorized');
}
// Check if user has permission
const isAuthorized = ctx.locals.StudioCMS.security?.userPermissionLevel.isEditor; // [3]
if (!isAuthorized) {
return apiResponseLogger(403, 'Unauthorized');
}
// Get Json Data
const jsonData = yield* readAPIContextJson<{
description: string;
user: string; // [4]
}>(ctx);
// Validate form data
if (!jsonData.description) {
return apiResponseLogger(400, 'Invalid form data, description is required');
}
if (!jsonData.user) {
return apiResponseLogger(400, 'Invalid form data, user is required');
}
// [5] jsonData.user passed directly — no check against userData
const newToken = yield* sdk.REST_API.tokens.new(jsonData.user, jsonData.description);
return createJsonResponse({ token: newToken.key }); // [6]
}),
Analysis The authorization logic has three distinct flaws: 1. Insufficient permission gate [1][2][3]: The handler retrieves the session from ctx.locals.StudioCMS.security and only verifies that isEditor is true. This means any user with editor privileges or above passes the gate. 2. Missing object-level authorization [4][5]: The user field from the JSON payload (line 54) is passed directly to sdk.REST_API.tokens.new() without any comparison against userData (the authenticated caller's identity from the session at [1]). There is no check such as jsonData.user === userData.id. This allows any authenticated user to specify an arbitrary target UUID and generate a token for that account. 3. No target role validation [5]: Even if cross-user token generation were an intended feature, there is no check to prevent a lower-privileged user from generating tokens for higher-privileged accounts (admin, owner).
PoC
Environment The following user roles were identified in the application: User ID | Role 2450bf33-0135-4142-80be-9854f9a5e9f1 | owner eacee42e-ae7e-4e9e-945b-68e26696ece4 | admin 2d93a386-e9cb-451e-a811-d8a34bfdf4da | admin 39b3e7d3-5eb0-48e1-abdc-ce95a57b212c | editor a1585423-9ade-426e-a713-9c81ed035463 | visitor
Step 1 — Generate an API Token for the Owner (as Editor) An authenticated Editor sends the following request, specifying the owner user ID in the body:
POST /studiocms_api/dashboard/api-tokens HTTP/1.1
Host: <target>
Cookie: auth_session=<editor_session_cookie>
Content-Type: application/json
Content-Length: 74
{
"user": "2450bf33-0135-4142-80be-9854f9a5e9f1",
"description": "pwn"
}
Result: The server returns a valid JWT token bound to the owner account.
Step 2 — Use the Token to Access the API as Owner
curl -H "Authorization: Bearer <owner_jwt_token>" http://<target>/studiocms_api/rest/v1/users
Result: The attacker now has full API access with owner privileges, including the ability to list all users, modify content, and manage the application.
Impact
- Privilege Escalation: Any authenticated user (above visitor) can escalate to owner level access.
- Full API Access: The generated token grants unrestricted access to all REST API endpoints with the impersonated user's permissions.
- Account Takeover: An attacker can impersonate any user in the system by specifying their UUID.
- Data Breach: Access to user listings, content management, and potentially sensitive configuration data.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.0"
},
"package": {
"ecosystem": "npm",
"name": "studiocms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30944"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-10T18:16:41Z",
"nvd_published_at": "2026-03-10T18:18:54Z",
"severity": "HIGH"
},
"details": "## Summary\nThe /studiocms_api/dashboard/api-tokens endpoint allows any authenticated user (at least Editor) to generate API tokens for any other user, including owner and admin accounts. The endpoint fails to validate whether the requesting user is authorized to create tokens on behalf of the target user ID, resulting in a full privilege escalation.\n\n## Details\nThe API token generation endpoint accepts a user parameter in the request body that specifies which user the token should be created for. The server-side logic authenticates the session (via auth_session cookie) but does not verify that the authenticated user matches the target user ID nor checks if the caller has sufficient privileges to perform this action on behalf of another user.\nThis is a classic BOLA vulnerability: the authorization check is limited to \"is the user logged in?\" instead of \"is this user authorized to perform this action on this specific resource?\"\n\n#### Vulnerable Code\nThe following is the server-side handler for the POST /studiocms_api/dashboard/api-tokens endpoint:\n**File:** packages/studiocms/frontend/pages/studiocms_api/dashboard/api-tokens.ts (lines 16\u201357)\n**Version:** studiocms@0.3.0\n```\nPOST: (ctx) =\u003e\n genLogger(\u0027studiocms/routes/api/dashboard/api-tokens.POST\u0027)(function* () {\n const sdk = yield* SDKCore;\n\n // Check if demo mode is enabled\n if (developerConfig.demoMode !== false) {\n return apiResponseLogger(403, \u0027Demo mode is enabled, this action is not allowed.\u0027);\n }\n\n // Get user data\n const userData = ctx.locals.StudioCMS.security?.userSessionData; // [1]\n\n // Check if user is logged in\n if (!userData?.isLoggedIn) { // [2]\n return apiResponseLogger(403, \u0027Unauthorized\u0027);\n }\n\n // Check if user has permission\n const isAuthorized = ctx.locals.StudioCMS.security?.userPermissionLevel.isEditor; // [3]\n if (!isAuthorized) {\n return apiResponseLogger(403, \u0027Unauthorized\u0027);\n }\n\n // Get Json Data\n const jsonData = yield* readAPIContextJson\u003c{\n description: string;\n user: string; // [4]\n }\u003e(ctx);\n\n // Validate form data\n if (!jsonData.description) {\n return apiResponseLogger(400, \u0027Invalid form data, description is required\u0027);\n }\n\n if (!jsonData.user) {\n return apiResponseLogger(400, \u0027Invalid form data, user is required\u0027);\n }\n\n // [5] jsonData.user passed directly \u2014 no check against userData\n const newToken = yield* sdk.REST_API.tokens.new(jsonData.user, jsonData.description);\n\n return createJsonResponse({ token: newToken.key }); // [6]\n }),\n```\n**Analysis**\nThe authorization logic has three distinct flaws:\n1. **Insufficient permission gate [1][2][3]:** The handler retrieves the session from ctx.locals.StudioCMS.security and only verifies that isEditor is true. This means any user with editor privileges or above passes the gate. \n2. **Missing object-level authorization [4][5]:** The user field from the JSON payload (line 54) is passed directly to sdk.REST_API.tokens.new() without any comparison against userData (the authenticated caller\u0027s identity from the session at [1]). There is no check such as jsonData.user === userData.id. This allows any authenticated user to specify an arbitrary target UUID and generate a token for that account.\n3. **No target role validation [5]:** Even if cross-user token generation were an intended feature, there is no check to prevent a lower-privileged user from generating tokens for higher-privileged accounts (admin, owner).\n\n## PoC\n**Environment**\nThe following user roles were identified in the application:\n*User ID | Role*\n2450bf33-0135-4142-80be-9854f9a5e9f1 | owner\neacee42e-ae7e-4e9e-945b-68e26696ece4 | admin\n2d93a386-e9cb-451e-a811-d8a34bfdf4da | admin\n39b3e7d3-5eb0-48e1-abdc-ce95a57b212c | editor\na1585423-9ade-426e-a713-9c81ed035463 | visitor\n\n**Step 1 \u2014 Generate an API Token for the Owner (as Editor)**\nAn authenticated Editor sends the following request, specifying the owner user ID in the body:\n```\nPOST /studiocms_api/dashboard/api-tokens HTTP/1.1\nHost: \u003ctarget\u003e\nCookie: auth_session=\u003ceditor_session_cookie\u003e\nContent-Type: application/json\nContent-Length: 74\n\n{\n \"user\": \"2450bf33-0135-4142-80be-9854f9a5e9f1\",\n \"description\": \"pwn\"\n}\n```\n**Result:** The server returns a valid JWT token bound to the owner account.\n\n**Step 2 \u2014 Use the Token to Access the API as Owner**\n```\ncurl -H \"Authorization: Bearer \u003cowner_jwt_token\u003e\" http://\u003ctarget\u003e/studiocms_api/rest/v1/users\n```\n**Result:** The attacker now has full API access with owner privileges, including the ability to list all users, modify content, and manage the application.\n\n## Impact\n- **Privilege Escalation:** Any authenticated user (above visitor) can escalate to owner level access.\n- **Full API Access:** The generated token grants unrestricted access to all REST API endpoints with the impersonated user\u0027s permissions.\n- **Account Takeover:** An attacker can impersonate any user in the system by specifying their UUID.\n- **Data Breach:** Access to user listings, content management, and potentially sensitive configuration data.",
"id": "GHSA-667w-mmh7-mrr4",
"modified": "2026-03-10T18:45:47Z",
"published": "2026-03-10T18:16:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-667w-mmh7-mrr4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30944"
},
{
"type": "WEB",
"url": "https://github.com/withstudiocms/studiocms/commit/9eec9c3b45523b635cfe16d55aa55afabacbebe3"
},
{
"type": "WEB",
"url": "https://github.com/withstudiocms/studiocms/commit/f4a209fc090c90195e2419fff47b48a46eab7441"
},
{
"type": "PACKAGE",
"url": "https://github.com/withstudiocms/studiocms"
},
{
"type": "WEB",
"url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms%400.4.0"
},
{
"type": "WEB",
"url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.0"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "StudioCMS has Privilege Escalation via Insecure API Token Generation"
}
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.