Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect 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:54
VLAI
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.

Show details on source website

{
  "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:30
VLAI
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

Show details on source website

{
  "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:47
VLAI
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.

Show details on source website

{
  "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:32
VLAI
Details

Tanium addressed an improper input validation vulnerability in Tanium Appliance.

Show details on source website

{
  "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:39
VLAI
Summary
OpenClaw Node system.run approval context-binding weakness in approval-enabled host=node flows
Details

Summary

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.

Show details on source website

{
  "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:01
VLAI
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'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.

Show details on source website

{
  "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:32
VLAI
Details

Incorrect 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.

Show details on source website

{
  "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:31
VLAI
Details

The 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.

Show details on source website

{
  "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:49
VLAI
Summary
Ech0 Scope Bypass: profile:read Access Token Can Change Admin Password and Escalate to Unrestricted Session
Details

Summary

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 issueUserTokenCreateClaims, 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:

  1. Change the admin's password without any write-level scope, violating the principle of least privilege
  2. Escalate to a full unrestricted session token by logging in with the new credentials
  3. 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
  4. 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

Show details on source website

{
  "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:00
VLAI
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.

Show details on source website

{
  "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
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.