CVE-2026-28699High· 8.1▾ MidnightPoC availableGitea: OAuth2 access token scope enforcement bypass via HTTP Basic authentication
▾ Midnight zone — Critical, or high with PoC / in-the-wild
impact 44.6 · likelihood 0.1 · exploitation 12
A public proof-of-concept already exists for this vulnerability — see Exploit availability below.
Public exploit / PoC code seen in 1 source. Availability, not in-the-wild use.
Exploit-prediction probability, daily snapshots since Jul 4.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.6%
0.6% → 0.6%
1 GitHub repo
Gitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only read:user can use the same token as Authorization: Basic base64(<token>:x-oauth-basic) and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.
Root cause: services/auth/basic.go accepts OAuth2 access tokens through the Basic auth path but does not store the token scope in the request context:
// services/auth/basic.go
if uid != 0 {
store.GetData()["LoginMethod"] = OAuth2TokenMethodName
store.GetData()["IsApiToken"] = true // scope is NOT set
return u, nil
}
The scope enforcement middleware in routers/api/v1/api.go exits early when ApiTokenScope is absent:
// routers/api/v1/api.go — tokenRequiresScopes
scope, scopeExists := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
if ctx.Data["IsApiToken"] != true || !scopeExists {
return //<- exits without checking scope, all actions permitted
}
When a token arrives via Bearer, ApiTokenScope is populated and scope checks apply normally. When the same token arrives via Basic auth, ApiTokenScope is never set, so tokenRequiresScopes returns immediately and no scope is enforced.
Suggested fix: When an OAuth2 access token is accepted in services/auth/basic.go, populate ApiTokenScope in the request context identically to the Bearer-token OAuth2 path.
read:user only.Bearer | correctly blocked:
Authorization: Bearer <token>
PATCH /api/v1/user/settings -> 403 Forbidden
Basic | bypass:
Authorization: Basic base64(<token>:x-oauth-basic)
PATCH /api/v1/user/settings -> 200 OK
All verified bypass endpoints using a read:user-only token:
| Endpoint | Bearer | Basic |
|---|---|---|
PATCH /api/v1/user/settings | 403 | 200 |
POST /api/v1/user/emails | 403 | 200 |
POST /api/v1/user/repos | 403 | 200 |
PATCH /api/v1/repos/{owner}/{repo} | 403 | 200 |
DELETE /api/v1/repos/{owner}/{repo} | 403 | 200 |
The bypass respects the user's normal repository permissions, it does not grant access to repositories the user cannot otherwise reach, and does not escalate to admin.
Any OAuth2 application with any restricted scope can silently operate beyond its granted permissions by switching from Bearer to Basic auth. An attacker who obtains a token (e.g. via a malicious OAuth2 app a user authorized) can:
The entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.
code.gitea.io/gitea <= 1.26.1Upgrade to a patched release:
code.gitea.io/gitea 1.26.2Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-58424High· 8.9Gitea: Permanent Fork PR Workflow Approval Gate Bypass
CVE-2026-58429Medium· 4.9Gitea: Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints
CVE-2026-55987High· 8.1Gitea: OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)
CVE-2026-58437High· 7.1Gitea: Repository Visibility Manipulation via Git Push Options
CVE-2026-58422HighGitea: Improper authorization on OAuth sign-in callback silently re-enables administrator-disabled accounts
CVE-2026-57897Medium· 6.5Gitea: Cross-Repo Information Disclosure via Org-Level Actions Run/Job APIs