CVE-2026-28699: 
Gitea Analyse et atténuation des vulnérabilités

CVE-2026-28699 is an OAuth2 access token scope enforcement bypass vulnerability in Gitea that allows an authenticated attacker to perform write actions using a token granted only read-level scopes. By submitting an OAuth2 access token via HTTP Basic authentication (as Authorization: Basic base64(<token>:x-oauth-basic)) instead of a Bearer token, the scope enforcement middleware is bypassed entirely. All Gitea versions up to and including 1.26.1 are affected; version 1.26.2 contains the fix. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Gitea Advisory). The advisory was published on June 5, 2026, and added to the GitHub Advisory Database on June 16, 2026.

The root cause is classified as CWE-284 (Improper Access Control) and CWE-863 (Incorrect Authorization). In services/auth/basic.go, when an OAuth2 access token is recognized via the Basic auth path, the code sets IsApiToken = true but never populates ApiTokenScope in the request context. The scope enforcement middleware in routers/api/v1/api.go (tokenRequiresScopes) checks for the presence of ApiTokenScope and exits immediately if it is absent — effectively granting unrestricted access. When the same token is submitted as a Bearer token, ApiTokenScope is correctly populated and scope checks apply normally. A public proof-of-concept repository demonstrating the bypass has been published (GitHub Advisory, Gitea Advisory).

Successful exploitation allows any OAuth2 application holding a restricted-scope token (e.g., read:user) to silently perform write operations as the authorizing user, including modifying user profiles and settings, adding attacker-controlled email addresses, creating repositories, and modifying or deleting private repositories. The bypass does not escalate privileges beyond the user's existing repository permissions and does not grant administrative access, but it completely undermines the OAuth2 scope model for all tokens submitted via Basic auth. This poses significant confidentiality and integrity risks, particularly in multi-tenant or enterprise Gitea deployments where OAuth2 applications are used by third parties (GitHub Advisory).

1. Obtain an OAuth2 token: Register or use an existing OAuth2 application in the target Gitea instance. Convince a target user to authorize the application with a restricted scope such as read:user only.
2. Retrieve the access token: After authorization, capture the resulting OAuth2 access token from the OAuth2 flow.
3. Encode the token for Basic auth: Construct the Basic auth credential by base64-encoding <token>:x-oauth-basic (e.g., echo -n '<token>:x-oauth-basic' | base64).
4. Send a write request via Basic auth: Issue an API request to a write endpoint using the Basic auth header instead of Bearer, for example:

   PATCH /api/v1/user/settings
   Authorization: Basic <base64(token:x-oauth-basic)>

5. Confirm bypass: The server returns 200 OK instead of 403 Forbidden, confirming that scope enforcement was bypassed. Additional write endpoints such as POST /api/v1/user/emails, POST /api/v1/user/repos, PATCH /api/v1/repos/{owner}/{repo}, and DELETE /api/v1/repos/{owner}/{repo} are also accessible (GitHub Advisory, Gitea Advisory).

• Network: API requests to write endpoints (PATCH /api/v1/user/settings, POST /api/v1/user/emails, POST /api/v1/user/repos, PATCH /api/v1/repos/{owner}/{repo}, DELETE /api/v1/repos/{owner}/{repo}) using Authorization: Basic headers where the decoded credential matches the pattern <token>:x-oauth-basic.
• Logs: Gitea access logs showing successful 200 OK responses to write API endpoints from OAuth2 tokens authenticated via Basic auth rather than Bearer; unexpected repository creation, deletion, or profile modification events in audit logs attributed to OAuth2 application tokens.
• Application Behavior: Unexpected email addresses added to user accounts; repositories created, modified, or deleted without corresponding user-initiated actions; user profile or settings changes not initiated by the account owner.

Gitea has released version 1.26.2 which patches this vulnerability by ensuring that ApiTokenScope is populated in the request context when an OAuth2 access token is accepted via the Basic auth path, consistent with the Bearer token path. All users running Gitea 1.26.1 or earlier should upgrade to 1.26.2 immediately. No configuration-based workaround is available; upgrading is the only remediation. Administrators should also audit OAuth2 application authorizations and review recent API activity logs for signs of scope bypass (GitHub Advisory, Gitea Advisory).

The vulnerability was reported by researcher "Alardiians" and published by Gitea maintainer "lunny" on June 5, 2026. A public PoC repository was subsequently released by the reporter. The Gitea release blog announced version 1.26.2 addressing this and related issues. FreeBSD ports and GitLab's advisory tracker also picked up the vulnerability, indicating broad ecosystem awareness (Gitea Blog, GitLab Advisory).