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.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-7P4C-VMFG-G296

Vulnerability from github – Published: 2026-06-05 12:31 – Updated: 2026-06-06 03:31

Details

Improper authorization in AppBlock prior to SMR Jun-2026 Release 1 allows local attacker to launch arbitrary activity. User interaction is required for triggering this vulnerability.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

5.2 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-21031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-05T11:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in AppBlock prior to SMR Jun-2026 Release 1 allows local attacker to launch arbitrary activity. User interaction is required for triggering this vulnerability.",
  "id": "GHSA-7p4c-vmfg-g296",
  "modified": "2026-06-06T03:31:21Z",
  "published": "2026-06-05T12:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21031"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2026\u0026month=06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:L/VA:L/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-7P4H-3GXQ-X3H3

Vulnerability from github – Published: 2026-07-21 20:17 – Updated: 2026-09-24 15:53

Summary

Gitea: Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118

Details

Summary

After PR #37118 / CVE-2026-25714 (fix: Unify public-only token filtering in API queries and repo access checks, merged 2026-05-18, backport #37773 to 1.26.2 — the May 2026 unification pass for public-only token filtering, reporter Medoedus per the 1.26.2 release notes), the public-only PAT scope is still bypassable on Repository and Package scope categories when the owner's Visibility = Limited (instance-internal).

The sibling Org / User / ActivityPub cases in the same checkTokenPublicOnly switch correctly reject Limited owners via !Visibility.IsPublic(). The Repository / Package cases use repo.IsPrivate or Owner.Visibility.IsPrivate(), both of which return false for VisibleTypeLimited — so a public-only PAT strictly exceeds anonymous reach on a Limited owner.

Tested on gitea/gitea:1.26.2. The decisive marker is that PR #37118's unification IS applied in the version under test (User-category PROBE returns 403 "token scope is limited to public users"). Despite that, the Repository-category PROBE on the same Limited owner with the same PAT returns 200 and serves content.

Affected entry points (4 spots)

File:Line	Function	Affected surface
`routers/api/v1/api.go:292`	`checkTokenPublicOnly` Package case	API v1 packages
`routers/api/packages/api.go:76`	`reqPackageAccess` middleware	All 24 native package registries (`/api/packages/<type>/...`)
`services/context/api.go`	`TokenCanAccessRepo` helper	All API v1 Repository-category endpoints — content, issues, PRs, releases, labels, milestones, etc.
`services/context/permission.go:32`	`CheckTokenScopes` (called via `CheckRepoScopedToken`)	Web download endpoints `/raw`, `/media`, `/attachments`. LFS routes (`services/lfs/server.go:470/472`, `services/lfs/locks.go:62/151/216/284`) also chain through this helper.

All four sinks check repo.IsPrivate or Owner.Visibility.IsPrivate() only. VisibleTypeLimited falls through.

// modules/structs/visible_type.go
func (vt VisibleType) IsPrivate() bool { return vt == VisibleTypePrivate }   // line 39-40
func (vt VisibleType) IsLimited() bool { return vt == VisibleTypeLimited }   // line 33-34

