CVE-2026-20736: 
Gitea vulnerability analysis and mitigation

CVE-2026-20736 is an improper access control vulnerability in Gitea that allows a user who previously uploaded an attachment to a repository to delete it after losing access, by routing the deletion request through a different repository they still have access to. It affects all Gitea versions prior to 1.25.4. The vulnerability was published on January 22, 2026, with a patch released on January 23, 2026. It carries a CVSS v3.1 base score of 7.5 (High) per Feedly's assessment, though the GitHub Advisory Database assigns a CVSS v4 score of 2.3 (Low) (GitHub Advisory, Gitea Release).

The root cause is CWE-284 (Improper Access Control): Gitea's attachment deletion handler in routers/web/repo/attachment.go fails to verify that the attachment being deleted belongs to the repository context of the incoming request. This means the server checks only whether the user has access to some repository, not whether the attachment is associated with the specific repository through which the deletion request is made. An attacker with a valid account and access to at least one repository can craft a deletion request referencing an attachment UUID from a repository they no longer have access to, and the server will process it without validating repository ownership of the attachment. The fix, contributed by maintainer lunny in PR #36320, adds a repository ownership check before processing attachment deletions (GitHub PR, GitHub Advisory).

Successful exploitation allows a revoked user to permanently delete attachments from repositories they no longer have access to, causing irreversible data loss and disrupting collaborative workflows. The impact is limited to integrity (deletion of files) with no confidentiality exposure, as the attacker cannot read or exfiltrate attachment content — only destroy it. In environments where attachments contain critical project artifacts, release binaries, or documentation, unauthorized deletion could significantly disrupt operations (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the time of publication. The EPSS score is approximately 0.016–0.017%, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to have a valid Gitea account with access to at least one repository, limiting the attack surface to authenticated users (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a Gitea instance running a version prior to 1.25.4. Confirm that the attacker previously had access to a target repository and uploaded at least one attachment (e.g., to an issue or release), and that they retain access to at least one other repository on the same instance.
2. Obtain attachment UUID: Retrieve the UUID or identifier of the attachment from the target repository. This may have been noted during prior access, or could potentially be inferred from cached links or shared content.
3. Craft deletion request: While authenticated, send an HTTP DELETE or POST request to the attachment deletion endpoint (e.g., /[accessible-repo-owner]/[accessible-repo]/attachments/[attachment-uuid]), substituting the accessible repository's path but referencing the attachment UUID from the inaccessible repository.
4. Achieve unauthorized deletion: Because Gitea does not validate that the attachment belongs to the repository in the request context, the server processes the deletion, permanently removing the attachment from the target repository (GitHub PR, GitHub Advisory).

• Logs: Gitea access logs showing DELETE or POST requests to attachment endpoints where the repository path in the URL does not match the repository associated with the referenced attachment UUID; requests from users who are no longer members of the target repository.
• Application Events: Attachment deletion events in Gitea's audit log attributed to users without current membership in the affected repository.
• File System: Missing attachment files in the Gitea data directory (gitea/attachments/) that correspond to attachments no longer accessible via the web UI, with deletion timestamps correlating to suspicious user activity.

Upgrade Gitea to version 1.25.4 or later, which includes the fix for this vulnerability (PR #36320, commit fbea2c6). No configuration-based workaround is available; the only remediation is applying the patch. Administrators should also audit attachment deletion logs for suspicious activity by former repository members and review repository access controls to ensure timely revocation (Gitea Release, Gitea Blog).

The Gitea project addressed the vulnerability as part of a broader security-focused release (v1.25.4), which included eight security fixes. Community reaction on GitHub was positive, with 40 users reacting to the release. The vulnerability was noted on social platforms including Bluesky and Mastodon/infosec.exchange shortly after disclosure. Coverage was primarily limited to vulnerability tracking databases and the Gitea community, with no major independent security research publications identified (Gitea Release, Gitea Blog).