CVE-2026-58424: Workflow Auth Bypass Vulnerability

CVE-2026-58424 Overview

CVE-2026-58424 is an authorization bypass vulnerability in Gitea affecting the fork pull request workflow approval gate. The flaw allows an authenticated contributor to permanently bypass the manual approval requirement for workflows triggered from forked repositories. Once bypassed, subsequent pull requests from the fork execute Actions workflows without maintainer review. The issue is categorized under CWE-285: Improper Authorization and was addressed in Gitea v1.26.4. Exploitation requires low privileges and user interaction, but produces high impact on integrity and availability of the CI/CD environment, with scope change extending beyond the repository boundary.

Critical Impact
Attackers with contributor-level access can execute untrusted workflow code from forks, enabling secret exfiltration, supply-chain tampering, and runner compromise across the Gitea Actions infrastructure.

Affected Products

Gitea self-hosted Git service, versions prior to 1.26.3
Gitea 1.26.3 (fix incomplete; superseded by 1.26.4)
Deployments using Gitea Actions with fork pull requests enabled

Discovery Timeline

2026-07-03 - CVE-2026-58424 published to NVD
2026-07-06 - Last updated in NVD database
Fix Release - Gitea v1.26.4 released addressing the approval bypass, referenced in GitHub Security Advisory GHSA-777r-4v59-6486

Technical Details for CVE-2026-58424

Vulnerability Analysis

Gitea Actions enforces a manual approval gate the first time a contributor submits a workflow-triggering pull request from a fork. This gate exists to prevent untrusted code in forks from executing on runners with access to repository secrets. The vulnerability stems from how Gitea persists approval state. Once a maintainer approves a single workflow run from a fork contributor, the approval requirement is dropped permanently for that user, even across unrelated pull requests and modified workflow files. An attacker who obtains one legitimate approval can then push arbitrary workflow definitions in subsequent PRs. Those workflows execute automatically without further review. This converts a one-time trust decision into an implicit standing grant.

Root Cause

The root cause is an authorization check that evaluates "has this user been approved before" rather than "is this specific workflow run approved." The design conflates user reputation with workflow trust. See the GitHub Pull Request Discussion for the code-level remediation.

Attack Vector

The attack requires network access to a Gitea instance and a contributor account authorized to open pull requests. The adversary first submits a benign PR from a fork and requests review. After a maintainer approves the workflow run, the attacker submits a follow-up PR containing a malicious .gitea/workflows/*.yaml file. The malicious workflow runs on the shared runner with access to repository secrets, GITHUB_TOKEN equivalents, and any mounted infrastructure. User interaction is required only for the initial approval, which is a routine maintainer action.

The vulnerability manifests in Gitea's fork PR trust evaluation logic. Refer to the Gitea Release Announcement for technical details and the Gitea Release Tag v1.26.4 for the corrected implementation.

Detection Methods for CVE-2026-58424

Indicators of Compromise

Workflow runs from fork pull requests executing without a corresponding approval event in the audit log
Modifications to .gitea/workflows/ files in fork PRs immediately followed by successful runner execution
Outbound network connections from Actions runners to unfamiliar hosts during fork PR runs
Access to repository secrets or ACTIONS_RUNTIME_TOKEN from workflows authored by external contributors

Detection Strategies

Correlate Gitea audit logs for workflow_run.approved events against workflow_run.started events originating from forks
Alert on fork PRs that add or modify workflow YAML files under .gitea/workflows/
Baseline expected runner egress destinations and flag deviations during fork-triggered runs
Review contributor histories for accounts with a single early approval followed by frequent workflow-modifying PRs

Monitoring Recommendations

Enable Gitea Actions audit logging and forward events to a centralized SIEM for correlation
Monitor process execution and network telemetry on self-hosted runners for command injection, credential access, and lateral movement patterns
Track secret access events tied to workflow run IDs to identify unauthorized retrieval

How to Mitigate CVE-2026-58424

Immediate Actions Required

Upgrade all Gitea instances to v1.26.4 or later without delay
Rotate any secrets, deploy keys, and tokens exposed to Gitea Actions runners that processed fork PRs
Audit prior fork PR workflow runs since the introduction of Gitea Actions for evidence of abuse
Restrict runner access to production infrastructure and enforce ephemeral runner instances

Patch Information

The fix is included in Gitea v1.26.4. Details are published in the GitHub Security Advisory GHSA-777r-4v59-6486 and the Gitea Release Announcement. The patch changes the approval model so that each fork pull request workflow run requires an independent approval decision rather than inheriting trust from prior approvals.

Workarounds

Disable Gitea Actions for repositories that accept fork contributions until the upgrade is applied
Configure runners without access to production secrets and use short-lived, scoped credentials
Require signed commits and enforce branch protection to reduce the blast radius of malicious workflow modifications
Segment self-hosted runners onto isolated networks with strict egress filtering

bash

# Verify installed Gitea version and upgrade
gitea --version

# Example upgrade path for binary installs
systemctl stop gitea
wget https://dl.gitea.com/gitea/1.26.4/gitea-1.26.4-linux-amd64 -O /usr/local/bin/gitea
chmod +x /usr/local/bin/gitea
systemctl start gitea

# Temporarily disable Actions in app.ini until patched
# [actions]
# ENABLED = false