Same-file evidence (`routers/api/v1/api.go:246-299` after PR #37118)

case auth_model.AccessTokenScopeCategoryOrganization:
    orgPrivate := ... && !ctx.Org.Organization.Visibility.IsPublic()        // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryUser:
    if ... && !ctx.ContextUser.Visibility.IsPublic() { ... }                // !IsPublic ✓
case auth_model.AccessTokenScopeCategoryActivityPub:
    if ... && !ctx.ContextUser.Visibility.IsPublic() { ... }                // !IsPublic ✓

case auth_model.AccessTokenScopeCategoryPackage:
    if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {     // IsPrivate ONLY ✗
        ctx.APIError(http.StatusForbidden, "token scope is limited to public packages")
        return
    }

TokenCanAccessRepo (services/context/api.go) reduces to !repo.IsPrivate:

// A public-only token cannot reach a private repo; any other token is unrestricted by this check.
func (ctx *APIContext) TokenCanAccessRepo(repo *repo_model.Repository) bool {
    return repo == nil || !ctx.PublicOnly || !repo.IsPrivate
}

CheckTokenScopes (services/context/permission.go:32):

if publicOnly && repo != nil && repo.IsPrivate {
    ctx.HTTPError(http.StatusForbidden)
    return
}

PoC (Docker e2e VERIFIED on `gitea/gitea:1.26.2`, 2026-06-05)

Full script in the report (run-poc.sh). Setup:

Create user limuser. PATCH /api/v1/admin/users/limuser with body {"visibility":"limited", ...} — response confirms "visibility":"limited".
Upload a generic package as limuser: PUT /api/packages/limuser/generic/secretpkg/1.0.0/secret.txt with body secret-content-internal-only → 201.
Create user attacker.
Mint PAT for attacker with scopes=["read:package","read:user","read:repository","public-only"].

Result on gitea/gitea:1.26.2 — nine PROBEs:

PROBE A  (download package via attacker PAT)
    HTTP=200  Body: secret-content-internal-only

PROBE C  (read README of limuser's PUBLIC repo)
    HTTP=200  Body: {"name":"README.md", ...}

PROBE F  (sanity — User category, same PAT, same owner)
    HTTP=403  Body: {"message":"token scope is limited to public users"}

PROBE G  (Repository category, same PAT, same owner)
    HTTP=200  Body: {"name":"README.md", ...}                    ← bypass

PROBE H  (list limuser's repos, User category)
    HTTP=403  Body: {"message":"token scope is limited to public users"}

PROBE M  (git HTTPS smart protocol — info/refs)
    HTTP=200  Body: 001e# service=git-upload-pack ... HEAD ...   ← full clone enabled

PROBE N  (write attempt: POST contents/hacked.txt)
    HTTP=403  Body: {"message":"user should have a permission to write to the target branch"}
                                                                    Integrity:N confirmed

PROBE O  (Limited ORG — same bypass class)
    Org category    : HTTP=403  {"message":"token scope is limited to public orgs"}
    Repo category   : HTTP=200  README content                  ← bypass

Anonymous baseline (no auth) on every above endpoint: HTTP=401/404

Gitea's own server error string in PROBE F / H / O — "token scope is limited to public users" / "public orgs" — is the explicit declaration of intent. Repository / Package category violates that intent on the same Limited owner.

Why this is not a duplicate of CVE-2026-25714

CVE-2026-25714 / PR #37118 (the May 2026 unification pass for public-only token filtering, merged 2026-05-18, backported to 1.26.2 via PR #37773) realigned checkTokenPublicOnly's Org / User / ActivityPub cases on !Visibility.IsPublic() and introduced the TokenCanAccessRepo helper for the Repository / Issue / Notification cases.

PROBE F on 1.26.2 returns 403 "token scope is limited to public users" for the User category — i.e. PR #37118's unification IS in effect on the version under test. The Repository / Package leak occurs after that fix; the Limited gap is the next residual issue on the same hygiene effort (the Package case was not touched, and TokenCanAccessRepo reduces to !repo.IsPrivate without consulting owner visibility), not the same bug.

Suggested fix (4 spots, 1-line shape each)

// routers/api/v1/api.go:292  (checkTokenPublicOnly Package case)
- if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {
+ if ctx.Package != nil && !ctx.Package.Owner.Visibility.IsPublic() {

// routers/api/packages/api.go:76  (reqPackageAccess middleware)
- if ctx.Package != nil && ctx.Package.Owner.Visibility.IsPrivate() {
+ if ctx.Package != nil && !ctx.Package.Owner.Visibility.IsPublic() {

// services/context/api.go  (TokenCanAccessRepo helper)
- return repo == nil || !ctx.PublicOnly || !repo.IsPrivate
+ return repo == nil || !ctx.PublicOnly ||
+     (!repo.IsPrivate && repo.Owner != nil && repo.Owner.Visibility.IsPublic())

// services/context/permission.go:32  (CheckTokenScopes)
- if publicOnly && repo != nil && repo.IsPrivate {
+ if publicOnly && repo != nil &&
+     (repo.IsPrivate || (repo.Owner != nil && !repo.Owner.Visibility.IsPublic())) {

This aligns the Repository / Package categories with the User / Org / ActivityPub siblings already shipped in PR #37118.

Reporter

JebeenLee

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "gitea.dev"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56443"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:17:19Z",
    "nvd_published_at": "2026-08-13T17:17:25Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAfter [PR #37118](https://github.com/go-gitea/gitea/pull/37118) / **CVE-2026-25714**\n(`fix: Unify public-only token filtering in API queries and repo access checks`,\nmerged 2026-05-18, backport `#37773` to 1.26.2 \u2014 the May 2026 unification pass\nfor public-only token filtering, reporter Medoedus per the 1.26.2 release notes),\nthe `public-only` PAT scope is still bypassable on **Repository** and **Package**\nscope categories when the owner\u0027s `Visibility = Limited` (instance-internal).\n\nThe sibling `Org` / `User` / `ActivityPub` cases in the same `checkTokenPublicOnly`\nswitch correctly reject Limited owners via `!Visibility.IsPublic()`. The\nRepository / Package cases use `repo.IsPrivate` or `Owner.Visibility.IsPrivate()`,\nboth of which return `false` for `VisibleTypeLimited` \u2014 so a `public-only` PAT\nstrictly exceeds anonymous reach on a Limited owner.\n\nTested on `gitea/gitea:1.26.2`. The decisive marker is that PR #37118\u0027s\nunification IS applied in the version under test (User-category PROBE returns\n`403 \"token scope is limited to public users\"`). Despite that, the\nRepository-category PROBE on the same Limited owner with the same PAT returns\n`200` and serves content.\n\n## Affected entry points (4 spots)\n\n| File:Line | Function | Affected surface |\n|---|---|---|\n| `routers/api/v1/api.go:292` | `checkTokenPublicOnly` Package case | API v1 packages |\n| `routers/api/packages/api.go:76` | `reqPackageAccess` middleware | All 24 native package registries (`/api/packages/\u003ctype\u003e/...`) |\n| `services/context/api.go` | `TokenCanAccessRepo` helper | All API v1 Repository-category endpoints \u2014 content, issues, PRs, releases, labels, milestones, etc. |\n| `services/context/permission.go:32` | `CheckTokenScopes` (called via `CheckRepoScopedToken`) | Web download endpoints `/raw`, `/media`, `/attachments`. LFS routes (`services/lfs/server.go:470/472`, `services/lfs/locks.go:62/151/216/284`) also chain through this helper. |\n\nAll four sinks check `repo.IsPrivate` or `Owner.Visibility.IsPrivate()` only.\n`VisibleTypeLimited` falls through.\n\n```go\n// modules/structs/visible_type.go\nfunc (vt VisibleType) IsPrivate() bool { return vt == VisibleTypePrivate }   // line 39-40\nfunc (vt VisibleType) IsLimited() bool { return vt == VisibleTypeLimited }   // line 33-34\n```\n\n## Same-file evidence (`routers/api/v1/api.go:246-299` after PR #37118)\n\n```go\ncase auth_model.AccessTokenScopeCategoryOrganization:\n    orgPrivate := ... \u0026\u0026 !ctx.Org.Organization.Visibility.IsPublic()        // !IsPublic \u2713\ncase auth_model.AccessTokenScopeCategoryUser:\n    if ... \u0026\u0026 !ctx.ContextUser.Visibility.IsPublic() { ... }                // !IsPublic \u2713\ncase auth_model.AccessTokenScopeCategoryActivityPub:\n    if ... \u0026\u0026 !ctx.ContextUser.Visibility.IsPublic() { ... }                // !IsPublic \u2713\n\ncase auth_model.AccessTokenScopeCategoryPackage:\n    if ctx.Package != nil \u0026\u0026 ctx.Package.Owner.Visibility.IsPrivate() {     // IsPrivate ONLY \u2717\n        ctx.APIError(http.StatusForbidden, \"token scope is limited to public packages\")\n        return\n    }\n```\n\n`TokenCanAccessRepo` (`services/context/api.go`) reduces to `!repo.IsPrivate`:\n\n```go\n// A public-only token cannot reach a private repo; any other token is unrestricted by this check.\nfunc (ctx *APIContext) TokenCanAccessRepo(repo *repo_model.Repository) bool {\n    return repo == nil || !ctx.PublicOnly || !repo.IsPrivate\n}\n```\n\n`CheckTokenScopes` (`services/context/permission.go:32`):\n\n```go\nif publicOnly \u0026\u0026 repo != nil \u0026\u0026 repo.IsPrivate {\n    ctx.HTTPError(http.StatusForbidden)\n    return\n}\n```\n\n## PoC (Docker e2e VERIFIED on `gitea/gitea:1.26.2`, 2026-06-05)\n\nFull script in the report (`run-poc.sh`). Setup:\n\n1. Create user `limuser`. `PATCH /api/v1/admin/users/limuser` with body\n   `{\"visibility\":\"limited\", ...}` \u2014 response confirms `\"visibility\":\"limited\"`.\n2. Upload a generic package as `limuser`:\n   `PUT /api/packages/limuser/generic/secretpkg/1.0.0/secret.txt` with body\n   `secret-content-internal-only` \u2192 `201`.\n3. Create user `attacker`.\n4. Mint PAT for `attacker` with `scopes=[\"read:package\",\"read:user\",\"read:repository\",\"public-only\"]`.\n\nResult on `gitea/gitea:1.26.2` \u2014 nine PROBEs:\n\n```\nPROBE A  (download package via attacker PAT)\n    HTTP=200  Body: secret-content-internal-only\n\nPROBE C  (read README of limuser\u0027s PUBLIC repo)\n    HTTP=200  Body: {\"name\":\"README.md\", ...}\n\nPROBE F  (sanity \u2014 User category, same PAT, same owner)\n    HTTP=403  Body: {\"message\":\"token scope is limited to public users\"}\n\nPROBE G  (Repository category, same PAT, same owner)\n    HTTP=200  Body: {\"name\":\"README.md\", ...}                    \u2190 bypass\n\nPROBE H  (list limuser\u0027s repos, User category)\n    HTTP=403  Body: {\"message\":\"token scope is limited to public users\"}\n\nPROBE M  (git HTTPS smart protocol \u2014 info/refs)\n    HTTP=200  Body: 001e# service=git-upload-pack ... HEAD ...   \u2190 full clone enabled\n\nPROBE N  (write attempt: POST contents/hacked.txt)\n    HTTP=403  Body: {\"message\":\"user should have a permission to write to the target branch\"}\n                                                                    Integrity:N confirmed\n\nPROBE O  (Limited ORG \u2014 same bypass class)\n    Org category    : HTTP=403  {\"message\":\"token scope is limited to public orgs\"}\n    Repo category   : HTTP=200  README content                  \u2190 bypass\n\nAnonymous baseline (no auth) on every above endpoint: HTTP=401/404\n```\n\nGitea\u0027s own server error string in PROBE F / H / O \u2014 *\"token scope is limited\nto public users\"* / *\"public orgs\"* \u2014 is the explicit declaration of intent.\nRepository / Package category violates that intent on the same Limited owner.\n\n## Why this is not a duplicate of CVE-2026-25714\n\nCVE-2026-25714 / PR #37118 (the May 2026 unification pass for public-only token\nfiltering, merged 2026-05-18, backported to 1.26.2 via PR #37773) realigned\n`checkTokenPublicOnly`\u0027s Org / User / ActivityPub cases on `!Visibility.IsPublic()`\nand introduced the `TokenCanAccessRepo` helper for the Repository / Issue /\nNotification cases.\n\nPROBE F on `1.26.2` returns `403 \"token scope is limited to public users\"` for\nthe User category \u2014 i.e. PR #37118\u0027s unification IS in effect on the version\nunder test. The Repository / Package leak occurs *after* that fix; the Limited\ngap is the next residual issue on the same hygiene effort (the Package case was\nnot touched, and `TokenCanAccessRepo` reduces to `!repo.IsPrivate` without\nconsulting owner visibility), not the same bug.\n\n## Suggested fix (4 spots, 1-line shape each)\n\n```go\n// routers/api/v1/api.go:292  (checkTokenPublicOnly Package case)\n- if ctx.Package != nil \u0026\u0026 ctx.Package.Owner.Visibility.IsPrivate() {\n+ if ctx.Package != nil \u0026\u0026 !ctx.Package.Owner.Visibility.IsPublic() {\n\n// routers/api/packages/api.go:76  (reqPackageAccess middleware)\n- if ctx.Package != nil \u0026\u0026 ctx.Package.Owner.Visibility.IsPrivate() {\n+ if ctx.Package != nil \u0026\u0026 !ctx.Package.Owner.Visibility.IsPublic() {\n\n// services/context/api.go  (TokenCanAccessRepo helper)\n- return repo == nil || !ctx.PublicOnly || !repo.IsPrivate\n+ return repo == nil || !ctx.PublicOnly ||\n+     (!repo.IsPrivate \u0026\u0026 repo.Owner != nil \u0026\u0026 repo.Owner.Visibility.IsPublic())\n\n// services/context/permission.go:32  (CheckTokenScopes)\n- if publicOnly \u0026\u0026 repo != nil \u0026\u0026 repo.IsPrivate {\n+ if publicOnly \u0026\u0026 repo != nil \u0026\u0026\n+     (repo.IsPrivate || (repo.Owner != nil \u0026\u0026 !repo.Owner.Visibility.IsPublic())) {\n```\n\nThis aligns the Repository / Package categories with the User / Org / ActivityPub\nsiblings already shipped in PR #37118.\n## Reporter\n\nJebeenLee",
  "id": "GHSA-7p4h-3gxq-x3h3",
  "modified": "2026-09-24T15:53:00Z",
  "published": "2026-07-21T20:17:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-7p4h-3gxq-x3h3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56443"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/gitea-1.27.0-is-released"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Gitea: Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) \u2014 residual after CVE-2026-25714 / PR #37118"
}

GHSA-7P7Q-VPQ8-MW97

Vulnerability from github – Published: 2026-09-30 18:33 – Updated: 2026-09-30 18:33

Details

In JetBrains YouTrack before 2026.2.19197 users with restricted permission could edit and hide other users' comments

Severity

4.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-100278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-30T16:16:59Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains YouTrack before 2026.2.19197 users with restricted permission could edit and hide other users\u0027 comments",
  "id": "GHSA-7p7q-vpq8-mw97",
  "modified": "2026-09-30T18:33:32Z",
  "published": "2026-09-30T18:33:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100278"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7PPP-WJ75-4MF7

Vulnerability from github – Published: 2026-09-08 18:31 – Updated: 2026-09-08 18:31

Details

A security issue exists in MongoDB's LDAP authorization integration where pooled LDAP connections can retain stale authentication identities after user authentication under certain configurations. Subsequent authorization queries may execute under an unintended LDAP identity rather than the expected one. This can result in incorrect role assignments based on the LDAP directory's access control configuration, potentially allowing an authenticated user to acquire elevated privileges that were not intended by the deployment's authorization policy.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

7.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-82053"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T17:18:33Z",
    "severity": "HIGH"
  },
  "details": "A security issue exists in MongoDB\u0027s LDAP authorization integration where pooled LDAP connections can retain stale authentication identities after user authentication under certain configurations. Subsequent authorization queries may execute under an unintended LDAP identity rather than the expected one. This can result in incorrect role assignments based on the LDAP directory\u0027s access control configuration, potentially allowing an authenticated user to acquire elevated privileges that were not intended by the deployment\u0027s authorization policy.",
  "id": "GHSA-7ppp-wj75-4mf7",
  "modified": "2026-09-08T18:31:57Z",
  "published": "2026-09-08T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82053"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-130785"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/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"
    }
  ]
}

GHSA-7PQP-MWC5-PQ7F

Vulnerability from github – Published: 2026-09-02 00:31 – Updated: 2026-09-02 21:32

Details

Incorrect authorization in SiteSettings in Google Chrome prior to 152.0.7977.75 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-84332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T00:18:28Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in SiteSettings in Google Chrome prior to 152.0.7977.75 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-7pqp-mwc5-pq7f",
  "modified": "2026-09-02T21:32:02Z",
  "published": "2026-09-02T00:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84332"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/514489238"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7Q22-X757-CMGC

Vulnerability from github – Published: 2024-11-29 21:31 – Updated: 2024-12-03 21:36

Withdrawn 2024-12-03

Summary

Withdrawn Advisory: Symfony http-security has authentication bypass

Details

Withdrawn Advisory

This advisory has been withdrawn because the report is not part of a valid vulnerability. This link is maintained to preserve external references. For more information, see advisory-database/pull/5046.

Original Description

In Symfony, a security vulnerability was identified in the FormLoginAuthenticator component, where it failed to adequately handle cases where the username or password field of a login request is empty. This flaw could lead to various security risks, including improper authentication logic handling or denial of service.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

6.8 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:U

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/security-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-36611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-02T20:21:10Z",
    "nvd_published_at": "2024-11-29T19:15:06Z",
    "severity": "MODERATE"
  },
  "details": "## Withdrawn Advisory\nThis advisory has been withdrawn because the report is not part of a valid vulnerability. This link is maintained to preserve external references. For more information, see advisory-database/pull/5046.\n\n## Original Description\nIn Symfony, a security vulnerability was identified in the FormLoginAuthenticator component, where it failed to adequately handle cases where the username or password field of a login request is empty. This flaw could lead to various security risks, including improper authentication logic handling or denial of service.",
  "id": "GHSA-7q22-x757-cmgc",
  "modified": "2024-12-03T21:36:47Z",
  "published": "2024-11-29T21:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36611"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/issues/59077#issuecomment-2513935018"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/5046"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/a804ca15fcad279d7727b91d12a667fd5b925995"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/1047524396/3581425e0911b716cf8ce4fa30e41e6c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/blob/v7.0.7/src/Symfony/Component/Security/Http/Authenticator/FormLoginAuthenticator.php#L132"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Withdrawn Advisory: Symfony http-security has authentication bypass",
  "withdrawn": "2024-12-03T16:07:27Z"
}

GHSA-7Q2H-F39X-VGG4

Vulnerability from github – Published: 2023-03-20 18:30 – Updated: 2023-03-23 21:30

Details

The ProfileGrid WordPress plugin before 5.3.1 provides an AJAX endpoint for resetting a user password but does not implement proper authorization. This allows a user with low privileges, such as subscriber, to change the password of any account, including Administrator ones.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-0940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-20T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "The ProfileGrid WordPress plugin before 5.3.1 provides an AJAX endpoint for resetting a user password but does not implement proper authorization. This allows a user with low privileges, such as subscriber, to change the password of any account, including Administrator ones.",
  "id": "GHSA-7q2h-f39x-vgg4",
  "modified": "2023-03-23T21:30:21Z",
  "published": "2023-03-20T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0940"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/56744f72-2d48-4f42-8195-24b4dd951bb5"
    }
  ],
  "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"
    }
  ]
}

