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.

5631 vulnerabilities reference this CWE, most recent first.

GHSA-9Q2P-VC84-2RWM

Vulnerability from github – Published: 2026-03-09 19:54 – Updated: 2026-03-09 19:54
VLAI
Summary
OpenClaw: system.run allow-always persistence included shell-commented payload tails
Details

OpenClaw's system.run allowlist analysis did not honor POSIX shell comment semantics when deriving allow-always persistence entries.

A caller in security=allowlist mode who received an allow-always decision could submit a shell command whose tail was commented out at runtime, for example by using an unquoted # before a chained payload. The runtime shell would execute only the pre-comment portion, but allowlist persistence could still analyze and store the non-executed tail as a trusted follow-up command.

Latest published npm version: 2026.3.2

Fixed on main on March 7, 2026 in 939b18475d734ed75173f59507e3ebbdfe1992b7 by teaching shell tokenization and chain/pipeline analysis to stop at unquoted shell comments, so allow-always persistence now tracks only commands that the shell can actually execute. Normal real chained commands and quoted # literals continue to work.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.3.2
  • Patched version: >= 2026.3.7

Fix Commit(s)

  • 939b18475d734ed75173f59507e3ebbdfe1992b7

Release Process Note

npm 2026.3.7 was published on March 8, 2026. This advisory is fixed in the released package.

Thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-09T19:54:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "OpenClaw\u0027s `system.run` allowlist analysis did not honor POSIX shell comment semantics when deriving `allow-always` persistence entries.\n\nA caller in `security=allowlist` mode who received an `allow-always` decision could submit a shell command whose tail was commented out at runtime, for example by using an unquoted `#` before a chained payload. The runtime shell would execute only the pre-comment portion, but allowlist persistence could still analyze and store the non-executed tail as a trusted follow-up command.\n\nLatest published npm version: `2026.3.2`\n\nFixed on `main` on March 7, 2026 in `939b18475d734ed75173f59507e3ebbdfe1992b7` by teaching shell tokenization and chain/pipeline analysis to stop at unquoted shell comments, so allow-always persistence now tracks only commands that the shell can actually execute. Normal real chained commands and quoted `#` literals continue to work.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.3.2`\n- Patched version: `\u003e= 2026.3.7`\n\n## Fix Commit(s)\n\n- `939b18475d734ed75173f59507e3ebbdfe1992b7`\n\n## Release Process Note\n\nnpm `2026.3.7` was published on March 8, 2026. This advisory is fixed in the released package.\n\nThanks @tdjackey for reporting.",
  "id": "GHSA-9q2p-vc84-2rwm",
  "modified": "2026-03-09T19:54:46Z",
  "published": "2026-03-09T19:54:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-9q2p-vc84-2rwm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/939b18475d734ed75173f59507e3ebbdfe1992b7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: system.run allow-always persistence included shell-commented payload tails"
}

GHSA-9Q36-67VC-RRWG

Vulnerability from github – Published: 2026-03-09 19:54 – Updated: 2026-03-30 13:31
VLAI
Summary
OpenClaw: Sandboxed /acp spawn requests could initialize host ACP sessions
Details

Summary

Sandboxed requester sessions could reach host-side ACP session initialization through /acp spawn.

OpenClaw already blocked sessions_spawn({ runtime: "acp" }) from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first.

Affected Packages / Versions

  • npm package: openclaw
  • Affected versions: <= 2026.3.2
  • Patched version: >= 2026.3.7

Details

ACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in src/agents/acp-spawn.ts already denied sandboxed requesters, but /acp spawn in src/auto-reply/reply/commands-acp/lifecycle.ts called initializeSession(...) without first applying the same restriction.

In affected versions, an already authorized sender in a sandboxed session could use /acp spawn to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available.

Fix Commit(s)

  • 61000b8e4ded919ca1a825d4700db4cb3fdc56e3

Fix Details

