CVE-2026-58424: 
Gitea Análisis y mitigación de vulnerabilidades

CVE-2026-58424 is a Permanent Fork PR Workflow Approval Gate Bypass vulnerability in Gitea Actions affecting all Gitea releases from v1.20.0 through v1.26.2. The flaw allows a low-privileged authenticated user to permanently bypass the CI workflow approval gate after receiving a single one-time approval from a repository administrator, enabling arbitrary workflow execution on subsequent fork pull requests without any further maintainer interaction. It was discovered by researcher Prakhar Porwal (prakhar0x01), live-verified on May 24, 2026, and publicly disclosed on July 1–3, 2026. The vulnerability carries a CVSS v3.1 base score of 8.9 (High) (GitHub Advisory).

The root cause is an improper authorization check (CWE-863, CWE-285, CWE-732) in the ifNeedApproval() function within services/actions/notifier_helper.go. The function's final bypass clause queries the action_run table for any prior run with approved_by > 0 scoped only to (repo_id, trigger_user_id) — it does not consider the pull request ID, head commit SHA, branch, workflow file contents, or any time window. As a result, a single administrator click of "Approve and run workflows" on a contributor's first fork PR permanently marks that user as trusted for all future fork PRs in the same repository, including PRs that entirely replace the workflow YAML. The buggy logic was introduced in commit edf98a2dc3 on 2023-02-24 and shipped unchanged until the fix. A proof-of-concept reproduction was included in the advisory, demonstrating that the second malicious PR's action_run row is created with need_approval = 0 and approved_by = 0 — indistinguishable from a legitimate trusted-user run (GitHub Advisory, Fix PR).

Successful exploitation grants an attacker arbitrary shell code execution on the Gitea Actions runner infrastructure, including access to a populated GITHUB_TOKEN, outbound network connectivity, and the cloned repository source. Beyond direct code execution, attackers can poison the Actions cache (which is shared across branches and consumed by trusted base-branch workflows), inject malicious artifacts into deploy pipelines, and — if runners are non-ephemeral or share state — achieve persistent runner host compromise. Repositories accepting fork PRs from the public (open-source projects) are most exposed, but internal corporate repositories that have ever approved a fork PR from a contractor or external collaborator are equally at risk; the bypassed run leaves no audit signal since its database row is schema-indistinguishable from a legitimate trusted-user run (GitHub Advisory).

1. Reconnaissance: Identify a Gitea instance (v1.20.0–v1.26.2) with Actions enabled ([actions] ENABLED = true in app.ini) and at least one registered runner. Target a public repository or one where the attacker can register an account.
2. Create attacker account: Register an unprivileged account on the target Gitea instance (standard sign-up; no special permissions required).
3. Fork the target repository: As the attacker, fork the target repository that has a .gitea/workflows/ CI workflow file.
4. Open a benign first PR (PR #1): Create a harmless change (e.g., a README typo fix) on a new branch in the fork and open a pull request against the upstream repository. The workflow run will be created with need_approval = 1 and status Blocked.
5. Wait for administrator approval: The repository maintainer sees the "Workflow runs from fork pull requests need approval to run" banner and clicks "Approve and run workflows" on PR #1. This sets approved_by = <admin_uid> on the action_run row for that run.
6. Open a malicious second PR (PR #2): On a new branch in the fork, replace .gitea/workflows/ci.yml with a malicious payload (e.g., exfiltrating ${{ github.token }}, running id, curl to an attacker-controlled server, or establishing a reverse shell). Open a new pull request.
7. Observe bypass: The new workflow run is created with need_approval = 0 and approved_by = 0 — the gate is skipped entirely. The runner dispatches the job within seconds, executing the attacker's arbitrary shell payload without any maintainer notification or approval (GitHub Advisory).

• Database (action_run table): Rows where trigger_user_id matches a fork contributor, need_approval = 0, and approved_by = 0 simultaneously — this combination is the primary forensic indicator of bypass exploitation. Query: SELECT id, trigger_user_id, need_approval, approved_by, status, ref FROM action_run WHERE need_approval = 0 AND approved_by = 0 AND ref LIKE 'refs/pull/%/head';
• Logs: Gitea Actions runner logs showing workflow execution for a fork PR without a preceding "Approve and run workflows" admin action in the audit log; runner logs containing unexpected commands (id, curl, wget, nc, reverse shell patterns) in step output.
• Network: Unexpected outbound connections from the runner host to external IPs or domains shortly after a fork PR workflow run; DNS queries or HTTP requests to attacker-controlled infrastructure originating from the runner process.
• File System: Unexpected files written to the runner workspace or host filesystem by the Gitea runner process; new cron jobs, SSH authorized keys, or persistence mechanisms created under the runner's user account.
• Process: Unusual child processes spawned by the Gitea runner (e.g., bash, sh, curl, python, nc) that are not part of the expected workflow steps (GitHub Advisory).

Upgrade to Gitea v1.26.4 (recommended) or v1.26.3 immediately — note that v1.26.3 contains a regression causing "context deadline exceeded" errors on repository code pages, so upgrading directly to v1.26.4 is strongly advised. The fix (PR #38010, merged June 8, 2026) replaces the flawed user-scoped approval check with a requirement that the contributor must have had a pull request merged in the repository before their fork PR workflows are auto-trusted, aligning behavior with GitHub Actions' first-time-contributor model. As a temporary workaround where upgrading is not immediately possible, administrators should audit the action_run table for suspicious rows (need_approval = 0, approved_by = 0, ref LIKE 'refs/pull/%/head') and consider disabling Actions for repositories that accept fork PRs from untrusted contributors (Gitea Release v1.26.4, Fix PR).

The vulnerability received coverage from The Hacker Wire and was discussed on Reddit's r/pwnhub, where it was described as a "critical vulnerability discovered in pull request workflows." Social media posts appeared on Bluesky and Mastodon shortly after disclosure. The Gitea maintainer lunny approved the fix PR promptly and characterized the issue as a "design defect" warranting backport to the stable branch. The fix was labeled pr/breaking by the Gitea bot, acknowledging that the behavior change (from approve-once to require-merged-PR trust) is a breaking change for maintainers who relied on the implicit "approve once" trust model (The Hacker Wire, Fix PR).