CVE-2025-68939: Gitea Path Traversal Vulnerability

CVE-2025-68939 Overview

CVE-2025-68939 is a business logic vulnerability in Gitea versions prior to 1.23.0. The flaw allows attackers to bypass file extension restrictions by editing an attachment name through the attachment application programming interface (API). Gitea enforces a list of forbidden file extensions during upload, but the rename operation exposed by the API does not re-validate the new filename. Attackers can upload a benign file and then rename it to a forbidden extension, defeating the platform's file type controls. The issue is tracked under Common Weakness Enumeration [CWE-424] (Improper Protection of Alternate Path) and was resolved in Gitea 1.23.0.

Critical Impact
Unauthenticated or low-privileged attackers can store files with restricted extensions on Gitea instances, undermining upload allow-list controls and enabling potential downstream abuse.

Affected Products

Gitea versions before 1.23.0
Self-hosted Gitea deployments exposing the attachment API
Gitea instances relying on file-extension deny-lists for content control

Discovery Timeline

2025-12-26 - CVE-2025-68939 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-68939

Vulnerability Analysis

Gitea maintains a configurable list of forbidden file extensions that attachments cannot use during upload. This control is intended to prevent users from storing executable scripts, binaries, or other high-risk file types on the server. The upload endpoint validates the extension at creation time, but the attachment API also exposes an edit operation that permits renaming an existing attachment.

The rename path does not re-apply the forbidden-extension check. An attacker uploads a file with an allowed extension, then issues an edit request that changes the attachment's stored name to include a restricted extension. The server persists the new name without validation, storing the file under a restricted type.

The fix, delivered in Gitea 1.23.0 via pull request #32151, extends extension validation to the attachment edit handler so the same allow-list logic runs on rename.

Root Cause

The root cause is inconsistent input validation across two code paths that operate on the same resource. Upload enforces the deny-list; rename does not. This mismatch is characteristic of [CWE-424], where an alternate path to the protected resource lacks equivalent controls.

Attack Vector

An attacker with the ability to upload attachments to a repository, issue, or release sends a normal upload request using a permitted extension such as .txt. The attacker then calls the attachment edit API with the same attachment identifier and supplies a new filename ending in a forbidden extension. The server accepts the change, and subsequent downloads serve the file under the restricted name.

See the Gitea Release Announcement for 1.23.0 and the upstream patch for implementation details.

Detection Methods for CVE-2025-68939

Indicators of Compromise

Attachment records where the stored filename extension differs from the extension recorded at initial upload time.
Attachments whose extensions match entries in the Gitea FORBIDDEN_TYPES or attachment allow-list configuration.
HTTP PATCH or edit requests to /api/v1/repos/{owner}/{repo}/issues/comments/{id}/assets/{attachment_id} shortly after an upload from the same user.

Detection Strategies

Audit the Gitea database attachment table for filenames ending in restricted extensions such as .exe, .sh, .js, or .html depending on your configured deny-list.
Correlate upload and edit API calls per attachment identifier to surface rename-after-upload patterns in access logs.
Alert on any attachment API request that modifies the name field to a value with a different extension than the original.

Monitoring Recommendations

Forward Gitea access logs and application logs to a centralized log platform for retention and query.
Track anomalous volumes of attachment edit requests per user account and repository.
Baseline normal attachment file types per project so deviations trigger investigation.

How to Mitigate CVE-2025-68939

Immediate Actions Required

Upgrade all Gitea instances to version 1.23.0 or later.
Inventory existing attachments and remove or quarantine any files whose current extension is on the forbidden list.
Restrict attachment upload permissions to trusted authenticated users where feasible.

Patch Information

The vulnerability is fixed in Gitea 1.23.0. The upstream fix is available in GitHub Pull Request #32151 and shipped in the Gitea v1.23.0 release. Administrators should follow the standard Gitea upgrade procedure, back up the database and repository storage, and validate service health after upgrade.

Workarounds

Place Gitea behind a reverse proxy that blocks PATCH requests to attachment endpoints until the patch is applied.
Serve attachment downloads with a fixed Content-Type and Content-Disposition: attachment header to reduce risk from restricted file types stored on the server.
Disable anonymous or self-service registration so attachment API access requires vetted accounts.

bash

# Configuration example: enforce download headers and disable open registration in app.ini
[service]
DISABLE_REGISTRATION = true
REQUIRE_SIGNIN_VIEW = true

[attachment]
ENABLED = true
ALLOWED_TYPES = image/jpeg,image/png,application/pdf,text/plain
MAX_SIZE = 4