The fix introduced a shared ACP runtime-policy guard in src/agents/acp-spawn.ts and reused it from the /acp spawn handler in src/auto-reply/reply/commands-acp/lifecycle.ts before any ACP backend initialization. Regression coverage was added in src/auto-reply/reply/commands-acp.test.ts to prove sandboxed /acp spawn requests are rejected early, while existing ACP spawn behavior for non-sandboxed sessions remains unchanged.

Release Process Note

Patched version is pre-set to 2026.3.7 so the advisory can be published once that npm release is available.

Thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27646"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-09T19:54:54Z",
    "nvd_published_at": "2026-03-23T22:16:25Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nSandboxed requester sessions could reach host-side ACP session initialization through `/acp spawn`.\n\nOpenClaw already blocked `sessions_spawn({ runtime: \"acp\" })` from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first.\n\n### Affected Packages / Versions\n- npm package: `openclaw`\n- Affected versions: `\u003c= 2026.3.2`\n- Patched version: `\u003e= 2026.3.7`\n\n### Details\nACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in `src/agents/acp-spawn.ts` already denied sandboxed requesters, but `/acp spawn` in `src/auto-reply/reply/commands-acp/lifecycle.ts` called `initializeSession(...)` without first applying the same restriction.\n\nIn affected versions, an already authorized sender in a sandboxed session could use `/acp spawn` to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available.\n\n### Fix Commit(s)\n- `61000b8e4ded919ca1a825d4700db4cb3fdc56e3`\n\n### Fix Details\nThe fix introduced a shared ACP runtime-policy guard in `src/agents/acp-spawn.ts` and reused it from the `/acp spawn` handler in `src/auto-reply/reply/commands-acp/lifecycle.ts` before any ACP backend initialization. Regression coverage was added in `src/auto-reply/reply/commands-acp.test.ts` to prove sandboxed `/acp spawn` requests are rejected early, while existing ACP spawn behavior for non-sandboxed sessions remains unchanged.\n\n### Release Process Note\nPatched version is pre-set to `2026.3.7` so the advisory can be published once that npm release is available.\n\nThanks @tdjackey for reporting.",
  "id": "GHSA-9q36-67vc-rrwg",
  "modified": "2026-03-30T13:31:02Z",
  "published": "2026-03-09T19:54:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-9q36-67vc-rrwg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/61000b8e4ded919ca1a825d4700db4cb3fdc56e3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.7"
    },
    {
      "type": "WEB",
      "url": "https://vulncheck.com/advisories/openclaw-mar-sandbox-escape-via-acp-spawn-command"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Sandboxed /acp spawn requests could initialize host ACP sessions"
}

GHSA-9Q9W-F94C-RXWX

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33
VLAI
Details

u'Improper authorization in DSP process could allow unauthorized users to downgrade the library versions in SD820, SD821, SD820, QCS603, QCS605, SDA855, SA6155P, SA6145P, SA6155, SA6155P, SD855, SD 675, SD660, SD429, SD439

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-11209"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-12T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "u\u0027Improper authorization in DSP process could allow unauthorized users to downgrade the library versions in SD820, SD821, SD820, QCS603, QCS605, SDA855, SA6155P, SA6145P, SA6155, SA6155P, SD855, SD 675, SD660, SD429, SD439",
  "id": "GHSA-9q9w-f94c-rxwx",
  "modified": "2022-05-24T17:33:31Z",
  "published": "2022-05-24T17:33:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11209"
    },
    {
      "type": "WEB",
      "url": "https://blog.checkpoint.com/2020/08/06/achilles-small-chip-big-peril"
    },
    {
      "type": "WEB",
      "url": "https://research.checkpoint.com/2021/pwn2own-qualcomm-dsp"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/november-2020-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9QC3-P9JQ-2X27

Vulnerability from github – Published: 2023-09-06 15:30 – Updated: 2023-09-06 20:53
VLAI
Summary
Apache Superset users may incorrectly create resources using the import charts feature
Details

A non Admin authenticated user could incorrectly create resources using the import charts feature, on Apache Superset up to and including 2.1.0. 

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-superset"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-27526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-06T20:53:39Z",
    "nvd_published_at": "2023-09-06T13:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A non Admin authenticated user could incorrectly create resources using the import charts feature, on Apache Superset up to and including 2.1.0.\u00a0\n",
  "id": "GHSA-9qc3-p9jq-2x27",
  "modified": "2023-09-06T20:53:39Z",
  "published": "2023-09-06T15:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27526"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/superset"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/ndww89yl2jd98lvn23n9cj722lfdg8dv"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache Superset users may incorrectly create resources using the import charts feature "
}

