Gitea Org-mode flaw turns public repositories into a server file-read risk

Gitea administrators have a critical patch to verify. The project has fixed CVE-2026-59774, an unauthenticated arbitrary file-read flaw that affects self-hosted Gitea versions 1.22.1 through 1.27.0 and is patched in 1.27.1. The weakness sits in the way Gitea handled Org-mode #+INCLUDE directives during markup rendering.

The issue is severe because the entry point can be a normal public repository. According to Gitea's security advisory, an anonymous attacker can send crafted Org-mode markup to POST /{owner}/{repo}/markup for a suitable public repository and read arbitrary files that the Gitea service user can access. If sensitive configuration files are exposed, the file-read primitive can become a path toward remote code execution.

This is not just a source-code hosting bug. Self-hosted Git platforms often sit near deployment credentials, CI/CD secrets, OAuth integrations, internal tokens, SSH material, database credentials, package publishing workflows, and webhook infrastructure. A file-read vulnerability on that control plane can quickly become a secret-exposure and incident response problem.

What happened

Gitea released version 1.27.1 on July 27, 2026, with security fixes for CVE-2026-59774 and CVE-2026-60004. The formal GitHub Security Advisory for CVE-2026-59774 was published on August 2 and rates the flaw as Critical, with a CVSS score of 9.8.

The vulnerable path involves Gitea's markup endpoint. Gitea registers POST /{username}/{reponame}/markup with optional sign-in, repository assignment, and a repository-unit reader check. For a public repository with a readable code unit, an anonymous request can pass the relevant access check.

The attacker then chooses Org-mode rendering by submitting Mode: file and a .org filename. In vulnerable builds, Gitea initialized the go-org library using its default file-reading callback. Org-mode's #+INCLUDE directive accepts file paths; with the default callback still active, an attacker could cause the renderer to read local files from the server.

The Gitea fix changed that behavior so include paths are rendered as plain content instead of being resolved against the server filesystem. The fix landed in pull request #38642 and was backported in #38645.

Why this matters

Arbitrary file read is sometimes underestimated because it does not always look like immediate code execution. On a developer platform, that assumption is dangerous. Gitea's own advisory describes a possible chain in which an attacker reads app.ini, extracts INTERNAL_TOKEN, injects a Git hook through the internal logger, and reaches command execution as the Gitea operating-system user during an anonymous clone.

Even when that full chain is not observed, the file-read capability is enough to create material risk:

• app.ini may expose internal tokens, database connection strings, signing material, OAuth client secrets, and operational metadata.
• Repository and runner configuration may reveal deployment paths, webhook targets, or CI/CD assumptions.
• SSH keys, service account files, backup metadata, and environment files may be accessible depending on how the host was configured.
• A public repository can become the route into private operational data if the service account has broad filesystem access.

That makes CVE-2026-59774 a reminder that access control in source-code platforms is more than repository permissions. The operating-system boundary, service-user privileges, configuration-file permissions, and renderer sandboxing all matter.

Who is affected

Gitea's advisory lists affected versions as 1.22.1 through 1.27.0. The patched version is 1.27.1.

The unauthenticated path depends on at least one public repository with a normal readable code unit that can reach the markup route. Instances with no public repositories may not expose the same anonymous route, but they should still upgrade. The vulnerable code path exists in the affected versions, and relying on current repository visibility as the only mitigation is brittle.

Gitea Cloud instances were scheduled for automatic upgrade during the release maintenance window. Self-hosted administrators need to confirm their own version, restart state, and package source.

What defenders should do now

The first step is straightforward: upgrade self-hosted Gitea to 1.27.1 or later. Then verify the running binary and container image, not only the package manager state. In containerized deployments, confirm that the updated image is actually running and that old pods, services, or rollback targets are not still reachable.

After patching, treat exposure as a secrets-review exercise:

• Check whether the instance had public repositories while running an affected version.
• Review web access logs for anonymous POST requests to /{owner}/{repo}/markup.
• Look for requests that select Org-mode rendering, use Mode: file, reference .org paths, or include absolute filesystem paths.
• If suspicious activity appears, assume files readable by the Gitea service user may have been exposed.
• Rotate INTERNAL_TOKEN, OAuth secrets, JWT signing material, database credentials, webhook secrets, deployment keys, and any CI/CD tokens stored on the host.
• Review Git hooks, repository hook directories, custom scripts, and service-user writable paths for unexpected executable content.
• Check anonymous clone activity around suspicious markup requests.

Where centralized logging is available, a starting search should focus on the markup endpoint:

index=web sourcetype IN (nginx, apache, gitea)
method=POST uri_path="*/markup"
| stats count min(_time) max(_time) values(src_ip) values(user_agent) by host uri_path status

For reverse proxies, also inspect request bodies if your retention and privacy model allow it. The most useful signals are not just the endpoint path, but the submitted rendering mode and file references.

Reduce the blast radius

Patching closes the software flaw, but the defensive lesson is broader. A self-hosted Git platform should not run with unnecessary read access across the host. Configuration files should be permissioned tightly. Secrets should be stored outside web-readable and renderer-reachable paths where possible. Backup material, SSH keys, runner tokens, and deployment credentials should not be casually readable by the main web service user.

Administrators should also revisit public repository policy. Public repositories are meant to expose code, not server-side rendering privileges that can touch local files. If public repositories are not required, disable them or restrict anonymous features. If they are required, keep extra attention on endpoints that transform user-controlled markup, documentation, diagrams, templates, or archive content.

For larger environments, Gitea belongs in the same monitoring tier as CI/CD, artifact registries, and identity infrastructure. Alert on configuration reads, hook creation, new OAuth applications, token changes, runner enrollment, webhook edits, and unusual clone patterns. Those are the places where a file-read bug can turn into operational control.

The takeaway

CVE-2026-59774 is a clean example of a small parser integration decision becoming a platform-level exposure. Org-mode includes are a documentation feature; inside a server-side renderer, they became a way to reach the filesystem.

The immediate action is to upgrade to Gitea 1.27.1 and review markup endpoint activity. The longer-term lesson is to treat self-hosted developer platforms as high-value control planes. If attackers can read their configuration, they may not need to break the build pipeline directly. They can steal the material that tells the pipeline whom to trust.

References

1. Unauthenticated Arbitrary File Read can lead to RCE
2. Gitea 1.27.1 is released
3. fix: orgmode render include path
4. fix: orgmode render include path (#38642)
5. Critical Gitea Flaw Let Unauthenticated Attackers Read Server Files via Org-Mode Markup