GHSA-3pww-vcvm-3gmj
MEDIUMGHSA-3pww-vcvm-3gmj is a medium-severity (CVSS 4.3) CWE-863 vulnerability in code.gitea.io/gitea. O3 Security confirms whether GHSA-3pww-vcvm-3gmj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gitea: API access token scope enforcement bypass on repository RSS/Atom feed endpoints leaks private repository commit data
Blast Radius
code.gitea.io/giteaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A Gitea personal access token (PAT) restricted to a non-repository scope (e.g. read:issue) can read the commit history of any private repository the token owner can access, via the repository RSS/Atom feed endpoints. The same token is correctly denied (403) on /raw, /media, /archive, and the contents API. It leaks commit SHAs, full commit messages (which frequently contain secrets and internal context), and committer name + email.
Details
Gitea enforces PAT scope on repository-content endpoints via checkDownloadTokenScope() (added in PR #37698, extended to the archive endpoint by the CVE-2026-20706 fix in 1.26.2). The RSS/Atom feed handlers were never included: they (a) opt into PAT auth via webAuth.AllowBasic, (b) serve private-repo content, but (c) never call checkDownloadTokenScope().
Affected handlers (all carry AllowBasic, none call the scope check):
RenderBranchFeedRSS/Atom-routers/web/feed/render.go(last 10 commits: SHA, title, full message, committer name + email)ShowFileFeed-routers/web/feed/file.go(per-file commit history)- repo activity feed
/{owner}/{repo}.rss/.atom TagsListFeedRSS/Atom,ReleasesFeedRSS/Atom-routers/web/repo/release.go
Root cause: routers/web/web.go registers the feed routes with webAuth.AllowBasic so a PAT authenticates, but the unit-permission middleware only checks the user's access, not the token's scope. checkDownloadTokenScope (routers/web/repo/download.go and the archive Download in repo.go) exists to close exactly that gap and is absent from the feed handlers. Same class as the recently fixed download/archive bypasses (GHSA-cr4g-f395-h25h / CVE-2026-20706); the feeds are the surface those fixes missed.
PoC
Tested on gitea/gitea:1.26.2-rootless, confirmed present at main HEAD (9608cc2, 2026-06-13).
- User
carolowns private repocarol/privwith a commit (message: "add confidential secret"). - Create a PAT scoped to issues only, no repository scope:
curl -u carol:PASS -X POST $HOST/api/v1/users/carol/tokens -d '{"name":"t","scopes":["read:issue"]}' - Scope-enforcing sibling correctly denies it:
curl -u carol:$TOK $HOST/carol/priv/raw/branch/main/secret.txt-> 403 - The feed leaks private data with the same token:
curl -u carol:$TOK $HOST/carol/priv/rss/branch/main-> 200, returns<description>add confidential secret ... this commit message itself is sensitive</description>
| Auth (same read:issue token) | /raw/branch/main/secret.txt | /rss/branch/main |
|---|---|---|
| anonymous | - | 404 (private repo hidden) |
| invalid token | - | 401 |
| read:issue token (no repo scope) | 403 (scope enforced) | 200 + private commit data |
| full-scope token | 200 | 200 (legitimate) |
Impact
PATs are routinely issued narrowly and handed to third-party bots, CI jobs, or chat integrations that are meant to have no code access. This bypass lets such a token exfiltrate private-repository commit history (messages often hold secrets, ticket refs, internal context) and committer emails for every repository the owner can read. Confidentiality only; no integrity or availability impact. Preconditions: a valid PAT of any non-repository scope owned by a user with read access to the target private repo, and feeds enabled (Other.EnableFeed, default ON).
Suggested fix: call checkDownloadTokenScope(ctx) at the start of each feed handler (mirroring download.go). Longer-term, enforce repository token scope in a single route-group middleware wherever AllowBasic / AllowOAuth2 is set on a repo-content route, so the next added endpoint cannot miss it.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.gitea.io/gitea | all versions | 1.26.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update code.gitea.io/gitea to 1.26.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3pww-vcvm-3gmj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3pww-vcvm-3gmj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3pww-vcvm-3gmj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3pww-vcvm-3gmj in your dependencies?
O3 detects GHSA-3pww-vcvm-3gmj across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.