Executive brief
Gitea, a self-hosted Git service, contains a flaw in how it handles security approvals for automated tasks (Actions) triggered by external contributors. Normally, a maintainer must manually approve code from a fork before it can run on the project's infrastructure to prevent malicious code execution. However, once a maintainer approves a single harmless contribution from a user, Gitea permanently trusts that user, allowing them to run any future malicious code automatically without further oversight. This could allow an attacker to steal source code, disrupt operations, or gain access to internal corporate networks.
Technical details
A logic flaw exists in the `ifNeedApproval` function within `services/actions/notifier_helper.go`. The gate check is scoped only to the repository ID and the triggering user ID, checking if the user has *any* previously approved run. It fails to validate the specific Pull Request, Commit SHA, or workflow content. Consequently, after a single manual approval of a benign PR, an attacker can submit subsequent PRs with malicious workflow files that bypass the approval gate entirely. This allows for arbitrary shell execution on the runner, access to `GITHUB_TOKEN`, and potential lateral movement or cache poisoning. The issue is fixed in version 1.26.3 by ensuring trust is not permanently associated with the user identity alone.
Affected products
- Gitea Gitea >= v1.20.0, < 1.26.3
Timeline
- 2023-02-24: other: Vulnerable logic introduced in commit edf98a2dc3
- 2026-05-24: disclosed: Vulnerability verified on main branch by researcher
- 2026-07-01: advisory: GitHub Advisory published
- 2026-07-21: patched: Advisory updated with fixed version 1.26.3