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.

5659 vulnerabilities reference this CWE, most recent first.

GHSA-7MQQ-4V55-88GH

Vulnerability from github – Published: 2026-06-26 23:10 – Updated: 2026-06-26 23:10
VLAI
Summary
Statamic CMS's incorrect authorization lets view-only users submit Live Preview content reserved for editors
Details

Impact

The Live Preview endpoint for existing entries and terms only checked view authorization, but it accepts and renders caller-supplied field values. A Control Panel user with view but not edit permission could therefore submit content they were not authorized to author and generate a shareable Live Preview URL rendering it.

Patches

This has been fixed in 5.74.0 and 6.20.3.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "statamic/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.74.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "statamic/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.20.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:10:37Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\n\nThe Live Preview endpoint for existing entries and terms only checked view authorization, but it accepts and renders caller-supplied field values. A Control Panel user with view but not edit permission could therefore submit content they were not authorized to author and generate a shareable Live Preview URL rendering it.\n\n### Patches\n\nThis has been fixed in 5.74.0 and 6.20.3.",
  "id": "GHSA-7mqq-4v55-88gh",
  "modified": "2026-06-26T23:10:37Z",
  "published": "2026-06-26T23:10:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/statamic/cms/security/advisories/GHSA-7mqq-4v55-88gh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/statamic/cms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Statamic CMS\u0027s incorrect authorization lets view-only users submit Live Preview content reserved for editors"
}

GHSA-7P28-JCMX-86M5

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-09 09:31
VLAI
Details

The CloudStack Backup plugin has an improper authorization logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and has access to specific APIs can list backups from any account in the environment. This vulnerability does not allow them to see the contents of the backup.

Users are recommended to upgrade to version 4.22.0.1, which fixes the issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-66170"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T13:16:35Z",
    "severity": "MODERATE"
  },
  "details": "The CloudStack Backup plugin has an improper authorization logic in versions 4.21.0.0 and 4.22.0.0. Anyone with authenticated user-account access in CloudStack 4.21.0.0+ environments, where this plugin is enabled and has access to specific APIs can list backups from any account in the environment. This vulnerability does not allow them to see the contents of the backup.\n\nUsers are recommended to upgrade to version 4.22.0.1, which fixes the issue.",
  "id": "GHSA-7p28-jcmx-86m5",
  "modified": "2026-05-09T09:31:44Z",
  "published": "2026-05-08T15:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66170"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/n8mt5b7wkpysstb8w7rr9f02kc5cq2xm"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/09/1"
    }
  ],
  "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"
    }
  ]
}

GHSA-7P2G-2VXC-5G55

Vulnerability from github – Published: 2024-12-27 21:30 – Updated: 2025-01-02 17:22
VLAI
Summary
Letta (previously MemGPT) incorrect access control vulnerability
Details

Incorrect access control in the /users endpoint of Cpacker MemGPT v0.3.17 allows attackers to access sensitive data.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "letta"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-39025"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-02T17:22:57Z",
    "nvd_published_at": "2024-12-27T20:15:23Z",
    "severity": "HIGH"
  },
  "details": "Incorrect access control in the /users endpoint of Cpacker MemGPT v0.3.17 allows attackers to access sensitive data.",
  "id": "GHSA-7p2g-2vxc-5g55",
  "modified": "2025-01-02T17:22:57Z",
  "published": "2024-12-27T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39025"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/letta-ai/letta"
    },
    {
      "type": "WEB",
      "url": "https://github.com/letta-ai/letta/blob/0.3.17/memgpt/server/rest_api/admin/users.py#L55-L68"
    },
    {
      "type": "WEB",
      "url": "https://github.com/letta-ai/letta/releases/tag/0.3.17"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@cnetsec/a-vulnerability-cve-2024-39025-has-been-identified-in-lettaai-memgpt-v0-3-17-146cb38bb6db"
    }
  ],
  "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": "Letta (previously MemGPT) incorrect access control vulnerability"
}

GHSA-7P4C-VMFG-G296

Vulnerability from github – Published: 2026-06-05 12:31 – Updated: 2026-06-06 03:31
VLAI
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.

Show details on source website

{
  "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-07-21 20:17
VLAI
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:

  1. Create user limuser. PATCH /api/v1/admin/users/limuser with body {"visibility":"limited", ...} — response confirms "visibility":"limited".
  2. Upload a generic package as limuser: PUT /api/packages/limuser/generic/secretpkg/1.0.0/secret.txt with body secret-content-internal-only201.
  3. Create user attacker.
  4. 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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "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": null,
    "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-07-21T20:17:19Z",
  "published": "2026-07-21T20:17:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-7p4h-3gxq-x3h3"
    },
    {
      "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-7Q22-X757-CMGC

Vulnerability from github – Published: 2024-11-29 21:31 – Updated: 2024-12-03 21:36
VLAI
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.

Show details on source website

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

Show details on source website

{
  "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-7Q4R-XVH7-HJ22

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

Improper authorization in GitLab 12.8+ allows a guest user in a private project to view tag data that should be inaccessible on the releases page

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-26T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in GitLab 12.8+ allows a guest user in a private project to view tag data that should be inaccessible on the releases page",
  "id": "GHSA-7q4r-xvh7-hj22",
  "modified": "2022-05-24T17:45:32Z",
  "published": "2022-05-24T17:45:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22172"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/833334"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22172.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/212911"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7Q54-G3H8-W6W7

Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42
VLAI
Details

IBM Remote Control v9 could allow a local user to use the component to replace files to which he does not have write access and which he can cause to be executed with Local System or root privileges. IBM X-Force ID: 123912.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-1233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-31T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Remote Control v9 could allow a local user to use the component to replace files to which he does not have write access and which he can cause to be executed with Local System or root privileges. IBM X-Force ID: 123912.",
  "id": "GHSA-7q54-g3h8-w6w7",
  "modified": "2022-05-13T01:42:39Z",
  "published": "2022-05-13T01:42:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1233"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/123912"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=swg22011765"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7Q5J-QGX2-V324

Vulnerability from github – Published: 2022-04-08 00:00 – Updated: 2022-04-14 00:00
VLAI
Details

An unauthorized file deletion vulnerability in Telesquare TLR-2855KS6 via DELETE method can allow deletion of system files and scripts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-46419"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-07T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An unauthorized file deletion vulnerability in Telesquare TLR-2855KS6 via DELETE method can allow deletion of system files and scripts.",
  "id": "GHSA-7q5j-qgx2-v324",
  "modified": "2022-04-14T00:00:27Z",
  "published": "2022-04-08T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46419"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/drive/folders/1TWw3Oy0wZImSHK_hj-tKkbn9sFgqqySp"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/166675/Telesquare-TLR-2855KS6-Arbitrary-File-Deletion.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.