EUVD-2026-41644
GHSA-cc8w-r4qh-3v65
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain low-scope PAT or OAuth2 token
-
DeliveryIdentify target private repo where token owner has RBAC
-
ExploitSend Git Smart HTTP request with Authorization: Bearer header
-
ExecutionBypass CheckRepoScopedToken scope enforcement
-
PersistClone/fetch private repo or push via git-receive-pack
-
ImpactExfiltrate source or tamper with repository contents
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Attacker must possess a valid Gitea PAT or OAuth2 access token for an account that already has normal RBAC (read or write) on the target repository - the bug bypasses token scope, not user permissions. The target Gitea instance must be at version 1.26.1 or earlier with Git Smart HTTP enabled (default) and accessible to the attacker. Exploitation requires sending the token via the |
| Impact | CVSS 3.1 base score is 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), reflecting network reach, low complexity, low privileges (a valid token of any scope) and high confidentiality and integrity impact. The vulnerability is not listed in CISA KEV, has no published EPSS data in the input, and no public weaponized exploit beyond the GHSA-cc8w-r4qh-3v65 advisory PoC test case. The real-world risk is bounded by the impact statement from the reporter: an attacker cannot reach repositories the token's owning user could not already reach via RBAC, so the bug breaks scope isolation rather than user isolation. The practical priority is therefore highest for Gitea operators who issue narrow-scope PATs to users, CI systems, or third-party integrations under the assumption that scope (e.g. read:notification, read:user) excludes repository access - that assumption is false on 1.26.1 and earlier when Bearer auth is used. Confidentiality and integrity for private repositories is the meaningful risk; A:N is consistent because there is no DoS angle. |
| Exploit ScenarioDerived | An attacker who has obtained a low-privilege PAT - for example a token issued for read:notification to a chatops integration, a leaked CI token, or a token phished from a developer - sends |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 17, 2026
Authorization scope bypass in Gitea v1.26.1 and earlier allows authenticated users to use OAuth2/PAT Bearer tokens to perform Git Smart HTTP clone, fetch, and push operations on private repositories without holding the required read:repository or write:repository token scopes. The flaw stems from CheckRepoScopedToken() short-circuiting unless ctx.IsBasicAuth is true, while the same route accepts Bearer authentication. No public exploit identified at time of analysis beyond the reporter's PoC test in the GHSA advisory.
RemediationAI
Vendor-released patch: upgrade to Gitea 1.26.2 or later, per GHSA-cc8w-r4qh-3v65 (https://github.com/go-gitea/gitea/security/advisories/GHSA-cc8w-r4qh-3v65). If immediate upgrade is not possible, revoke and reissue narrow-scope PATs and OAuth2 tokens that you do not want to grant repository read or write access (the bypass requires a valid token, so reducing the population of low-scope tokens shrinks exploitation surface). As a stronger compensating control, restrict Git Smart HTTP authentication to Basic only by terminating Bearer Authorization headers at a fronting reverse proxy (nginx/Traefik) for /info/refs, /git-upload-pack, and /git-receive-pack paths - trade-off: this breaks any legitimate clients that authenticate to Git over Bearer. Reviewing audit logs for clone/fetch/push operations authenticated with Bearer tokens whose scope does not include read:repository or write:repository will surface prior abuse; rotate any tokens identified in such activity.
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 Go-based Git service. The vulnerability lives in services/context/permission.go where CheckRepoScopedToken() guards repository-scoped Personal Access Token (PAT) and OAuth2 scope enforcement, and in routers/web/repo/githttp.go which invokes it for Git Smart HTTP (git-upload-pack and git-receive-pack) endpoints. The route is registered with both webAuth.AllowBasic and webAuth.AllowOAuth2 handlers; the OAuth2 path in services/auth/oauth2.go correctly populates IsApiToken and ApiTokenScope in the session store, but CheckRepoScopedToken() returns early if ctx.IsBasicAuth is false, so the recorded scope is ignored for Bearer requests. This is a textbook CWE-863 (Incorrect Authorization) - a check exists but is applied inconsistently across authentication transports, breaking the token-scope boundary while user-level RBAC still applies. Affected component is the Go package code.gitea.io/gitea (CPE 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
Exploitation requires any valid user token (PR:L), is network-reachable with a single header swap (AV:N/AC:L), no UI, and grants private repo read and write (C:H/I:H, A:N).
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
DescriptionCVE.org
Summary
Gitea v1.26.1 enforces repository-scoped access-token permissions on repository operations. In the Git Smart HTTP path, however, this check runs only when the token is presented via HTTP Basic authentication - CheckRepoScopedToken() returns early unless ctx.IsBasicAuth is true - so the same token sent as Authorization: Bearer <token> bypasses the scope check entirely.
As a result, a PAT or OAuth2 token presented as a Bearer credential can clone or fetch private repositories without the read:repository scope, and likewise reach the Git push without write:repository.
Details
Git Smart HTTP routes allow both Basic auth and OAuth2/Bearer auth:
// routers/web/web.go
addOwnerRepoGitHTTPRouters(
m,
repo.HTTPGitEnabledHandler,
webAuth.AllowBasic,
webAuth.AllowOAuth2,
repo.CorsHandler(),
optSignInFromAnyOrigin,
context.UserAssignmentWeb(),
)The Git HTTP authorization path calls CheckRepoScopedToken() before falling through to normal repository RBAC:
// routers/web/repo/githttp.go
if askAuth {
if !ctx.IsSigned {
ctx.HTTPError(http.StatusUnauthorized)
return nil
}
context.CheckRepoScopedToken(ctx, repo, auth_model.GetScopeLevelFromAccessMode(accessMode))
if ctx.Written() {
return nil
}
// normal repository RBAC follows
}However, CheckRepoScopedToken() only enforces token scopes for Basic-authenticated requests:
// services/context/permission.go
func CheckRepoScopedToken(ctx *Context, repo *repo_model.Repository, level auth_model.AccessTokenScopeLevel) {
if !ctx.IsBasicAuth || ctx.Data["IsApiToken"] != true {
return
}
scope, ok := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)
if ok {
requiredScopes := auth_model.GetRequiredScopes(level, auth_model.AccessTokenScopeCategoryRepository)
// public-only and required repository scope checks follow
}
}The Bearer/OAuth2 auth path still records the token scope:
// services/auth/oauth2.go
accessTokenScope, uid := GetOAuthAccessTokenScopeAndUserID(ctx, tokenSHA)
if uid != 0 {
store.GetData()["IsApiToken"] = true
store.GetData()["ApiTokenScope"] = accessTokenScope
}Bearer PATs also set IsApiToken=true and ApiTokenScope, but ctx.IsBasicAuth remains false because the selected auth method is OAuth2/Bearer rather than Basic. The scope is therefore available but ignored.
PoC
This test creates a token for user2 with only read:notification, then requests Git Smart HTTP refs for user2/repo2, which is private. The same token is rejected over Basic auth, but succeeds over Bearer auth.
func TestPOCGitSmartHTTPBearerTokenBypassesRepositoryScope(t *testing.T) {
defer tests.PrepareTestEnv(t)()
repo := unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: 2, OwnerName: "user2", Name: "repo2"})
assert.True(t, repo.IsPrivate)
session := loginUser(t, "user2")
token := getTokenForLoggedInUser(t, session, auth_model.AccessTokenScopeReadNotification)
url := "/user2/repo2/info/refs?service=git-upload-pack"
basicReq := NewRequest(t, "GET", url)
basicReq.SetBasicAuth(token, "x-oauth-basic")
MakeRequest(t, basicReq, http.StatusForbidden)
bearerReq := NewRequest(t, "GET", url).AddTokenAuth(token)
resp := MakeRequest(t, bearerReq, http.StatusOK)
assert.Contains(t, resp.Body.String(), "refs/heads/master")
}Impact
Any Gitea instance exposing Git Smart HTTP is affected when users use PATs or OAuth2 tokens as Bearer tokens. The attacker still needs a token for a user who has normal repository RBAC, so this does not grant access to repositories the token owner could not otherwise access.
The vulnerability breaks the access-token scope boundary. A token intended only for unrelated scopes, such as read:notification, can clone or fetch private repository contents over Git Smart HTTP. The same root cause can affect write flows because git-receive-pack also calls the same repository scope check before normal write RBAC.
Executive ViewAI
Gitea v1.26.1 and earlier contain an authorization bypass vulnerability allowing authenticated users to exploit OAuth2/PAT Bearer tokens with limited scopes to read and modify private repositories without proper scope validation. This exposes source code and development infrastructure to unauthorized access by developers, service accounts, or holders of compromised credentials, creating significant intellectual property and code integrity risks.
Restrict OAuth2/PAT token scopes to absolute minimum required permissions. Disable Bearer token authentication for Git Smart HTTP operations and enforce basic authentication instead. Immediately rotate all existing access tokens to reduce exploitation window. Implement access logging and alerting for Git operations by tokens with insufficient scopes. Monitor Gitea vendor advisories closely for patch availability.
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-863 – Incorrect Authorization
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