CVE-2026-58424VulnerabilityPublished 07/21/2026

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

Affects Gitea code.gitea.io/giteaSource GCVE Database

Not known to be exploited · CVSS 8.9 High.

Data as of 10/24/2026, 22:16:04 UTC

CVSS 3.1 base score

8.9High

How severe the flaw is on the 0–10 CVSS scale.

Exploitation: Not in CISA KEV, no exploitation reported
EPSS: 0.3% chance of exploitation in 30 days – higher than 29% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

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

Attack Vector: Network
Attack Complexity: Low
Privileges Required: Low
User Interaction: Required
Scope: Changed
Confidentiality: Low
Integrity: High
Availability: High

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: Low: The attacker is authorized with (i.e., requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
User Interaction: Required: Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited.
Scope: Changed: An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.
Confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.
Integrity: High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
Availability: High: There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Definitions: FIRST CVSS v3.1 specification.

What to do

Affected software

Product	Affected	Fixed in
GitHubgo-gitea/gitea`pkg:github/go-gitea/gitea`Other threats	Affected =0	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Repository administrators should be aware that approving a fork PR workflow run from a new contributor permanently grants that user the ability to run arbitrary workflows without further approval. As a temporary mitigation, administrators should avoid approving fork PR workflow runs from untrusted contributors until a fix is released. Monitor Gitea vendor advisories for updates and apply official patches once available.

Description

Gitea Actions contains a vulnerability in the fork pull request workflow approval gate that allows an attacker with a single unprivileged account and one-time maintainer approval on a benign fork PR to permanently bypass approval for all future fork PR workflow runs from that user on the same repository. This bypass occurs because the approval check only verifies if the user has any previously approved run in the repository, without considering the pull request, commit, or workflow contents. The vulnerability affects all Gitea versions from v1.20.0 onward and remains unpatched as of this disclosure.

Impact

An attacker with a standard authenticated account capable of forking the repository can gain persistent ability to execute arbitrary workflow code on the repository's CI runners after a single approval of a benign fork PR workflow by a repository administrator. This allows execution of arbitrary shell commands with network access and repository source access, potentially leading to code execution, data exposure, and disruption of CI infrastructure. The vulnerability undermines the intended security gate for fork PR workflows, effectively granting permanent elevated trust to the attacker within the affected repository.

Summary

The vulnerability (CVE-2026-58424) resides in Gitea Actions' approval gate for workflows triggered by fork pull requests. The function ifNeedApproval incorrectly skips approval if the triggering user has any previously approved workflow run in the repository, regardless of the PR, commit, or workflow file. This logic flaw means that after a single approval by a repository administrator on a benign fork PR, the user is permanently trusted to run arbitrary workflows on the repository's CI infrastructure. The issue was introduced in commit edf98a2dc3 on 2023-02-24 and affects all releases from v1.20.0 through versions prior to 1.26.3, including the latest development builds. No official fix is available yet. The vulnerability requires an authenticated user with fork capability and one-time interaction from a repository admin. It was live-verified on Gitea main branch in May 2026.

Weaknesses

CWE-285Improper Authorization (opens in a new tab)
Class weaknessLikelihood of exploit: HighOWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design
Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
Architecture and Design
Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records.
Architecture and Design · Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
OWASP Cheat Sheets
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.8 (opens in a new tab)
V13.4.2 (opens in a new tab)
V7.2.2 (opens in a new tab)
Attack patterns
Accessing Functionality Not Properly Constrained by ACLs (opens in a new tab)
Cross Zone Scripting (opens in a new tab)
Directory Indexing (opens in a new tab)
Subverting Environment Variable Values (opens in a new tab)
Using Malicious Files (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-732Incorrect Permission Assignment for Critical Resource (opens in a new tab)
Class weaknessLikelihood of exploit: HighOWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
Implementation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user), and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Architecture and Design
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly.
Architecture and Design · Operation · Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
OWASP Cheat Sheets
REST Assessment (opens in a new tab)
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V4.3.3 (opens in a new tab)
V8.3.8 (opens in a new tab)
V13.4.2 (opens in a new tab)
Attack patterns
Accessing Functionality Not Properly Constrained by ACLs (opens in a new tab)
Directory Indexing (opens in a new tab)
Using Malicious Files (opens in a new tab)
Exploiting Incorrectly Configured Access Control Security Levels (opens in a new tab)
Signing Malicious Code (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-863Incorrect Authorization (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #17OWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Architecture and Design
Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
Architecture and Design
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records.
Architecture and Design · Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
OWASP Cheat Sheets
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.8 (opens in a new tab)
V13.4.2 (opens in a new tab)
V7.2.2 (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…