GHSA-7Q37-3M9H-F5MP

Vulnerability from github – Published: 2026-09-16 21:32 – Updated: 2026-09-16 21:32

Details

Twenty before 2.35.0 fails to validate field and row permissions in the groupBy-with-records GraphQL resolver, allowing authenticated users to bypass permission checks. Attackers with canReadObjectRecords permission but canReadFieldValue false can retrieve restricted field values through the groupBy resolver that would normally be denied.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-92771"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T21:17:25Z",
    "severity": "HIGH"
  },
  "details": "Twenty before 2.35.0 fails to validate field and row permissions in the groupBy-with-records GraphQL resolver, allowing authenticated users to bypass permission checks. Attackers with canReadObjectRecords permission but canReadFieldValue false can retrieve restricted field values through the groupBy resolver that would normally be denied.",
  "id": "GHSA-7q37-3m9h-f5mp",
  "modified": "2026-09-16T21:32:53Z",
  "published": "2026-09-16T21:32:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92771"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twentyhq/twenty/issues/25911"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twentyhq/twenty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twentyhq/twenty/blob/twenty/v2.14.0/packages/twenty-server/src/engine/api/graphql/graphql-query-runner/group-by/services/group-by-with-records.service.ts#L243"
    },
    {
      "type": "WEB",
      "url": "https://github.com/twentyhq/twenty/blob/twenty/v2.14.0/packages/twenty-server/src/engine/twenty-orm/repository/permissions.utils.ts#L47-L53"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/twenty-before-2.35.0-permission-bypass-via-groupby-with-records-query"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/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"
    }
  ]
}

