DEV Community

facilishz
facilishz

Posted on

Fork pull requests and runner trust: what Gitea's Actions approval fixes change

#security #gitea #cicd #supplychain

Fork pull requests and runner trust: what Gitea's Actions approval fixes change

A self-hosted forge holds source code, pipeline definitions and the credentials those pipelines use. Opening it to outside contributions means accepting fork pull requests, and that means deciding when untrusted code is allowed to touch a runner. Gitea's 28.0.0 and 28.1.0 releases together close 27 security issues, and four of them sit directly on that decision. CVE-2026-103670, scored 7.5, is the cancellation-side member of the group.

Where the trust boundary sits

A fork pull request arrives from an account a project does not control. The repository's protection is procedural: a maintainer reviews the change, and only then does the pipeline run with the project's secrets and network position. Everything inside the runner is trusted; everything arriving through the fork is not. The gate exists to keep those two apart.
Approval bypasses shorten that gate. In Gitea, routine triage such as adding a label could start a fork run with no sign-off. A separate flaw let a small workflow matrix expand into a large number of jobs and exhaust the server, which is a resource problem rather than an approval one, and the release notes place them in the same cluster because they share an input source.

Mechanism and exploitation conditions

CVE-2026-103670 is described as a trusted workflow cancellation reachable by an unapproved fork run. The published material names the class and the version range and does not document the exact trigger. What follows from the description is the shape of the weakness: a cancellation path that assumes the caller belongs to the trusted set, and an input that an unapproved fork can supply.
Two conditions shape practical exposure. First, the repository has to accept fork pull requests, which is standard for public projects. Second, the Actions feature has to be in use with fork workflows enabled. Repositories that disable external workflows, or that run fork code on an isolated runner with no secrets, have far less at stake if the approval logic fails.

Impact

Workflow state is part of release handling in many projects. A cancellation that no maintainer requested can mask a failing build, remove queued work, or place a run in a state that downstream automation reads as settled. None of that requires code execution on the runner. The damage is to the integrity of the pipeline record and, in the worst case, to a release decision taken on a falsified outcome.
The advisory set lists no confirmed exploitation in the wild for these Gitea issues and no public proof-of-concept. Treat the impact picture as a design risk that is now closed rather than an incident report.

Affected products and scope

Releases up to and including Gitea 28.0.0 carry the eight issues fixed in 28.1.0, and Gitea 1.27.3 and earlier carry a further nineteen fixed in 28.0.0. Some of the 27 fixes apply only under non-default settings. The Actions items matter most to teams that accept external contributions and run workflows on fork pull requests.

Exposure context

A ZoomEye query for app="Gitea" matched 116,431 assets on 2026-10-07. That figure counts hosts presenting the Gitea fingerprint across the internet, and it says nothing about version, configuration or whether Actions is enabled. A query for vul.cve="CVE-2026-103670" returned no indexed assets. The honest reading is that the vulnerable population is a subset of a large, mostly self-hosted fleet, and version inventory is the only way to narrow it.

Remediation and mitigations

Move to Gitea 28.1.0, because 28.0.0 still carries eight of the 27 fixes. Then reduce what a fork run can reach: require approval for fork pull request workflows, keep secrets out of workflows that untrusted code can trigger, and prefer runners that hold no production credentials. Review recent Actions activity for cancellations no maintainer started, and for label changes that produced runs nobody expected. These steps do not repair an unpatched instance, but they bound what a bypass yields while the upgrade is scheduled.

References

Top comments (0)