CWE-863

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-95352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T18:17:28Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in DevTools in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted Chrome extension. (Chromium security severity: Low)",
  "id": "GHSA-hjvw-qq89-h873",
  "modified": "2026-09-30T15:31:13Z",
  "published": "2026-09-29T18:32:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95352"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0856730748.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/513791872"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "last_affected": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:57:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA collaborator removed from a project keeps a **live, automatic feed** of that project\u0027s contents, because nothing on any revocation path deletes the webhook they created while they had access.\n\nVikunja already has a revocation-cleanup routine that deletes other derived rows for exactly this reason. Its set is `{task_assignees, subscriptions}`. **`webhooks` and `link_shares` \u2014 the only two rows that carry a live channel into the project \u2014 are not in it**, and the routine is wired to one of four revocation paths.\n\n## Details\n\n`pkg/models/teams.go:411` \u2014 `cleanupTaskMembersAfterTeamRemoval`, added in `9358954c9`, whose commit message states the invariant: *\"cleanup team memberships, assignments and subscriptions when users lose access to a project\"*.\n\n```go\n\t\tcanRead, _, permErr := project.CanRead(s, \u0026user.User{ID: memberID})\n\t\t...\n\t\tif !canRead {\n\t\t\tprojectsToCleanup = append(projectsToCleanup, projectID)\n\t\t}\n\t...\n\t\t_, err = s.In(\"task_id\", taskIDs).And(\"user_id = ?\", memberID).\n\t\t\tDelete(\u0026TaskAssginee{})\n\t\t_, err = s.In(\"entity_id\", taskIDs).\n\t\t\tWhere(\"entity_type = ? AND user_id = ?\", SubscriptionEntityTask, memberID).\n\t\t\tDelete(\u0026Subscription{})\n\t_, err = s.In(\"entity_id\", projectsToCleanup).\n\t\tWhere(\"entity_type = ? AND user_id = ?\", SubscriptionEntityProject, memberID).\n\t\tDelete(\u0026Subscription{})\n```\n\nSo you have already decided that losing read access must delete rows the departing user left behind, and that the test is a live `project.CanRead`. The gap is which rows are in the set.\n\n**And there is a second level, which is the sharper one.** That routine has exactly one caller:\n\n```\npkg/models/listeners.go:1642    err = cleanupTaskMembersAfterTeamRemoval(s, event.Team.ID, event.Member.ID)\n```\n\nagainst four revocation paths:\n\n```\npkg/models/project_team.go:151   TeamProject.Delete\npkg/models/project_users.go:141  ProjectUser.Delete      \u003c- grep -c cleanup inside: 0\npkg/models/project_users.go:248  ProjectUser.Update      \u003c- the downgrade path\npkg/models/team_members.go:91    TeamMember.Delete       \u003c- the only one wired up\n```\n\nRemoving a user directly from a project \u2014 the ordinary operation \u2014 dispatches nothing at all.\n\n## PoC\n\nReleased `vikunja/vikunja:2.6.0` Docker image.\n\nThe harness was proved first by reproducing a **known-fixed** advisory: `GHSA-qfwc` refuses the read-only member and returns the hash to the owner. Every run carries its own negative control.\n\nThe strongest form is on the **team-removal path, where your cleanup routine does fire**:\n\n```\n== OWNER removes collab from the TEAM ==\n\n-- did the cleanup routine run? --\n  assignees now: []                            \u003c- POSITIVE CONTROL: it ran\n  collab direct read of task: HTTP 403         \u003c- NEGATIVE CONTROL: access is gone\n\n-- webhook still delivering? --\nWEBHOOK RECEIVED  task_title=\u0027post-team-removal secret\u0027\n                  task_desc=\u0027cleanup ran, webhook did not\u0027\n\n-- link share still redeemable? --\n[{\"title\":\"post-team-removal secret\",\"description\":\"cleanup ran, webhook did not\"}]\n```\n\nThe two controls are the argument: your own routine executed and removed the assignee rows, and the collaborator\u0027s direct read is refused with 403 \u2014 and the webhook created before removal still delivers the contents of a task created *after* it.\n\nOn the `ProjectUser.Delete` path the same thing happens with no cleanup running at all.\n\n**One lab accommodation, stated plainly**: non-routable outbound IPs were enabled so a loopback sink was reachable. In a default deployment an attacker simply uses a public URL, so this changes nothing about reachability.\n\n## Impact\n\nA former collaborator receives task titles and descriptions for the whole project, continuously, after their access has been revoked \u2014 including content created after revocation.\n\n**The honest counter-argument, which we would rather state than have you find.** Both artefacts stay **visible and auditable to the owner** afterwards: `GET /projects/{p}/webhooks` still shows `{\"created_by\":\"collab\"}` and `GET /projects/{p}/shares` still shows `{\"shared_by\":\"collab\"}`. An administrator reviewing project settings after an offboarding will find them. That is genuinely weaker than a silent channel, and it argues for the low end of Medium.\n\nThe precondition is also real: the attacker held write access, so they could have taken a snapshot before leaving. **The only thing new here is access to content created after revocation** \u2014 which is precisely the line you drew yourselves in `GHSA-jp29-jrxc-92vf`, *\"favourites readable after revocation\"*. We think it holds. It is also the entirety of the claim, and we are not dressing it up as more.\n\n## Affected range\n\n**All releases from `v0.22.0` through `v2.6.0`, and current `main`.**\n\nDetermined by checking the code at each released tag:\n\n```\nv0.22.0 \u2026 v0.24.6   webhooks.go=yes  cleanupRoutine=0\nv1.0.0  \u2026 v2.6.0    webhooks.go=yes  cleanupRoutine=1\n```\n\nProject webhooks arrive in `ad7d485eb` (2023-10-17), first released in v0.22.0. The cleanup routine arrives in `9358954c9` (2025-10-09), first released in v1.0.0, and has never included webhooks or link shares. Still present on `main` at `d822e1c58`: the routine contains only `Delete(\u0026TaskAssginee{})` and two `Delete(\u0026Subscription{})`, and `ProjectUser.Delete` contains zero dispatches.\n\nReproduced at v2.6.0; earlier versions asserted from source rather than run, and we are saying which is which.\n\n## Recommended Fix\n\nTwo changes, and they are independent \u2014 the first is the smaller one, the second is the one that closes the class.\n\n**Add the two row types to the cleanup set.** Alongside the existing `task_assignees` and `subscriptions` deletions, delete `webhooks` and `link_shares` whose `created_by` / `shared_by` is the departing user and whose project is in `projectsToCleanup`. The existing live `project.CanRead` test is already the right predicate.\n\n**Dispatch the cleanup from all four revocation paths**, not only team-member removal. `ProjectUser.Delete` and `ProjectUser.Update` (the downgrade case) are the common operations and currently fire nothing; `TeamProject.Delete` unshares a whole project from a team and is equally a revocation.\n\nA cheaper alternative for the second half, if reworking dispatch is unattractive: check `CanRead` for the webhook\u0027s `created_by` at delivery time, and for the share\u0027s `shared_by` at redemption time. That converts a cleanup problem into an authorization check on a path that already has the user id to hand.\n\n## Severity\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` \u2014 **6.5 Medium**.\n\nThis is **the identical vector you assigned to your own webhook advisory**, `GHSA-7c2g-p23p-4jg3` (webhook BasicAuth credentials exposed to read-only members), copied rather than argued. `PR:L` because the attacker must have been provisioned with project write at some point; `C:H` because the channel carries full task titles and descriptions for the whole project continuously \u2014 the same `C:H` you assigned there for a credential leak of narrower scope.\n\nThe auditability caveat above argues for the low end of Medium and we would not contest a lower score.\n\n### The link share is strictly more capable, and we are not leading with it\n\nThe same gap leaves a link share created by the departing collaborator redeemable after revocation, and a link share carries **read and write** \u2014 HTTP 201 demonstrated. On the same reasoning that would be `C:H/I:H` = 8.1 High.\n\nWe are deliberately **not** proposing that, and leading with the webhook instead, because a link share has a real *\"it is designed to be handed out\"* defence and the webhook does not. That judgement is yours to make, and if you decide the share is the more serious half we will not argue.",
  "id": "GHSA-hjx8-qv73-f7cm",
  "modified": "2026-10-09T20:57:41Z",
  "published": "2026-10-09T20:57:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-hjx8-qv73-f7cm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed"
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
}