GHSA-9QX4-M255-P25G

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2024-04-04 00:24
VLAI
Details

The BrowseProjects.jspa resource in Jira before version 7.13.2, and from version 8.0.0 before version 8.0.2 allows remote attackers to see information for archived projects through a missing authorisation check.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-3399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-30T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "The BrowseProjects.jspa resource in Jira before version 7.13.2, and from version 8.0.0 before version 8.0.2 allows remote attackers to see information for archived projects through a missing authorisation check.",
  "id": "GHSA-9qx4-m255-p25g",
  "modified": "2024-04-04T00:24:25Z",
  "published": "2022-05-24T16:44:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3399"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-69246"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9R5X-FJV3-Q6H4

Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2024-05-21 14:35
VLAI
Summary
Duplicate Advisory: Incorrect Access Control in github.com/nats-io/jwt and github.com/nats-io/nats-server/v2
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-62mh-w5cv-p88c (for github.com/nats-io/jwt) and GHSA-j756-f273-xhp4 (for github.com/nats-io/nats-server). This link is maintained to preserve external references.

Original Description

NATS Server (github.com/nats-io/nats-server/v2/server) 2.x before 2.2.0 and JWT library (github.com/nats-io/jwt/v2) before 2.0.1 have Incorrect Access Control because Import Token bindings are mishandled.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/jwt/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.3-0.20210314221642-a826c77dc9d2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-12T20:34:10Z",
    "nvd_published_at": "2021-03-16T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-62mh-w5cv-p88c (for github.com/nats-io/jwt) and GHSA-j756-f273-xhp4 (for github.com/nats-io/nats-server). This link is maintained to preserve external references.\n\n## Original Description\nNATS Server (github.com/nats-io/nats-server/v2/server) 2.x before 2.2.0 and JWT library (github.com/nats-io/jwt/v2) before 2.0.1 have Incorrect Access Control because Import Token bindings are mishandled.",
  "id": "GHSA-9r5x-fjv3-q6h4",
  "modified": "2024-05-21T14:35:21Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3127"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/pull/149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/jwt/pull/149/commits/a826c77dc9d2671c961b75ceefdb439c41029866"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/commit/423b79440c80c863de9f4e20548504e6c5d5e403"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/CVE-2021-3127.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Incorrect Access Control in github.com/nats-io/jwt and github.com/nats-io/nats-server/v2",
  "withdrawn": "2024-05-21T14:35:21Z"
}

GHSA-9R5X-WG6M-X2RC

Vulnerability from github – Published: 2026-06-16 23:40 – Updated: 2026-06-16 23:40
VLAI
Summary
Gitea: OAuth2 access token scope enforcement bypass via HTTP Basic authentication
Details

Summary

Gitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only read:user can use the same token as Authorization: Basic base64(<token>:x-oauth-basic) and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.

Details

Root cause: services/auth/basic.go accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:

// services/auth/basic.go
if uid != 0 {
    store.GetData()["LoginMethod"] = OAuth2TokenMethodName
    store.GetData()["IsApiToken"] = true   // scope is NOT set
    return u, nil
}

