Gitea patched CVE-2026-59774, a CVSS 9.8 flaw that could let unauthenticated attackers read server files and potentially reach RCE.
The open-source Git service platform Gitea recently disclosed and patched CVE-2026-59774, a critical vulnerability rated 9.8 on the CVSS 3.1 scale. According to a report by ITNEWS ISC, a remote attacker does not need to log in; as long as a publicly accessible repository exists on the target server, they may be able to read files on the server through the document processing feature, obtain an internal access token, and ultimately even achieve code execution.[4]
The core risk of this vulnerability is that the attack entry point does not require prior repository write privileges, and the attacker does not need to upload malicious files. As long as a public repository is readable from the outside, it may become an exploitation point.[4] The official fix was completed in Gitea 1.27.1, and the affected versions range from 1.22.1 to 1.27.0.[4][5]
CVE-2026-59774 occurs in Gitea's Org-mode document handling flow. Gitea provides a document preview feature so users can browse content in specific formats, but Org-mode itself supports loading other files from specified paths. The original processing flow did not effectively prevent this capability from accessing local files on the server, allowing attackers to submit specially crafted content and trick Gitea into reading files that should not be public.[4][5]
This type of issue is fundamentally a defect in document parsing and path access control. From an external perspective, the attacker is only interacting with a preview or rendering endpoint; but on the server side, the renderer is actually forced to read local files, leading to sensitive information disclosure.[4][5] Related reports also note that the scope of exploitation depends on what file access permissions the Gitea service account itself has, meaning the privilege boundary of the service identity directly affects the range of data that can be read.[4]
More seriously, this is not just a data exposure issue. Gitea's security advisory states that if an attacker reads the internal access token from the main system configuration file, they may be able to use Gitea's internal functions to write a Git hook, causing Git to automatically execute a specified command during certain operations.[4][3] In this attack chain, an unauthenticated user can trigger the hook when cloning the repository, allowing the malicious command to execute on the server with the permissions of the Gitea service account and creating a remote code execution risk.[4][3]
From the attack flow perspective, this means the vulnerability has a multi-stage pattern of "file read first, privilege escalation second, execution last": first, Org-mode rendering is used to read local files; second, an internal token is extracted from the configuration file; third, an internal function is used to implant a hook; and fourth, the command is triggered during an anonymous clone or related operation.[4][3] This is also why both the vendor and the media classify it as a high-risk vulnerability that can escalate from unauthenticated access all the way to RCE.[4][3]
The affected versions are Gitea 1.22.1 through 1.27.0, and the patched version is 1.27.1.[4][5][7] Any environment with publicly readable repositories that can trigger the related document rendering flow may become an attack entry point.[4][5]
The actual level of risk is also affected by deployment style and permission settings. If the Gitea service account has broader local file read permissions, more content can be read by the attacker; if system configuration files or tokens are inadequately protected, the attack chain is easier to complete.[4][8]
Multiple security sources emphasize that externally exposed Gitea instances are at the highest risk, especially in scenarios that allow anonymous access to public repositories.[4][5][7]
The most direct and effective measure is to immediately upgrade to Gitea 1.27.1 or a newer version.[4][5][7]
If you suspect the system has been exposed or attempted to be exploited, you should also check logs, rotate any secrets that may have leaked, and confirm whether there is any abnormal hook activity.[3][8] Related recommendations include reviewing the permissions of `app.ini` and confirming that Gitea is not running as root.[2][8]
If you cannot upgrade immediately in the short term, at minimum you should temporarily reduce exposure of public repositories and closely monitor abnormal requests to markup-related endpoints.[7][13]
If signs of configuration file reading, token leakage, abnormal clone behavior, or hook-related activity are already present in the environment, it is recommended to further rotate INTERNAL_TOKEN and related credentials to prevent an attacker from continuing lateral exploitation after obtaining a single read opportunity.[8][3]