Gitea-Actions - CraftedSignal Threat Feed

Gitea Actions Fork Pull Request Approval Gate Bypass

hello@craftedsignal.io — Tue, 21 Jul 2026 20:43:25 +0000

A critical logic flaw, identified as GITEA-2026-004, has been discovered in Gitea Actions affecting all versions v1.20.0 and later. This vulnerability allows an unprivileged Gitea user with the ability to fork a repository to bypass the intended approval mechanism for fork pull requests. The flawed logic, introduced in commit edf98a2dc3 (February 24, 2023), mistakenly interprets a single approval of any workflow run from a contributor on a given repository as permanent, unconditional trust for that user on that repository. Consequently, after a repository administrator approves a single benign pull request's workflow from an attacker, all subsequent malicious pull requests from the same attacker on the same repository will automatically execute their workflows on the Gitea Actions runner without requiring any further maintainer intervention. This effectively grants the attacker arbitrary code execution capabilities on the runner, leading to potential source code disclosure, exfiltration of sensitive data, or broader system compromise.

Attack Chain

An attacker creates an unprivileged Gitea account on a self-hosted Gitea instance.
The attacker forks a target repository, typically a public project or one they wish to compromise.
The attacker submits a benign pull request (PR) from their fork to the target repository, triggering a Gitea Actions workflow. This PR's workflow is designed to appear harmless and gain initial approval.
A repository administrator reviews the benign PR and, unaware of the vulnerability, explicitly approves its workflow run.
Gitea's flawed ifNeedApproval() function (in services/actions/notifier_helper.go) records this approval as a permanent trust for the attacker's user ID on that repository by incrementing approved_by in the action_run table.
The attacker then creates a new branch in their fork and crafts a second, malicious pull request containing a harmful workflow file (e.g., executing shell commands like curl, id, ls -la to exfiltrate data or establish persistence).
Due to the previously recorded permanent trust, Gitea's approval gate is bypassed, and the malicious workflow is dispatched immediately to the configured Gitea Actions runner without any further interaction or explicit approval from the maintainer.
The Gitea Actions runner executes the malicious workflow, granting the attacker arbitrary shell execution, access to the cloned source code, environment variables (like a populated GITHUB_TOKEN), and outbound network connectivity, leading to various impacts.

Impact

The successful exploitation of this vulnerability results in arbitrary code execution on the Gitea Actions runner environment. This gives attackers control over the CI compute resources with the ambient privileges of the runner (shell access, network connectivity, filesystem access). Observed consequences include the ability to execute arbitrary shell commands, access to a populated GITHUB_TOKEN which can be used to interact with the Gitea API, and source code disclosure from the cloned repository. Attackers can leverage this access to exfiltrate sensitive data, manipulate repository contents, compromise the runner infrastructure itself, or establish further footholds within the organization's network. While the number of affected instances is not specified, all self-hosted Gitea instances running v1.20.0 or later are potentially vulnerable, impacting any organization utilizing Gitea Actions for CI/CD.

Recommendation

If possible, temporarily disable Gitea Actions for fork pull requests on sensitive repositories until a patch is available.
Implement a rigorous review process for any first-time contributor's pull request, including manual verification of workflow files and their potential impact, even if only a one-time approval is required.
Monitor Gitea application logs for action_run entries where need_approval is false but approved_by is 0 for new fork pull requests, which could indicate exploitation.
Monitor Gitea Actions runner activity for suspicious shell commands (e.g., curl to unusual destinations, id, ls -la in unexpected directories) originating from fork PR workflows, which would be visible in the runner's execution logs (/api/v1/repos/{owner}/{repo}/actions/jobs/{job_id}/logs).

Gitea Actions Artifacts V4 HMAC Ambiguity Allows Cross-Repository Data Access

hello@craftedsignal.io — Tue, 21 Jul 2026 20:42:15 +0000

A critical vulnerability (GHSA-hg5r-vq93-9fv6) has been identified in Gitea Actions Artifacts V4 that allows an authenticated attacker to bypass access controls using specially crafted signed URLs. This flaw, present in Gitea versions from v1.22.6 through v1.26.1, arises because the HMAC signature for artifact URLs is generated by concatenating fields (such as artifactName, taskID, and artifactID) without proper delimiters or length-prefixing. An attacker with permissions to execute a Gitea Actions job can forge a signed URL to achieve two primary objectives: unauthorized cross-repository artifact reading (DownloadArtifact path) or unauthorized cross-task artifact staging write and metadata mutation (UploadArtifact path). The vulnerability permits access to private repository data or the injection of arbitrary data into other running tasks' artifact contexts, posing a significant risk to data confidentiality and integrity within affected Gitea instances.

Attack Chain

An attacker gains legitimate execution permissions within Gitea Actions to run a job.
The attacker creates their own Gitea Actions task, publishes an artifact, and obtains a legitimate signed URL for this attacker-controlled artifact.
The attacker crafts a new URL by manipulating the artifactName, taskID, and artifactID parameters within the signed URL, specifically choosing values (e.g., artifactName="artifact-795-1", taskID=53, artifactID=48) that, when concatenated, produce the same HMAC input as the original legitimate URL.
The attacker, acting as an unauthenticated client, sends the forged URL as an HTTP GET request to the Gitea /api/actions/artifactsv4/DownloadArtifact endpoint to attempt data exfiltration.
Gitea's server-side verifySignature() function validates the HMAC of the forged URL as legitimate due to the underlying concatenation flaw.
The server then proceeds to resolve the artifact using the attacker-controlled taskID and artifactName from the URL, which now points to a target task or artifact in a different repository.
Gitea retrieves and serves the artifact from the targeted repository or task context to the attacker, leading to unauthorized cross-repository artifact data exposure. Alternatively, the attacker can send a forged PUT request to /api/actions/artifactsv4/UploadArtifact to write arbitrary data into another running task's artifact staging area and mutate its metadata.

Impact

Successful exploitation of this vulnerability can lead to severe consequences for organizations utilizing affected Gitea instances. Attackers can exfiltrate sensitive data from private repositories by reading artifacts belonging to other users or teams. Furthermore, the ability to write arbitrary data into another task's artifact staging area compromises data integrity, potentially allowing for injection of malicious code, corrupted build artifacts, or other integrity-damaging actions. While no active in-the-wild exploitation is reported, the vulnerability's impact is high (confidentiality and integrity), as demonstrated by the proof-of-concept allowing cross-repository private artifact disclosure and cross-context staging write with metadata mutation.

Recommendation

Upgrade Gitea instances to a patched version immediately to remediate GHSA-hg5r-vq93-9fv6.
Monitor Gitea access logs for unusual download or upload patterns involving the /api/actions/artifactsv4/DownloadArtifact and /api/actions/artifactsv4/UploadArtifact endpoints, especially for unauthenticated requests or requests with unusual taskID or artifactID patterns in the query string.
Implement strong authentication and authorization policies for Gitea Actions job execution to limit potential attackers' initial access.