Gitea CVE-2026-24059

A valid Gitea API token with at minimum read:user scope (or the org/repo/admin equivalents) is required - the attacker does not need a write-scoped token. Gitea Actions must be enabled on the instance ([actions] ENABLED = true in app.ini); on instances where Actions is disabled, runner registration is inert but the token-minting call may still succeed. The instance must be running Gitea prior to v1.25.5. Exploitation is limited by the need to possess or obtain a valid API token - unauthenticated exploitation is not possible; the CVSS PR:L reflects this requirement. Additionally, the impact on secrets is constrained to repositories that actually use Actions workflows; instances running Gitea purely as a code host without CI workflows face reduced practical impact from a registered runner, as no jobs would execute.

The CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) correctly reflects low-complexity network exploitation with a low-privilege token, but understates integrity impact: registering a malicious runner allows arbitrary code execution within workflow context, which is an integrity impact the vendor's vector omits. EPSS at 0.16% (6th percentile) indicates no meaningful observed exploitation activity in the wild, and the vulnerability is not listed in CISA KEV, further supporting low current exploitation pressure. However, the attack chain is simple and entirely achievable with a single leaked token, making this a high-priority remediation target for any Gitea instance with Actions enabled. The primary real-world risk amplifier is token exposure - organizations that store Gitea API tokens in CI environment variables, dotfiles, or logs should treat this as elevated priority. The SSVC exploitation status is 'none' per available signals, the attack is automatable (single HTTP GET), and the technical impact is total on secrets and source code access, suggesting expedited remediation is warranted despite the moderate base score.

An attacker discovers a Gitea API token with read:user scope in a public GitHub repository, a leaked dotfile, or a CI environment variable dump. They issue a single authenticated GET request to https://gitea.example.com/api/v1/user/actions/runners/registration-token using that token; the API returns a valid runner registration token. The attacker then registers a malicious self-hosted runner using the Gitea Actions runner binary with that token, and waits for - or triggers - a workflow run on a target repository, at which point the runner executes the workflow jobs and exfiltrates GITEA_TOKEN, repository secrets, and source code to an attacker-controlled server. No public proof-of-concept exploit code has been identified at time of analysis, but the attack requires only standard Gitea API client tooling.