Critical Gitea CVE-2023-48093 vulnerability lets attackers run remote code
Key Takeaways A critical remote code execution (RCE) vulnerability, CVE-2023-48093, has been discovered in Gitea. This flaw impacts Gitea versions 1.17 through 1.27.0, allowing attackers with...
Key Takeaways
- A critical remote code execution (RCE) vulnerability, CVE-2023-48093, has been discovered in Gitea.
- This flaw impacts Gitea versions 1.17 through 1.27.0, allowing attackers with repository write access to execute arbitrary shell commands.
- The vulnerability carries a CVSS v3.1 score of 9.8 (Critical) and can be exploited on publicly accessible instances with open registration.
- A patch is available in Gitea version 1.27.1; immediate upgrade is strongly recommended.
A severe vulnerability in the Gitea self-hosted Git service, tracked as CVE-2023-48093, presents a critical risk of remote code execution on affected servers. This flaw could allow malicious actors to run arbitrary shell commands, impacting Gitea versions ranging from 1.17 up to and including 1.27.0. The issue has since been addressed in Gitea version 1.27.1.
Table Of Content
Understanding the Vulnerability
The core of the vulnerability lies within Gitea’s diffpatch endpoint, which is responsible for processing repository patches using Git commands. An attacker who possesses standard write access to a repository can leverage this functionality to inject a malicious Git hook into a temporary bare repository clone created by Gitea.
Crucially, because the root directory of this temporary clone functions as Git’s own directory, a specially crafted file placed at hooks/post-index-change is treated as an active Git hook rather than just ordinary repository content.
The attack sequence begins when the same maliciously crafted patch is submitted twice. Gitea then uses the git apply command with index-related options to process this patch, inadvertently activating the malicious content.
Exploitation Mechanism
For Git versions 2.32 and newer, Git may perform a three-way merge fallback when it detects an “add/add” collision. During this process, Git checks out the indexed path, even when the operation is executed using the --cached option. In a bare Git repository context, this behavior is particularly dangerous because the repository root itself acts as the Git directory. Consequently, a malicious executable file written to hooks/post-index-change is recognized and executed as a live hook while Git updates its index.
This allows attacker-controlled commands to execute with the privileges of the operating system account running the Gitea service.
Severity and Impact
According to the GitHub Security Advisory (GHSA-rcr6-4jqh-j84m), this vulnerability has been assigned a CVSS v3.1 score of 9.8 (Critical). This high score reflects several factors: a network attack vector, low attack complexity, no user interaction required, and significant impacts on confidentiality, integrity, and availability.
The flaw falls under CWE-94, which denotes “Improper Control of Code Generation,” or code injection. While exploiting this vulnerability requires write access to a repository, this condition can be easily met on Gitea instances where public registration is enabled. An unauthenticated visitor could simply register an account, create a repository, and then exploit the vulnerable diffpatch route to trigger code execution. This makes publicly accessible Gitea deployments particularly susceptible.
Successful exploitation could expose sensitive Gitea resources, including the app.ini configuration file, application secrets, environment variables, mounted repositories, database credentials, OAuth tokens, and integration credentials. The ultimate severity of the exploit depends on the permissions granted to the Gitea service account and the server’s isolation controls.
To carry out the attack, the threat actor needs Git version 2.32 or newer on the server, an enabled diffpatch route, and a temporary filesystem that permits both writing and executing files. Reports indicate that proof-of-concept exploits can retrieve command output via Git objects and authenticated Smart HTTP, suggesting that an outbound network connection from the target host might not be necessary for exfiltration.
What You Should Do
- Upgrade Immediately: Administrators must promptly upgrade Gitea to version 1.27.1 or later to apply the official patch.
- Disable Public Registration: If an immediate upgrade is not feasible, disable public registration on your Gitea instance to prevent unauthorized users from gaining repository write access.
- Restrict Diffpatch Functionality: Limit or disable access to the
diffpatchfunctionality if it is not essential for your operations. - Review Permissions: Audit and restrict repository write permissions to only trusted users. Additionally, review the privileges assigned to the Gitea service account, adhering to the principle of least privilege.
- Monitor Logs: Actively monitor Gitea and Git logs for any unusual patch submissions or unexpected activity related to Git hooks.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.