The scope enforcement middleware in routers/api/v1/api.go exits early when ApiTokenScope is absent:

// routers/api/v1/api.go — tokenRequiresScopes
scope, scopeExists := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
if ctx.Data["IsApiToken"] != true || !scopeExists {
    return   //<- exits without checking scope, all actions permitted
}

When a token arrives via Bearer, ApiTokenScope is populated and scope checks apply normally. When the same token arrives via Basic auth, ApiTokenScope is never set, so tokenRequiresScopes returns immediately and no scope is enforced.

Suggested fix: When an OAuth2 access token is accepted in services/auth/basic.go, populate ApiTokenScope in the request context identically to the Bearer-token OAuth2 path.

PoC

  1. Create an OAuth2 application in Gitea.
  2. Authorize it as a normal user with scope read:user only.
  3. Take the resulting access token and call a write endpoint both ways:

Bearer | correctly blocked:

Authorization: Bearer <token>
PATCH /api/v1/user/settings  ->  403 Forbidden

Basic | bypass:

Authorization: Basic base64(<token>:x-oauth-basic)
PATCH /api/v1/user/settings  ->  200 OK

All verified bypass endpoints using a read:user-only token:

Endpoint Bearer Basic
PATCH /api/v1/user/settings 403 200
POST /api/v1/user/emails 403 200
POST /api/v1/user/repos 403 200
PATCH /api/v1/repos/{owner}/{repo} 403 200
DELETE /api/v1/repos/{owner}/{repo} 403 200

The bypass respects the user's normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.

Impact

Any OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:

  • Modify the victim's profile and settings
  • Add attacker-controlled email addresses to the victim's account
  • Create repositories as the victim
  • Modify or delete the victim's private repositories

The entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.26.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T23:40:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nGitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only `read:user` can use the same token as `Authorization: Basic base64(\u003ctoken\u003e:x-oauth-basic)` and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.\n\n### Details\n\n**Root cause:** `services/auth/basic.go` accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:\n\n```go\n// services/auth/basic.go\nif uid != 0 {\n    store.GetData()[\"LoginMethod\"] = OAuth2TokenMethodName\n    store.GetData()[\"IsApiToken\"] = true   // scope is NOT set\n    return u, nil\n}\n```\n\nThe scope enforcement middleware in `routers/api/v1/api.go` exits early when `ApiTokenScope` is absent:\n\n```go\n// routers/api/v1/api.go \u2014 tokenRequiresScopes\nscope, scopeExists := ctx.Data[\"ApiTokenScope\"].(auth_model.AccessTokenScope)\nif ctx.Data[\"IsApiToken\"] != true || !scopeExists {\n    return   //\u003c- exits without checking scope, all actions permitted\n}\n```\n\nWhen a token arrives via Bearer, `ApiTokenScope` is populated and scope checks apply normally. When the same token arrives via Basic auth, `ApiTokenScope` is never set, so `tokenRequiresScopes` returns immediately and no scope is enforced.\n\n**Suggested fix:** When an OAuth2 access token is accepted in `services/auth/basic.go`, populate `ApiTokenScope` in the request context identically to the Bearer-token OAuth2 path.\n\n### PoC\n\n1. Create an OAuth2 application in Gitea.\n2. Authorize it as a normal user with scope `read:user` only.\n3. Take the resulting access token and call a write endpoint both ways:\n\n**Bearer | correctly blocked:**\n```\nAuthorization: Bearer \u003ctoken\u003e\nPATCH /api/v1/user/settings  -\u003e  403 Forbidden\n```\n\n**Basic | bypass:**\n```\nAuthorization: Basic base64(\u003ctoken\u003e:x-oauth-basic)\nPATCH /api/v1/user/settings  -\u003e  200 OK\n```\n\n**All verified bypass endpoints using a `read:user`-only token:**\n\n| Endpoint | Bearer | Basic |\n|---|---|---|\n| `PATCH /api/v1/user/settings` | 403 | 200 |\n| `POST /api/v1/user/emails` | 403 | 200 |\n| `POST /api/v1/user/repos` | 403 | 200 |\n| `PATCH /api/v1/repos/{owner}/{repo}` | 403 | 200 |\n| `DELETE /api/v1/repos/{owner}/{repo}` | 403 | 200 |\n\nThe bypass respects the user\u0027s normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.\n\n### Impact\n\nAny OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:\n\n- Modify the victim\u0027s profile and settings\n- Add attacker-controlled email addresses to the victim\u0027s account\n- Create repositories as the victim\n- Modify or delete the victim\u0027s private repositories\n\nThe entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.",
  "id": "GHSA-9r5x-wg6m-x2rc",
  "modified": "2026-06-16T23:40:34Z",
  "published": "2026-06-16T23:40:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-9r5x-wg6m-x2rc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: OAuth2 access token scope enforcement bypass via HTTP Basic authentication"
}

