Gitea EUVD-2026-41607

Exploitation requires that Gitea Actions is enabled and that the repository accepts fork pull requests gated by the maintainer approval workflow - the exact feature the CVE targets. The attacker must hold a low-privileged authenticated account capable of opening a fork PR (PR:L), and a maintainer must perform the initial approval interaction (UI:R) at least once before the permanent bypass takes hold. Limiting factors: instances that disable Actions, that do not run workflows on fork PRs, or that never grant an approval are not exploitable; the dependency on a maintainer action and an existing contributor foothold means this is not exploitable against a default install with no contributors or with Actions turned off.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:H, base 8.9) indicates a network-reachable, low-complexity attack requiring a low-privileged account (PR:L, i.e. an authenticated contributor able to open a fork PR) and user interaction (UI:R - a maintainer must act at least once), with a scope change and high integrity and availability impact but only low confidentiality impact. This is a credible, high-priority CI/CD supply-chain risk for organizations that run Gitea Actions with fork PRs enabled, but the UI:R and PR:L requirements meaningfully constrain it: the attacker needs a contributor foothold and at least one maintainer interaction, so this is not a spray-and-pray internet-wide bug. No EPSS score, KEV listing, SSVC decision, or POC was supplied in the input, so real-world exploitation probability cannot be quantified from the data - the assessment rests on the CVSS vector and vendor description. The absence of KEV/POC data suggests no confirmed active exploitation, but absence of data is not proof of absence; treat the CVSS-derived severity as the primary signal and patch promptly given the CI/secret exposure.

An attacker registers a contributor account, forks a target repository hosted on a vulnerable Gitea instance, and opens a pull request; once a maintainer grants the one-time approval for the fork's workflow, the attacker exploits the permanent-approval flaw so that later malicious workflow changes execute without a fresh approval, running attacker-controlled code on the CI runner with access to repository tokens and secrets. No public exploit has been identified at time of analysis, but the network vector and low attack complexity make this straightforward to attempt for anyone able to submit a fork PR.