Advisory Database
  • Advisories
  • Dependency Scanning
  1. golang
  2. ›
  3. code.gitea.io/gitea
  4. ›
  5. CVE-2026-58424

CVE-2026-58424: Gitea: Permanent Fork PR Workflow Approval Gate Bypass

July 21, 2026

Gitea Actions enforces an approval gate on workflow runs triggered by fork pull requests, so that an untrusted contributor cannot execute arbitrary workflow YAML on the maintainer’s runner infrastructure without explicit consent. The gate is implemented by ifNeedApproval() in services/actions/notifier_helper.go. Its final clause skips the gate whenever the triggering user has any previously-approved run in the same repository:

// services/actions/notifier_helper.go:423-433
if count, err := db.Count[actions_model.ActionRun](ctx, actions_model.FindRunOptions{
RepoID:        repo.ID,
TriggerUserID: user.ID,
Approved:      true,
}); err != nil {
return false, fmt.Errorf("CountRuns: %w", err)
} else if count > 0 {
log.Trace("do not need approval because user %d has been approved before", user.ID)
return false, nil
}

The check is scoped to (repo_id, trigger_user_id) only. It does not consider the pull request, the head commit, the workflow file contents, or any time window. The single approval click on a contributor’s first fork PR is therefore interpreted by Gitea as “this user is permanently trusted to execute any workflow YAML on this repository’s CI infrastructure forever” — for every future PR, on any branch, against any commit, regardless of what the workflow does.

This is a structural deviation from the documented intent — the in-source comment on the bypassing path reads “if it’s the first time user … triggered actions”, implying a per-action-trigger check that the code does not actually perform. It is also a deviation from the equivalent behavior on the platform Gitea Actions is modeled after (GitHub Actions), where the first-contributor gate persists until a PR is merged, not merely approved-to-run.

I have live-reproduced the bypass end-to-end against a current main build. With zero further interaction from the maintainer after the one-time approval, an attacker’s second PR’s workflow:

  • Was created with need_approval = 0 and approved_by = 0 in the action_run table (i.e. nobody ever approved it, and yet it was not gated).
  • Was dispatched to the runner immediately.
  • Executed arbitrary shell on the runner, with outbound network access, a populated GITHUB_TOKEN, and access to the cloned source.

Full receipts are in §3.


References

  • blog.gitea.com/release-of-1.26.3-and-1.26.4
  • github.com/advisories/GHSA-777r-4v59-6486
  • github.com/go-gitea/gitea/commit/699fe2ef43b9466ac1b0cb857029f91fd5b0056d
  • github.com/go-gitea/gitea/commit/e107498f3b6fccff35455ef17430ca68df665297
  • github.com/go-gitea/gitea/pull/38010
  • github.com/go-gitea/gitea/releases/tag/v1.26.4
  • github.com/go-gitea/gitea/security/advisories/GHSA-777r-4v59-6486
  • nvd.nist.gov/vuln/detail/CVE-2026-58424

Code Behaviors & Features

Detect and mitigate CVE-2026-58424 with GitLab Dependency Scanning

Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Learn more about Dependency Scanning →

Affected versions

All versions before 1.26.3

Fixed versions

  • 1.26.3

Solution

Upgrade to version 1.26.3 or above.

Impact 8.9 HIGH

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:H

Learn more about CVSS

Weakness

  • CWE-285: Improper Authorization
  • CWE-732: Incorrect Permission Assignment for Critical Resource
  • CWE-863: Incorrect Authorization

Source file

go/code.gitea.io/gitea/CVE-2026-58424.yml

Spotted a mistake? Edit the file on GitLab.

  • Site Repo
  • About GitLab
  • Terms
  • Privacy Statement
  • Contact

Page generated Sat, 08 Aug 2026 00:18:35 +0000.