Anyone who hosts source code themselves entrusts their Git platform with some of the organisation’s most sensitive data: source code, credentials, CI/CD secrets and deployment keys. This is precisely where two recent vulnerabilities in Gitea come into play – a widely used self-hosted alternative to GitHub and GitLab. CVE-2026-59774 allows unauthenticated attackers to read any files from the server and can be exploited to execute arbitrary code. Along with CVE-2026-60004 the vulnerability in Gitea 1.27.1 has been patched. We explain what’s behind it and what you should do now.
What has happened?
Gitea is a lightweight Git platform written in Go, which many organisations run in their own data centers or in private clouds. Security researchers have now disclosed two critical vulnerabilities, both of which were fixed in version 1.27.1. The more serious of the two, CVE-2026-59774, which received a CVSS score of 9.8 out of 10 and is therefore classified as critical.
The root of the problem lies in Gitea’s Org-mode renderer. The application initialised the underlying library go-orgwithout overriding the standard callback for reading files. This allowed the Org-mode directive #+INCLUDE with absolute file paths to be used to load any files to which Gitea’s service account has access. The vulnerability is triggered via a specially crafted request to the endpoint POST /{owner}/{repo}/markup with file mode enabled.
Particularly serious: no login is required to carry out the attack. All that is needed is access to a public repository in which the code unit is enabled. This means the vulnerability also affects servers that deliberately host public projects.
From file access to complete takeover
Read-only access to files may sound manageable at first, but in practice it triggers a dangerous chain reaction. Attackers can gradually work their way up from a seemingly harmless read operation to a complete server takeover.
Reading the configuration
The vulnerability allows the central configuration file app.ini and use it to extract the secret INTERNAL_TOKEN can be extracted from it.
Inject a Git hook
Using the stolen token, a manipulated Git hook can be placed on the server via the internal logger.
Execute code
The next time an anonymous clone is performed, the hook is triggered and executes arbitrary code within the context of the Gitea service. This turns a simple file read into a remote code execution.
This combination of a lack of authentication, a high CVSS score and a clear path to code execution makes the vulnerability a prime target. Experience shows that known, easily discoverable instances on the internet are quickly targeted by automated scans.
Are we affected?
All Gitea versions from 1.22.1 up to and including 1.27.0 are affected. Anyone using one of these versions and hosting at least one public repository with a code unit enabled should assume they are at immediate risk. You can check your access logs to assess whether your instance has already been probed.
Check your logs specifically for anonymous POSTrequests to /{owner}/{repo}/markup, particularly those targeting the Org-mode renderer. There are currently no known instances of active exploitation in the wild, and the vulnerability has not yet been included in the US public authority CISA’s ‘Known Exploited Vulnerabilities’ catalogue. However, this is no reason to let your guard down; rather, it simply provides a window of opportunity to take action.
Tip: Do not rely solely on the fact that there is nothing suspicious in the logs. The absence of traces does not necessarily mean that no access has taken place. As a precaution, treat a vulnerable instance as potentially compromised until proven otherwise.
What should you do now?
The most important measure is clear and urgent: update your Gitea installation immediately to version 1.27.1 or later. The patch overrides the faulty file callback so that include paths are returned as plain text only, rather than actually being resolved from the file system.
If you suspect that your instance was already accessible and vulnerable prior to the update, simply applying the patch will not be sufficient. Any secrets that may have been leaked INTERNAL_TOKEN will otherwise remain valid. In this case, you must consistently rotate all relevant secrets:
- Internal tokens for the Gitea instance
- OAuth credentials and stored application secrets
- JWT signing keys for tokens and sessions
- Database credentials, provided that a breach has been confirmed via the logs
A common misconception is that everything is sorted once the update has been applied. However, if the server has already been compromised, attackers may have established a permanent foothold via injected hooks, additional accounts or stored keys. A patch closes the door, but does not remove intruders already inside the system.
Mint Secure GmbH
How Mint Secure supports you
Whether this specific vulnerability affects you or you simply want to ensure that critical vulnerabilities do not remain undetected for weeks on end: we support you every step of the way, from analysis through to long-term hardening.
Vulnerability Management
We identify vulnerable systems in your environment, assess the risk realistically and prioritise the appropriate countermeasures.
Penetration Testing
In controlled tests, we check your self-hosted services for exploitable vulnerabilities before attackers do.
Incident Response
If a breach is suspected, we analyse the incident, preserve evidence and support you in a clean recovery.
Want to secure your Git infrastructure? We offer a free initial consultation to assess your needs together. Get in touch.
Conclusion
CVE-2026-59774 and CVE-2026-60004 demonstrate how quickly a seemingly harmless rendering function can become a pathway to complete server takeover. An unauthenticated vulnerability with a CVSS score of 9.8 in a platform that manages source code and secrets is one of those scenarios that should not be put on the back burner.
Update affected instances to Gitea 1.27.1 immediately, check your access logs and, if you suspect a breach, rotate all secrets without fail. If you self-host, you need a reliable process to detect such reports early and respond swiftly.
Mint Secure provides consulting and support as you make your systems resilient and ensure you remain capable of taking action in the event of an incident. Talk to us.
