Description

Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-06T20:17:34.867Z",
  "pubdate": "2026-10-06T20:17:34.867Z",
  "executiveSummary": "This vulnerability involves a path resolution inconsistency in Gitea when processing malformed Git tree objects containing duplicate file entries. By injecting trees with identical names, an attacker can manipulate Gitea's web-based interface to display benign content while ensuring that backend operations, such as CI/CD workflows and local checkouts, operate on malicious, attacker-controlled data.\nThe vulnerability stems from a discrepancy in how Gitea's web views parse Git trees versus how standard Git binaries handle file resolution. While Gitea resolves the path to the first occurrence, Git internals (used by Gitea Actions and release exports) prioritize the last entry. This creates a significant security risk for software supply chain integrity, as automated testing and distribution mechanisms become decoupled from the source code audited through the web interface.\nExploitation requires the ability to push specially crafted Git trees to a repository. Once accepted, the inconsistency persists within the repository state. The impact is critical, as it facilitates the injection of malicious code that remains invisible to repository reviewers using the Gitea UI but executes during the build and deployment lifecycle.\nThis issue represents a failure in input validation where Gitea failed to enforce Git-native consistency checks at the object ingestion layer.",
  "technicalDetails": "The root cause of this vulnerability is a logic discrepancy in Git tree object parsing between Gitea's web frontend and the underlying Git implementation. In the Git object model, a tree object can theoretically contain multiple entries with the same name. Standard Git consistency checks reject such objects; however, Gitea previously accepted these objects without performing necessary validation.\nThe exploit flow utilizes the differential behavior in path resolution: Gitea's web-based file browser and diff viewer resolve a path to the first entry encountered in the tree list, whereas standard Git tools—including 'git checkout', Gitea Actions (CI), and automated release archive generation—resolve the same path to the last entry in the tree list. An attacker can craft a malicious Git object that contains two entries for the same file path. The first entry contains benign, readable code intended for peer review, while the second entry contains malicious payloads.\nWhen a contributor views the Pull Request or the repository file tree in the Gitea UI, they perceive the benign content. Simultaneously, when the Gitea Actions runner fetches the repository or a developer performs a 'git checkout', the Git client ignores the first entry in favor of the second, effectively swapping the benign source code for the attacker-controlled code during the build process.\nThis discrepancy occurs because the Gitea application logic for rendering the UI was independent of the standard Git object verification routines. The system failed to treat incoming Git tree objects with the same level of strictness as the Git command-line interface, allowing malformed data to enter the repository state. Because Gitea did not perform consistency validation upon object reception, the malicious tree is committed to the repository history.\nThe impact is severe for repository integrity and CI/CD security. The 'source of truth' viewed by developers in the browser is effectively untethered from the 'source of truth' processed by automated infrastructure. Once the malformed tree is stored, the inconsistency remains, as Gitea only mitigates this by checking incoming objects, leaving existing repository states vulnerable to exploitation if they contain such artifacts. Authentication is required to push to a repository, but the vulnerability can be leveraged by any actor with sufficient permissions to commit code, potentially leading to widespread supply chain compromise via malicious build artifacts."
}