CVE-2026-25718: Gitea Path Traversal Vulnerability

CVE-2026-25718 Overview

CVE-2026-25718 affects Gitea versions before 1.25.5. The vulnerability stems from improper path resolution during template repository generation. Template processing follows symbolic links and other non-regular paths, allowing read or write operations outside the intended repository directory. This is a link-following weakness classified under [CWE-59].

The flaw is network-exploitable without authentication or user interaction. An attacker with the ability to trigger template repository generation can leverage crafted symlinks to access or modify files on the Gitea host. Gitea released version 1.25.5 to address the issue.

Critical Impact
Unauthenticated network attackers can read or write arbitrary files through symlinked paths during template repository generation, compromising repository confidentiality and integrity.

Affected Products

Gitea versions prior to 1.25.5
Self-hosted Gitea instances exposing repository generation features
Gitea deployments allowing template repository creation

Discovery Timeline

2026-07-03 - CVE-2026-25718 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-25718

Vulnerability Analysis

Gitea supports template repositories that generate new repositories by copying and processing files from a source template. During this generation flow, Gitea walks the template's file tree and applies template rendering to eligible files. The vulnerability arises because the path resolution logic does not verify that each path being read or written is a regular file within the intended directory boundary.

When the template tree contains symbolic links or other non-regular file types, template processing follows those links. This causes reads to originate from, or writes to land in, arbitrary filesystem locations accessible to the Gitea process. The result is a symlink-following file system vulnerability that breaks the trust boundary between template content and host filesystem.

The issue is tracked in Gitea Pull Request #36734 and Pull Request #36746, which enforce regular-file checks and reject non-regular paths during generation.

Root Cause

The root cause is missing validation of file types and resolved path targets during template repository generation. Gitea traversed template contents without confirming that each entry was a regular file contained within the source repository. Symlinks were dereferenced by standard file I/O calls, so the effective read or write target could be any path readable or writable by the Gitea service account.

Attack Vector

An attacker prepares a repository that contains symbolic links pointing to sensitive files on the Gitea server. The attacker marks the repository as a template or supplies it as a template source. When any user, or the attacker themselves, generates a new repository from this template, Gitea processes the symlinked paths. Reads exfiltrate host file contents into the generated repository. Writes overwrite host files with attacker-controlled content, which can escalate to configuration tampering or code execution depending on the target file.

The vulnerability is exploitable over the network with no privileges and no user interaction required beyond triggering template generation.

Detection Methods for CVE-2026-25718

Indicators of Compromise

Gitea server version strings reporting a release earlier than 1.25.5 on the /api/v1/version endpoint
Unexpected symbolic links inside repositories flagged as templates via the is_template attribute
Newly generated repositories containing files with contents matching sensitive host paths such as /etc/passwd, app.ini, or SSH keys
Modifications to Gitea configuration files or on-disk secrets with timestamps aligned to repository generation events

Detection Strategies

Audit all repositories where is_template is true and inspect their file trees for symlinks or non-regular file entries
Correlate Gitea application logs showing POST /repo/create template generation calls with filesystem change events on the host
Compare file hashes of Gitea configuration, hook scripts, and SSH key material against known-good baselines
Scan repository storage on disk for symlinks whose targets resolve outside the repository root

Monitoring Recommendations

Enable filesystem integrity monitoring on the Gitea data directory and system configuration paths
Forward Gitea access logs and audit events to a centralized log platform for correlation with repository creation activity
Alert on template repository creation from newly registered or low-reputation accounts
Track outbound content of newly generated repositories for signatures of host configuration files or credentials

How to Mitigate CVE-2026-25718

Immediate Actions Required

Upgrade Gitea to version 1.25.5 or later on all self-hosted instances
Review existing template repositories and remove any containing symbolic links or non-regular files
Rotate credentials, tokens, and SSH keys stored on the Gitea host if exposure through template generation is suspected
Restrict template repository creation to trusted users until patching is complete

Patch Information

Gitea addressed CVE-2026-25718 in the v1.25.5 release. The fix enforces that only regular files within the template repository boundary are read or written during generation. Details are available in the Gitea 1.25.5 Release Blog and the associated pull requests #36734 and #36746.

Workarounds

Disable the template repository feature by removing the is_template flag from repositories until an upgrade is applied
Run the Gitea service under a dedicated low-privilege account with filesystem access limited to its data directory
Apply mandatory access controls, such as AppArmor or SELinux profiles, that constrain Gitea reads and writes to the repository storage path
Place Gitea behind an authenticated reverse proxy and disallow anonymous repository creation while triaging the environment

bash

# Verify installed Gitea version and confirm upgrade
gitea --version

# Example: upgrade a Docker-based deployment to the patched release
docker pull gitea/gitea:1.25.5
docker stop gitea && docker rm gitea
docker run -d --name gitea \
  -v /var/lib/gitea:/data \
  -p 3000:3000 -p 2222:22 \
  gitea/gitea:1.25.5