{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/gitea-actions/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Gitea (v1.20.0 and later)"],"_cs_severities":["critical"],"_cs_tags":["logic-bug","ci-cd","code-execution","privilege-escalation","gitea-actions"],"_cs_type":"advisory","_cs_vendors":["Gitea"],"content_html":"\u003cp\u003eA 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 \u003ccode\u003eedf98a2dc3\u003c/code\u003e (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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker creates an unprivileged Gitea account on a self-hosted Gitea instance.\u003c/li\u003e\n\u003cli\u003eThe attacker forks a target repository, typically a public project or one they wish to compromise.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eA repository administrator reviews the benign PR and, unaware of the vulnerability, explicitly approves its workflow run.\u003c/li\u003e\n\u003cli\u003eGitea's flawed \u003ccode\u003eifNeedApproval()\u003c/code\u003e function (in \u003ccode\u003eservices/actions/notifier_helper.go\u003c/code\u003e) records this approval as a permanent trust for the attacker's user ID on that repository by incrementing \u003ccode\u003eapproved_by\u003c/code\u003e in the \u003ccode\u003eaction_run\u003c/code\u003e table.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003eid\u003c/code\u003e, \u003ccode\u003els -la\u003c/code\u003e to exfiltrate data or establish persistence).\u003c/li\u003e\n\u003cli\u003eDue 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.\u003c/li\u003e\n\u003cli\u003eThe Gitea Actions runner executes the malicious workflow, granting the attacker arbitrary shell execution, access to the cloned source code, environment variables (like a populated \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e), and outbound network connectivity, leading to various impacts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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 \u003ccode\u003eGITHUB_TOKEN\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eIf possible, temporarily disable Gitea Actions for fork pull requests on sensitive repositories until a patch is available.\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003cli\u003eMonitor Gitea application logs for \u003ccode\u003eaction_run\u003c/code\u003e entries where \u003ccode\u003eneed_approval\u003c/code\u003e is \u003ccode\u003efalse\u003c/code\u003e but \u003ccode\u003eapproved_by\u003c/code\u003e is \u003ccode\u003e0\u003c/code\u003e for new fork pull requests, which could indicate exploitation.\u003c/li\u003e\n\u003cli\u003eMonitor Gitea Actions runner activity for suspicious shell commands (e.g., \u003ccode\u003ecurl\u003c/code\u003e to unusual destinations, \u003ccode\u003eid\u003c/code\u003e, \u003ccode\u003els -la\u003c/code\u003e in unexpected directories) originating from fork PR workflows, which would be visible in the runner's execution logs (\u003ccode\u003e/api/v1/repos/{owner}/{repo}/actions/jobs/{job_id}/logs\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-21T20:43:25Z","date_published":"2026-07-21T20:43:25Z","id":"https://feed.craftedsignal.io/briefs/2026-07-gitea-fork-pr-bypass/","summary":"A vulnerability in Gitea Actions (versions v1.20.0 and later) allows an unprivileged attacker to permanently bypass the fork pull request approval gate for a repository after a single, initial workflow approval, enabling arbitrary shell command execution on the Gitea Actions runner without further maintainer interaction, leading to source code disclosure and potential system compromise.","title":"Gitea Actions Fork Pull Request Approval Gate Bypass","url":"https://feed.craftedsignal.io/briefs/2026-07-gitea-fork-pr-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":true,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Gitea (v1.22.6)","Gitea (v1.23.8)","Gitea (v1.24.7)","Gitea (v1.25.5)","Gitea (v1.26.1)"],"_cs_severities":["critical"],"_cs_tags":["hmac-spoofing","data-exfiltration","supply-chain","gitea-actions"],"_cs_type":"threat","_cs_vendors":["Gitea"],"content_html":"\u003cp\u003eA 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 \u003ccode\u003eartifactName\u003c/code\u003e, \u003ccode\u003etaskID\u003c/code\u003e, and \u003ccode\u003eartifactID\u003c/code\u003e) 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 (\u003ccode\u003eDownloadArtifact\u003c/code\u003e path) or unauthorized cross-task artifact staging write and metadata mutation (\u003ccode\u003eUploadArtifact\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains legitimate execution permissions within Gitea Actions to run a job.\u003c/li\u003e\n\u003cli\u003eThe attacker creates their own Gitea Actions task, publishes an artifact, and obtains a legitimate signed URL for this attacker-controlled artifact.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a new URL by manipulating the \u003ccode\u003eartifactName\u003c/code\u003e, \u003ccode\u003etaskID\u003c/code\u003e, and \u003ccode\u003eartifactID\u003c/code\u003e parameters within the signed URL, specifically choosing values (e.g., \u003ccode\u003eartifactName=\u0026quot;artifact-795-1\u0026quot;\u003c/code\u003e, \u003ccode\u003etaskID=53\u003c/code\u003e, \u003ccode\u003eartifactID=48\u0026lt;attacker artifact id\u0026gt;\u003c/code\u003e) that, when concatenated, produce the same HMAC input as the original legitimate URL.\u003c/li\u003e\n\u003cli\u003eThe attacker, acting as an unauthenticated client, sends the forged URL as an HTTP GET request to the Gitea \u003ccode\u003e/api/actions/artifactsv4/DownloadArtifact\u003c/code\u003e endpoint to attempt data exfiltration.\u003c/li\u003e\n\u003cli\u003eGitea's server-side \u003ccode\u003everifySignature()\u003c/code\u003e function validates the HMAC of the forged URL as legitimate due to the underlying concatenation flaw.\u003c/li\u003e\n\u003cli\u003eThe server then proceeds to resolve the artifact using the attacker-controlled \u003ccode\u003etaskID\u003c/code\u003e and \u003ccode\u003eartifactName\u003c/code\u003e from the URL, which now points to a target task or artifact in a different repository.\u003c/li\u003e\n\u003cli\u003eGitea 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 \u003ccode\u003e/api/actions/artifactsv4/UploadArtifact\u003c/code\u003e to write arbitrary data into another running task's artifact staging area and mutate its metadata.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Gitea instances to a patched version immediately to remediate GHSA-hg5r-vq93-9fv6.\u003c/li\u003e\n\u003cli\u003eMonitor Gitea access logs for unusual download or upload patterns involving the \u003ccode\u003e/api/actions/artifactsv4/DownloadArtifact\u003c/code\u003e and \u003ccode\u003e/api/actions/artifactsv4/UploadArtifact\u003c/code\u003e endpoints, especially for unauthenticated requests or requests with unusual \u003ccode\u003etaskID\u003c/code\u003e or \u003ccode\u003eartifactID\u003c/code\u003e patterns in the query string.\u003c/li\u003e\n\u003cli\u003eImplement strong authentication and authorization policies for Gitea Actions job execution to limit potential attackers' initial access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-21T20:42:15Z","date_published":"2026-07-21T20:42:15Z","id":"https://feed.craftedsignal.io/briefs/2026-07-gitea-actions-artifacts-v4-hmac-ambiguity/","summary":"A vulnerability in Gitea Actions Artifacts V4 allows authenticated attackers, with permission to run an Actions job, to bypass intended access controls by manipulating signed artifact URLs, enabling unauthorized reading of artifacts from other repositories or writing arbitrary data to other tasks' artifact staging areas, potentially leading to data exfiltration or integrity compromise.","title":"Gitea Actions Artifacts V4 HMAC Ambiguity Allows Cross-Repository Data Access","url":"https://feed.craftedsignal.io/briefs/2026-07-gitea-actions-artifacts-v4-hmac-ambiguity/"}],"language":"en","title":"CraftedSignal Threat Feed - Gitea-Actions","version":"https://jsonfeed.org/version/1.1"}