Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.

Project Subscriptions

No data.

Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Tue, 06 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Description Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.
Title Gitea fork workflow approval bypass through maintainer-triggered events
Weaknesses CWE-441
CWE-863
References

Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: Gitea

Published:

Updated: 2026-10-06T19:25:04.327Z

Reserved: 2026-10-04T21:57:35.579Z

Link: CVE-2026-94205

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-06T20:17:34.733

Modified: 2026-10-06T20:17:34.733

Link: CVE-2026-94205

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

No data.

Weaknesses