GHSA-7Q3F-WX44-378M

Vulnerability from github – Published: 2026-10-01 15:26 – Updated: 2026-10-01 15:26

Summary

vm2: External module allowlist uses a raw prefix test, so a prefix-sharing sibling package is treated as allowlisted

Details

Summary

isPathAllowedForModule decides whether a resolved path belongs to an allowlisted external module using a raw string prefix test. node_modules/foo2 starts with node_modules/foo, so a package whose name merely shares a prefix with an allowlisted one is treated as being inside it, and a relative require from the allowlisted package reaches it even with transitive loading disabled.

Where it is

lib/resolver-compat.js, lines 122 to 132, quoted from HEAD 7a1f5100b96f48d34e0fe104ab37c0acc5944f92:

isPathAllowedForModule(path, mod) {
    if (!super.isPathAllowed(path)) return false;
    if (mod) {
        if (mod.allowTransitive) return true;
        if (path.startsWith(mod.path)) {
            const rem = path.slice(mod.path.length);
            if (!/(?:^|[\\/])node_modules(?:$|[\\/])/.test(rem)) return true;
        }
    }
    return this.externals.some(regex => regex.test(path));
}

With mod.path of .../node_modules/foo and a resolved path of .../node_modules/foo2/index.js, startsWith is true and rem is 2/index.js, which contains no node_modules segment, so the function returns true.

