Gitea CVE-2025-68939

Requires an authenticated caller able to reach the attachment edit endpoints (EditIssueAttachment, EditIssueCommentAttachment, or EditReleaseAttachment) with rights to modify an existing attachment on an issue, comment, or release. The specific precondition is that pre-1.23.0 Gitea enforced the configured AllowedTypes allow-list only during UploadAttachment and not during the attachment-name update path, so the attacker must first create a valid attachment and then rename it via the API. LIMITING FACTORS: exploitation only matters when the instance relies on the AllowedTypes allow-list to restrict extensions (default AllowedTypes is unrestricted in many deployments, limiting impact); it requires API access and attachment-management privileges rather than fully anonymous access; and impact is confined to storing/serving a disallowed extension, not code execution on the server.

This is a low-to-moderate priority issue despite the 'high-sounding' exploit-bypass framing. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) scores 5.3 (Medium) with only Integrity-Low impact (C:N/I:L/A:N), reflecting that the flaw merely lets an attacker store an attachment whose extension would normally be blocked by the instance's AllowedTypes allow-list - it is not RCE or data theft. EPSS is low at 0.33% (24th percentile), the CVE is NOT on CISA KEV, and no public exploit is identified in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' These signals are consistent with each other: low EPSS, no KEV, no POC, and a modest CVSS all point to a non-urgent, low-real-risk defect. CONFLICT TO VERIFY: the input vector lists PR:N (unauthenticated), but the fixed code (EditIssueAttachment/EditReleaseAttachment, authenticated API endpoints) and the nature of editing an existing attachment imply an authenticated API call is required - the PR:N rating is likely overstated; verify authentication requirement with the vendor. The CWE (CWE-424, Improper Protection of Alternate Path) and the 'Information Disclosure' tag also disagree with the actual integrity/restriction-bypass nature of the bug.

An authenticated user with permission to manage attachments uploads a benign, allowed file via the Gitea attachment API, then calls the edit-attachment endpoint to rename it to a normally-forbidden extension (e.g. an executable or script type) because pre-1.23.0 Gitea validated the extension only on upload, not on update. The attachment is then served from the instance with the forbidden extension, undermining the configured AllowedTypes policy. No public POC is referenced in the provided data.