Gitea CVE-2026-59774: a public repository could read server files

Gitea has disclosed CVE-2026-59774, a critical vulnerability in its handling of Org-mode documents. Under affected configurations, an anonymous user could place a local-file reference in a public repository and the server would retrieve the content with the privileges of the Gitea process while rendering the document. An ordinary repository text file effectively became an interface to the host filesystem.

This is an important case for teams running their own Git service. No password was stolen and no cryptography was broken. The trust-boundary failure appeared in a convenient presentation feature that ran automatically when the application displayed user-controlled content.

How the vulnerability worked

The Org-mode renderer resolves embedded references to build a document preview. According to the CVE-2026-59774 record, validation did not properly separate repository resources from local paths. A rendering request could therefore open a file outside the repository directory.

The attack was particularly serious because it did not require an account where an attacker could reference or create publicly visible content. Reads occurred in the service account’s context, so the real reach depended on process permissions, installation mode, container mounts and the location of secrets.

Potential targets included Gitea configuration, private keys, integration tokens, database credentials and environment files. A file read is not automatically code execution, but a recovered secret may unlock the API, database, CI environment or administrator accounts. Risk assessment must therefore follow the dependency graph rather than stop at the Git server.

Who was exposed

Affected releases are listed in the vendor advisory, and fixes are available in current versions published by the Gitea project. Internet-facing instances, services with public registration or repositories, and installations storing secrets within reach of the same operating-system user deserve the highest priority.

A container does not solve the problem by itself. If operators mounted the Docker socket, a host home directory, deployment files or a volume shared with a CI runner, a local read inside the container may reach far beyond the application. Secure deployment should assume that a content renderer can be attacked.

Technical response plan

1. Upgrade Gitea to a fixed release and verify the version of the running process, not only the image stored in a registry.
2. Until the upgrade is complete, restrict public access and disable Org-mode rendering if the deployment supports that option.
3. Search repositories and HTTP logs for unusual Org-mode files, absolute paths, traversal sequences and repeated preview requests.
4. Establish exactly which files the Gitea service account could read. Treat that set as the potential disclosure boundary.
5. Rotate keys and tokens within that boundary, including database, SMTP, OAuth, webhook, package-registry and runner credentials.
6. Remove unnecessary mounts, block container-socket access and run the service as a dedicated unprivileged user with minimal rights.
7. Preserve reverse-proxy, Gitea, database and CI logs before rebuilding the server so the response does not destroy evidence.

Detection requires reconstructing renderer activity

Ordinary access logs may show only a valid repository page request because file opening occurred inside the process. Correlate rendering times with operating-system logs, file-access auditing and calls to services whose secrets were stored on the host. A Gitea process suddenly reading SSH directories, database configuration or files outside its working tree is a stronger signal than an HTTP status alone.

For future containment, an AppArmor or SELinux profile should let the service read only its executable files, configuration and own data. Secrets can be delivered by a credential manager to the process that needs them instead of storing the complete set in readable files. A separate rendering worker without network access or production configuration limits the blast radius of another parser defect. Regression tests should cover absolute paths, encoded separators, symlinks and references that begin inside an allowed directory but resolve outside it.

Primary facts versus Breachroad analysis

Public material confirms the arbitrary-file-read class, an unauthenticated scenario and an available fix. It does not establish mass exploitation of every vulnerable instance. The possible-secret list depends on local deployment and describes exposure, not proof of theft.

Breachroad’s conclusion is to treat every document renderer as an untrusted-code parser. Secure-development training should cover parser and secret boundaries, while web and API penetration testing can assess preview, import and content-conversion features as well as conventional endpoints.