The node_modules test in rem is what stops a genuine transitive dependency from slipping through. It does not stop a sibling, because a sibling's remainder never contains that segment.

Impact

Code running in NodeVM under an external module allowlist with transitive: false can reach a package that was not allowlisted, provided an allowlisted package performs a relative require to a prefix-sharing sibling.

Two preconditions are worth stating plainly rather than leaving implicit. The deployment must already have such a package layout, and an allowlisted package must have a reachable code path that does the relative require. This is not something the attacker creates; it is something they find. That narrows it considerably, and it is why I have not scored it higher.

Reachability

NodeVM.run at lib/nodevm.js:506 executes the script. require comes from createRequireForModule at lib/setup-node-sandbox.js:168-172 and reaches the resolver callback at lib/nodevm.js:380-384. LegacyResolver.resolveFull at lib/resolver-compat.js:145-160 sets currMod for direct requires, the relative specifier resolves through DefaultResolver.resolveFull and tryFile at lib/resolver.js:327-330, and the authorization decision lands on the function above.

Suggested fix

Require a separator after the prefix, so a sibling cannot match:

if (path === mod.path || path.startsWith(mod.path + path.sep)) {

That is the same anchoring the rem regex already applies to node_modules, applied one level earlier.

Severity

4.2 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:26:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`isPathAllowedForModule` decides whether a resolved path belongs to an allowlisted external module using a raw string prefix test. `node_modules/foo2` starts with `node_modules/foo`, so a package whose name merely shares a prefix with an allowlisted one is treated as being inside it, and a relative require from the allowlisted package reaches it even with transitive loading disabled.\n\n## Where it is\n\n`lib/resolver-compat.js`, lines 122 to 132, quoted from HEAD `7a1f5100b96f48d34e0fe104ab37c0acc5944f92`:\n\n```js\nisPathAllowedForModule(path, mod) {\n    if (!super.isPathAllowed(path)) return false;\n    if (mod) {\n        if (mod.allowTransitive) return true;\n        if (path.startsWith(mod.path)) {\n            const rem = path.slice(mod.path.length);\n            if (!/(?:^|[\\\\/])node_modules(?:$|[\\\\/])/.test(rem)) return true;\n        }\n    }\n    return this.externals.some(regex =\u003e regex.test(path));\n}\n```\n\nWith `mod.path` of `.../node_modules/foo` and a resolved path of `.../node_modules/foo2/index.js`, `startsWith` is true and `rem` is `2/index.js`, which contains no `node_modules` segment, so the function returns true.\n\nThe `node_modules` test in `rem` is what stops a genuine transitive dependency from slipping through. It does not stop a sibling, because a sibling\u0027s remainder never contains that segment.\n\n## Impact\n\nCode running in `NodeVM` under an external module allowlist with `transitive: false` can reach a package that was not allowlisted, provided an allowlisted package performs a relative require to a prefix-sharing sibling.\n\nTwo preconditions are worth stating plainly rather than leaving implicit. The deployment must already have such a package layout, and an allowlisted package must have a reachable code path that does the relative require. This is not something the attacker creates; it is something they find. That narrows it considerably, and it is why I have not scored it higher.\n\n## Reachability\n\n`NodeVM.run` at `lib/nodevm.js:506` executes the script. `require` comes from `createRequireForModule` at `lib/setup-node-sandbox.js:168-172` and reaches the resolver callback at `lib/nodevm.js:380-384`. `LegacyResolver.resolveFull` at `lib/resolver-compat.js:145-160` sets `currMod` for direct requires, the relative specifier resolves through `DefaultResolver.resolveFull` and `tryFile` at `lib/resolver.js:327-330`, and the authorization decision lands on the function above.\n\n## Suggested fix\n\nRequire a separator after the prefix, so a sibling cannot match:\n\n```js\nif (path === mod.path || path.startsWith(mod.path + path.sep)) {\n```\n\nThat is the same anchoring the `rem` regex already applies to `node_modules`, applied one level earlier.",
  "id": "GHSA-7q3f-wx44-378m",
  "modified": "2026-10-01T15:26:45Z",
  "published": "2026-10-01T15:26:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-7q3f-wx44-378m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92945"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/6ac3916da84e060c403e407b6b6318fcc66b0e72"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-module-allowlist-bypass-via-prefix-matching"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2: External module allowlist uses a raw prefix test, so a prefix-sharing sibling package is treated as allowlisted"
}

