ZeroDay Findings
Sign inSign up

Findings

CVE-2026-94205

Gitea fork workflow approval bypass through maintainer-triggered events

Published Oct 14, 2026 · updated Oct 14, 2026

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 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.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 14, 2026 · GitHub Advisory Database

    Detected

    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 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

  2. Oct 14, 2026 · GitHub Advisory Database

    Fix available

    gitea fixed in 28.0.0

  3. Oct 14, 2026 · GitHub Advisory Database

    Fix available

    gitea fixed in 28.0.0

  4. Oct 14, 2026 · GitHub Advisory Database

    Updated

    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 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

Affected

  • Bitnami gitea0 → 28.0.0

Sources

References