CVE-2026-28699

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.

Details

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.

PoC

1. Create an OAuth2 application in Gitea.
2. Authorize it as a normal user with scope read:user only.
3. Take the resulting access token and call a write endpoint both ways:

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:

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:

• Modify the victim's profile and settings
• Add attacker-controlled email addresses to the victim's account
• Create repositories as the victim
• Modify or delete the victim's private repositories

The entire OAuth2 scope system is effectively bypassed for any token submitted via Basic auth.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-28699 has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.26.2); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-28699? CVE-2026-28699 is a high-severity incorrect authorization vulnerability in code.gitea.io/gitea (go), affecting versions <= 1.26.1. It is fixed in 1.26.2. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-28699? CVE-2026-28699 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of code.gitea.io/gitea are affected by CVE-2026-28699? code.gitea.io/gitea (go) versions <= 1.26.1 is affected.
4. Is there a fix for CVE-2026-28699? Yes. CVE-2026-28699 is fixed in 1.26.2. Upgrade to this version or later.
5. Is CVE-2026-28699 exploitable, and should I be worried? Whether CVE-2026-28699 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-28699 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-28699? Upgrade code.gitea.io/gitea to 1.26.2 or later.