GHSA-7Q3H-63X4-WQWG

Vulnerability from github – Published: 2026-09-26 15:31 – Updated: 2026-09-26 15:31

Details

ClawHub (openclaw/clawhub) contains an incorrect authorization vulnerability in the ClawHub application/backend: an organization-owned skill retains the ownerUserId of its original publisher, and transfer and lifecycle authorization checks trust that historical user before requiring current organization privileges. An authenticated user who originally published an organization skill can therefore transfer, delete, or restore that skill — taking control of its trusted name and history — even after their organization privileges have been revoked or downgraded. The issue was confirmed at revision cbfee7343ddc867316dd9b3de6fa8856730f9f41; the complete historical affected range was not established. It is fixed by PR #3680, included in revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650, which was deployed to clawhub.ai on 2026-09-11; self-hosted deployments should update to that revision or a later descendant. The npm CLI and OpenClaw runtime are separate products and are not affected.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-100604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T14:16:40Z",
    "severity": "MODERATE"
  },
  "details": "ClawHub (openclaw/clawhub) contains an incorrect authorization vulnerability in the ClawHub application/backend: an organization-owned skill retains the ownerUserId of its original publisher, and transfer and lifecycle authorization checks trust that historical user before requiring current organization privileges. An authenticated user who originally published an organization skill can therefore transfer, delete, or restore that skill \u2014 taking control of its trusted name and history \u2014 even after their organization privileges have been revoked or downgraded. The issue was confirmed at revision cbfee7343ddc867316dd9b3de6fa8856730f9f41; the complete historical affected range was not established. It is fixed by PR #3680, included in revision 8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650, which was deployed to clawhub.ai on 2026-09-11; self-hosted deployments should update to that revision or a later descendant. The npm CLI and OpenClaw runtime are separate products and are not affected.",
  "id": "GHSA-7q3h-63x4-wqwg",
  "modified": "2026-09-26T15:31:13Z",
  "published": "2026-09-26T15:31:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/clawhub/security/advisories/GHSA-9558-q4f9-324f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100604"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/clawhub/commit/8c2de6c506bb4efabe3f0c2ffb8370b9e23d4650"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/clawhub-authentication-bypass-via-former-publisher-skill-control"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI: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"
    }
  ]
}

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.

← Back to the CWE list

CWE-863

Incorrect Authorization

Summary

Affected entry points (4 spots)

Same-file evidence (routers/api/v1/api.go:246-299 after PR #37118)

PoC (Docker e2e VERIFIED on gitea/gitea:1.26.2, 2026-06-05)

Why this is not a duplicate of CVE-2026-25714

Suggested fix (4 spots, 1-line shape each)

Reporter

Withdrawn Advisory

Original Description

Summary

Where it is

Impact

Reachability

Suggested fix

Mitigation

Mitigation

Mitigation MIT-4.4

Mitigation

Mitigation

Same-file evidence (`routers/api/v1/api.go:246-299` after PR #37118)

PoC (Docker e2e VERIFIED on `gitea/gitea:1.26.2`, 2026-06-05)