CVE-2025-68939
NixOS vulnerability analysis and mitigation

Overview

CVE-2025-68939 is a file extension bypass vulnerability in Gitea's attachment API that allows attackers to upload attachments with forbidden file extensions by renaming them via the API. It affects all Gitea versions before 1.23.0 and was published on December 25–26, 2025. The fix was included in Gitea v1.23.0, released January 9, 2025. CVSS scores differ by source: NVD assigns 5.3 (Medium) while MITRE/GitHub Advisory assigns 8.2 (High) (Github Advisory, bugzilla.redhat.com).

Technical details

The root cause is classified as CWE-424 (Improper Protection of Alternate Path): Gitea's attachment upload flow enforced file extension restrictions at the point of initial upload, but the edit attachment API endpoints — used to rename existing attachments — did not apply the same extension validation (Github Advisory, Gitea PR #32151). Issue posters and users with repository write access could exploit this by first uploading a permitted file type, then using the edit attachment API to rename it to a forbidden extension (e.g., .exe, .php). The fix (PR #32151) added file extension checks to the attachment edit API endpoints, ensuring the same restrictions applied at both upload and rename time (Gitea PR #32151).

Impact

Successful exploitation allows an attacker to store files with otherwise-blocked extensions (such as executables or scripts) within a Gitea instance, bypassing the administrator-configured attachment type restrictions. This primarily affects integrity — malicious files could be disguised and distributed to other users who download attachments from issues, comments, or releases. In scenarios where Gitea serves attachments that are subsequently executed or processed by downstream systems, this could facilitate code execution or further compromise (Github Advisory, Gitea PR #32151).

Exploitability

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.036% (Feedly data) to 0.012% (GitHub Advisory), placing it in a very low percentile for near-term exploitation likelihood. Exploitation requires the attacker to have at least issue poster or repository write access, which limits the attack surface to authenticated users (Github Advisory).

Exploitation steps

  1. Obtain access: Authenticate to a vulnerable Gitea instance (before v1.23.0) as any user with issue poster or repository write access.
  2. Upload a permitted file: Attach a file with an allowed extension (e.g., .txt or .png) to an issue, comment, or release via the normal upload mechanism.
  3. Retrieve the attachment ID: Note the attachment UUID/ID returned by the API or visible in the response after upload.
  4. Rename via API: Send a PATCH or PUT request to the attachment edit API endpoint (e.g., /api/v1/repos/{owner}/{repo}/issues/attachments/{attachment_id}) with a modified name field using a forbidden extension (e.g., malicious.exe or shell.php).
  5. Distribute the file: Share the issue, comment, or release link containing the now-renamed attachment with target users, who may download and execute the file (Gitea PR #32151, Github Advisory).

Indicators of compromise

  • Logs: Gitea access logs showing API PATCH/PUT requests to attachment edit endpoints (e.g., /api/v1/repos/.*/issues/attachments/ or /api/v1/repos/.*/releases/assets/) where the resulting filename has a forbidden extension (e.g., .exe, .php, .sh, .bat).
  • File System: Presence of files with executable or script extensions in the Gitea attachment storage directory that do not match the configured ALLOWED_TYPES policy.
  • Application Logs: Gitea application logs may show attachment rename operations that would not have been permitted through the normal upload UI.
  • Network: Unusual API activity from authenticated users making repeated attachment edit requests, particularly renaming files to executable extensions shortly after upload.

Mitigation and workarounds

Upgrade Gitea to version 1.23.0 or later, which includes the fix from PR #32151 that adds file extension validation to the attachment edit API endpoints (Gitea v1.23.0 Release). As a temporary workaround prior to upgrading, administrators can restrict attachment upload permissions to trusted users only, or configure the ALLOWED_TYPES setting to an empty list (allowing all types) and rely on other controls — though this removes extension-based filtering entirely. Reviewing existing attachments for files with suspicious extensions is also recommended (Feedly).

Community reactions

The vulnerability received brief coverage from security news aggregators and social media accounts such as TheHackerWire on Mastodon and Bluesky shortly after disclosure on December 26, 2025. Red Hat tracked the issue via Bugzilla and assigned it high priority/severity. The CISA vulnerability bulletin for the week of December 22, 2025 referenced the CVE. No significant vendor statements beyond the Gitea release notes or notable independent researcher commentary have been identified.

Additional resources


SourceThis report was generated using AI

Related NixOS vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-13097HIGH8.7
  • NixOS logoNixOS
  • freeipa-common
NoYesAug 20, 2026
CVE-2026-73198HIGH7.5
  • NixOS logoNixOS
  • ctdb-ceph-mutex
NoYesAug 20, 2026
CVE-2026-73197HIGH7.5
  • NixOS logoNixOS
  • ipa-server-trust-ad
NoYesAug 20, 2026
CVE-2026-73196MEDIUM6.5
  • NixOS logoNixOS
  • freeipa-server-dns
NoYesAug 20, 2026
CVE-2026-64777MEDIUM4.3
  • NixOS logoNixOS
  • container
NoYesAug 20, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management