EUVD-2026-41623
GHSA-8629-vc8r-5p58
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
PR:L because a valid API token is required; C:L because only organization membership metadata leaks, with no integrity or availability impact.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Lifecycle Timeline
2DescriptionCVE.org
Summary
Two related issues in the token public-only scope enforcement introduced by PR #32204 (CVE-2025-68941 fix). A public-only scoped API token can access private organization data.
Issue 1: /user/orgs missing checkTokenPublicOnly()
routers/api/v1/api.go line 1599:
m.Get("/user/orgs", reqToken(), tokenRequiresScopes(
auth_model.AccessTokenScopeCategoryUser,
auth_model.AccessTokenScopeCategoryOrganization,
), org.ListMyOrgs)
// Missing checkTokenPublicOnly()Adjacent route at line 1603 has it:
m.Group("/users/{username}/orgs", func() { ... },
..., checkTokenPublicOnly())Issue 2: checkTokenPublicOnly switch-case evaluates only first matching category
routers/api/v1/api.go lines 253-295. Go switch executes only the first matching case. For routes with categories [User, Organization]:
- Organization case matches first (line 263)
- ctx.Org.Organization is nil on user routes, passes
- ctx.ContextUser.IsOrganization() is false, passes
- User case (line 273) is never reached
- User visibility check skipped entirely
Steps to Reproduce
- Create a token with public-only scope (Settings > Applications > check "public only")
- Call:
curl -H "Authorization: token <PUBLIC_ONLY_TOKEN>" https://gitea.example.com/api/v1/user/orgs - Response includes private and limited-visibility organizations
Expected: only public organizations returned.
Impact
Public-only scoped tokens can enumerate private organizations the token owner belongs to. Violates the token's declared scope constraints.
Suggested Fix
- Add
checkTokenPublicOnly()to/user/orgsroute at line 1599 - Replace switch with loop over all categories so User visibility check is not skipped
Version
Current main branch, commit 2c2d7e6 (April 3, 2026).
AnalysisAI
Public-only scoped API tokens in Gitea bypass their declared scope constraints and expose private organization membership data through two distinct code defects in routers/api/v1/api.go: the /user/orgs route omits the checkTokenPublicOnly() middleware entirely, and the checkTokenPublicOnly function contains a Go switch-case logic flaw that skips the user-visibility check on multi-category routes. This is an incomplete remediation of CVE-2025-68941 introduced by PR #32204, affecting all Gitea instances running version 1.26.1 and earlier. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the attack is trivially reproducible from the published advisory steps.
Technical ContextAI
Gitea is a self-hosted Git service written in Go, and this vulnerability is rooted in its API routing middleware layer. Issue 1 is a straightforward omission: the route handler for GET /user/orgs at line 1599 of routers/api/v1/api.go applies reqToken() and tokenRequiresScopes() but is missing the checkTokenPublicOnly() call present on the adjacent /users/{username}/orgs group at line 1603. Issue 2 is a structural logic flaw: checkTokenPublicOnly (lines 253-295) uses a Go switch statement over scope categories; because Go switch evaluates only the first matching case, routes requiring both [User, Organization] categories hit the Organization branch first. On user-context routes, ctx.Org.Organization is nil and ctx.ContextUser.IsOrganization() is false, so the Organization case passes vacuously and the function returns without ever reaching the User visibility check. The root cause class is CWE-862 (Missing Authorization) - the access control gate is either absent from the route or structurally unreachable. The affected Go module is code.gitea.io/gitea, CPE pkg:go/code.gitea.io_gitea.
RemediationAI
Upgrade to Gitea 1.26.2, which is confirmed as the fixed release per the advisory package data at https://github.com/go-gitea/gitea/security/advisories/GHSA-8629-vc8r-5p58. The fix requires both adding checkTokenPublicOnly() to the /user/orgs route at line 1599 and replacing the switch-case in checkTokenPublicOnly with a loop that evaluates all scope categories, ensuring the user-visibility check is never skipped. If immediate upgrade to 1.26.2 is not feasible, the most targeted compensating control is to audit and revoke any API tokens currently configured with the 'public only' scope, replacing them with appropriately scoped tokens under tighter access policies - this eliminates the specific token type exploited by this flaw, though it removes the intended least-privilege boundary. Network-level restrictions on API endpoint access reduce exposure surface but do not address the logic flaw. No other documented workarounds are available from the advisory.
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulne
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access t
Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today