EUVD-2026-41640
GHSA-9r5x-wg6m-x2rc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAttacker hosts malicious OAuth2 app
-
DeliveryVictim authorizes app with read:user scope
-
ExploitAttacker captures access token
-
ExecutionRe-encode token as Basic auth header
-
PersistCall write API endpoints
-
ImpactModify emails or delete victim repositories
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the Gitea instance to have the OAuth2 provider feature enabled and at least one OAuth2 application registered and authorized by a target user, yielding a valid OAuth2 access token that the attacker controls (e.g., via operating a malicious OAuth2 app, phishing the authorization flow, or stealing an existing token). The attacker must be able to send authenticated HTTP requests to the Gitea API (PR:L) but no user interaction is needed beyond the initial OAuth2 consent already obtained. Exploitation is strictly bounded by the authorizing user's existing permissions - it does not escalate to admin and does not grant access to repositories the user cannot otherwise reach - and is fully mitigated on instances running Gitea 1.26.2 or later. |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, 8.1 High) accurately reflects a network-reachable, low-complexity bypass requiring an existing OAuth2 token (PR:L) with high confidentiality and integrity impact but no availability impact - the attacker cannot exceed the authorizing user's underlying permissions, so blast radius is bounded by that user's account and repositories. No EPSS, KEV, or SSVC data was supplied; CISA KEV is not asserted and no public exploit identified at time of analysis, though a step-by-step reproducer is published in the GHSA advisory itself, which lowers the barrier to weaponization. Real priority is elevated for any Gitea instance that hosts third-party OAuth2 apps (especially public-facing or multi-tenant deployments), because a single malicious or compromised OAuth2 app obtaining a minimally-scoped token can repurpose it for full write access to the victim's account and repos. |
| Exploit ScenarioDerived | A user installs or authorizes a seemingly benign third-party OAuth2 application against the organization's Gitea instance, granting only |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 17, 2026
OAuth2 scope enforcement bypass in Gitea <= 1.26.1 allows any OAuth2 access token to perform write actions far beyond its granted scope when submitted via HTTP Basic authentication instead of as a Bearer token. A token issued with only read:user can modify user settings, add attacker-controlled emails, and create or delete the user's repositories, effectively nullifying the entire OAuth2 scope model for Basic-auth requests. No public exploit identified at time of analysis, but the advisory itself contains a full working PoC.
RemediationAI
Vendor-released patch: upgrade Gitea to 1.26.2 or later, as published in GHSA-9r5x-wg6m-x2rc (https://github.com/go-gitea/gitea/security/advisories/GHSA-9r5x-wg6m-x2rc). If immediate patching is not possible, the most effective compensating control is to disable the OAuth2 provider feature in app.ini ([oauth2] ENABLED = false) so no scope-limited OAuth2 tokens exist that could be abused - note this breaks any third-party application integrations that rely on Gitea as an OAuth2 identity provider. As an alternative, audit and revoke existing OAuth2 application authorizations via Site Administration so untrusted apps cannot retain tokens, and consider fronting the API with a reverse proxy rule that strips or rejects Authorization: Basic headers on /api/v1/ (this will also break legitimate username/password and personal-access-token Basic auth use, so weigh the operational impact). Until upgrade, treat any previously issued OAuth2 token as equivalent to a full-write user PAT for the authorizing user.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea is a self-hosted Git service written in Go. The flaw lives in services/auth/basic.go, which authenticates OAuth2 access tokens passed through the HTTP Basic auth path but never populates the ApiTokenScope key in the request context. The downstream middleware tokenRequiresScopes in routers/api/v1/api.go short-circuits and returns without checking any scope whenever ApiTokenScope is absent, so all API actions are permitted. This is a CWE-284 (Improper Access Control) issue: scope metadata that is correctly attached on the Bearer-token code path is silently dropped on the Basic-auth code path, producing inconsistent authorization enforcement for the same credential. The affected package is pkg:go/code.gitea.io_gitea.
Know when Gitea gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Network API call (AV:N), no special conditions (AC:L), requires a valid OAuth2 token so PR:L, no user interaction post-consent; high C and I via profile/email/repo writes, no availability impact since deletion is scoped to the user's own repos.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
DescriptionCVE.org
Summary
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
- Create an OAuth2 application in Gitea.
- Authorize it as a normal user with scope
read:useronly. - Take the resulting access token and call a write endpoint both ways:
Bearer | correctly blocked:
Authorization: Bearer <token>
PATCH /api/v1/user/settings -> 403 ForbiddenBasic | bypass:
Authorization: Basic base64(<token>:x-oauth-basic)
PATCH /api/v1/user/settings -> 200 OKAll 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.
Impact
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.
Executive ViewAI
Gitea versions up to 1.26.1 contain a high-severity OAuth2 authentication bypass (CVSS 8.1) that allows any valid OAuth2 token to perform write operations beyond its granted scope when submitted via HTTP Basic authentication; no public exploit identified at time of analysis, but the advisory includes a working proof-of-concept. This vulnerability completely nullifies Gitea's OAuth2 access control, enabling attackers with even read-only tokens to modify user accounts, add malicious email addresses, and delete all repositories. Organizations using Gitea with OAuth2 authentication face immediate risk of unauthorized code repository access, data destruction, and account compromise.
Disable HTTP Basic authentication for OAuth2 token submissions; configure Gitea to accept OAuth2 tokens exclusively via Bearer token authorization. Implement network-level access controls and IP whitelisting for Gitea instances. Enable detailed API audit logging and alerting on scope escalation attempts. Restrict OAuth2 scope grants to minimum required permissions per application. No vendor-released patch identified at time of analysis; if OAuth2 is not essential, temporarily disable it as interim mitigation until patched version becomes available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
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
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
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
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Important| 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 |
Exploit-DB