EUVD-2026-103985Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate and trigger Actions workflow
-
DeliveryCapture run's runner token
-
ExploitSend oversized Twirp artifact request
-
ExecutionServer reads body fully into memory
-
ImpactMemory exhausted, Gitea process terminates
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 | Requires that the Gitea instance has Actions enabled and that the attacker is an authenticated user permitted to run a workflow; the attacker must additionally obtain the runner token issued for that specific run, then target the artifact v4 (Twirp) handlers (findArtifactByName / parseProtobufBody path in routers/api/actions/artifactsv4.go). Exploitation is LIMITED by these prerequisites: it is not available to unauthenticated or anonymous users, and instances with Actions disabled or restricted to trusted users are not exposed. No user interaction by a victim is needed. Impact is confined to availability (process crash); there is no confidentiality or integrity exposure. |
| Impact | This is a genuine but moderate-priority issue, not an urgent one. The CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects an availability-only impact (C:N/I:N/A:H) reachable over the network but requiring low privileges (PR:L). All signals point the same direction, which increases confidence: EPSS is very low (0.16%, 4th percentile), the CISA SSVC framework rates Exploitation as 'none', Automatable as 'no', and Technical Impact as only 'partial', there is no KEV listing, and no public exploit is identified. The signals are consistent rather than conflicting - a low EPSS, non-automatable, partial-impact DoS with a prerequisite of holding a valid runner token is a targeted, authenticated-abuse scenario rather than mass-exploitable. The one nuance worth noting is that the CVSS PR:L may understate the real barrier: the attacker must not only be able to run a workflow but also obtain that run's runner token, which is a meaningful gating condition that makes opportunistic exploitation unlikely. Prioritize patching on instances where untrusted users can trigger Actions workflows; deprioritize where Actions is disabled or restricted to trusted users. |
| Exploit ScenarioDerived | An authenticated Gitea user who is permitted to run an Actions workflow captures the runner token issued for their own workflow run, then uses it to send a deliberately oversized request to the artifact v4 (Twirp) service. The handler reads the entire body into memory with no cap, exhausting server RAM and crashing the Gitea process, causing a denial of service for all users. No public exploit code is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Memory exhaustion in Gitea's Actions artifact v4 (Twirp) service lets an authenticated user who can run a workflow crash the server process by sending an oversized request body to the artifact handlers. The handlers called io.ReadAll on the request body without any size cap, so a single large POST from a run's runner token can consume all available memory and terminate the Gitea process, denying service to all users. The issue is rated CVSS 6.5 (availability-only, PR:L - authenticated, no user interaction), affects Gitea 1.22.0 through 28.1.0, and is fixed in 28.2.0; no public exploit code was identified and EPSS is only 0.16% (4th percentile), consistent with an SSVC assessment of no observed exploitation and low automatability.
RemediationAI
Upgrade to Gitea 28.2.0 or later, which caps Twirp request bodies at 1 MiB and returns HTTP 413 instead of buffering unbounded data (vendor advisory: https://github.com/go-gitea/gitea/security/advisories/GHSA-6f9g-7jgm-m5ph; fixes in https://github.com/go-gitea/gitea/pull/39818 and https://github.com/go-gitea/gitea/pull/39822). If an immediate upgrade is not possible, the exposure can be reduced by disabling Gitea Actions entirely where artifact support is not needed, or by restricting workflow execution to a small set of trusted users and organizations so that runner tokens are not obtainable by lower-privileged accounts - the trade-off is loss of CI/CD functionality or reduced self-service for developers. Because exploitation requires a valid runner token for a run the attacker can start, tightening who may trigger workflows and auditing runner token issuance materially shrinks the attack surface, though it does not remove the underlying unbounded-read flaw. Running Gitea under a supervisor or container memory limit will not prevent the crash but will contain blast radius and speed recovery; note that the process will still be killed on OOM, causing a brief outage for all users. Monitoring for unusually large POST bodies or 413/5xx responses on the /api/actions/artifactsv4/ Twirp paths provides a useful detection signal until patching is complete.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea Actions implements the GitHub Actions-compatible artifact protocol over Twirp, a lightweight RPC framework that serializes protobuf messages over plain HTTP POST requests. In routers/api/actions/artifactsv4.go, the parseProtobufBody helper (used by handlers such as findArtifactByName) read the entire request body with io.ReadAll before unmarshalling, with no upper bound on how much data would be buffered. Because CWE-770 (Allocation of Resources Without Limits or Throttling) applies, an attacker could submit an arbitrarily large body and force the Go process to allocate memory proportional to the request size; the resulting allocation pressure ends in an OOM kill of the Gitea service rather than a graceful error. The legitimate Twirp payloads here carry only a handful of small scalar fields (run IDs, artifact names), so the upstream fix introduces a maxProtobufBodySize constant of 1 MiB and wraps the body in io.LimitReader with a +1 sentinel byte, returning HTTP 413 Request Entity Too Large when the limit is exceeded - bounding memory without affecting any realistic request. The attack surface is only reachable when Actions is enabled, because the endpoint authenticates callers using the runner token issued for a specific workflow run.
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-reachable Twirp endpoint (AV:N); requires an authenticated workflow runner's token so PR:L; availability-only crash gives A:H with C:N/I:N and unchanged scope.
Primary rating from Vendor (Gitea).
CVSS VectorVendor: Gitea
Lifecycle Timeline
2DescriptionCVE.org
The Gitea Actions artifact v4 (Twirp) handlers read the whole request body into memory without a size limit. A user who can run a workflow and obtains the runner token of that run could send an oversized request to the artifact service and exhaust the memory of the server, which terminates the Gitea process. The request body is now limited to 1 MiB.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
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
Exploit-DB