GHSA-9R69-X87G-5765

Vulnerability from github – Published: 2026-06-15 15:31 – Updated: 2026-06-15 15:31
VLAI
Details

WordPress Ultimate Product Catalog 3.8.6 contains an arbitrary file upload vulnerability that allows authenticated users with contributor, editor, author, or administrator roles to upload malicious files by exploiting the custom fields functionality. Attackers can upload PHP shells through the Products tab custom file field and access them via the upcp-product-file-uploads directory to execute arbitrary code on the server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-20075"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T14:16:30Z",
    "severity": "HIGH"
  },
  "details": "WordPress Ultimate Product Catalog 3.8.6 contains an arbitrary file upload vulnerability that allows authenticated users with contributor, editor, author, or administrator roles to upload malicious files by exploiting the custom fields functionality. Attackers can upload PHP shells through the Products tab custom file field and access them via the upcp-product-file-uploads directory to execute arbitrary code on the server.",
  "id": "GHSA-9r69-x87g-5765",
  "modified": "2026-06-15T15:31:32Z",
  "published": "2026-06-15T15:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-20075"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/40012"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wordpress-ultimate-product-catalog-arbitrary-file-upload-rce"
    },
    {
      "type": "WEB",
      "url": "http://www.EtoileWebDesign.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9R89-C96G-GF22

Vulnerability from github – Published: 2023-02-18 00:31 – Updated: 2023-02-28 21:30
VLAI
Details

TOTOLINK A720R V4.1.5cu.532_ B20210610 is vulnerable to Incorrect Access Control.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-23064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-17T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "TOTOLINK A720R V4.1.5cu.532_ B20210610 is vulnerable to Incorrect Access Control.",
  "id": "GHSA-9r89-c96g-gf22",
  "modified": "2023-02-28T21:30:16Z",
  "published": "2023-02-18T00:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23064"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shellpei/TOTOLINK-Unauthorized/blob/main/CVE-2023-23064"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9R8R-X3VG-6XH4

Vulnerability from github – Published: 2026-05-15 21:31 – Updated: 2026-06-09 00:01
VLAI
Summary
Duplicate Advisory: phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-jrc5-w569-h7h5. This link is maintained to preserve external references.

Original Description

phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpMyFAQ/phpMyFAQ"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpMyFAQ"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:53:52Z",
    "nvd_published_at": "2026-05-15T19:17:01Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-jrc5-w569-h7h5. This link is maintained to preserve external references.\n\n### Original Description\nphpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.",
  "id": "GHSA-9r8r-x3vg-6xh4",
  "modified": "2026-06-09T00:01:42Z",
  "published": "2026-05-15T21:31:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-jrc5-w569-h7h5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45009"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpMyFAQ"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/phpmyfaq-insufficient-authorization-check-in-admin-api-endpoints"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check",
  "withdrawn": "2026-06-09T00:01:42Z"
}

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.