Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content

Impact

An attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository's authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.

This can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.

Reproduction Summary

Full HTTP/E2E observation:

• A local Gitea server was started with an isolated SQLite database.
• A victim user created private repositories, private issues, and issue attachments containing unique marker strings.
• An attacker user first attempted to download each victim attachment through /attachments/{uuid} and received 404.
• The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.
• The same attacker could then download the victim issue attachment through /attachments/{uuid} and received 200; the response body contained the unique issue marker.
• The attacker repeated the flow through the real comment edit route and could download the second victim attachment with 200; the response body contained the unique comment marker.

Model-level issue-path behavior:

• A fixture attachment with RepoID = 2 and IssueID = 4 was passed to UpdateIssueAttachments for attacker issue ID = 1, whose RepoID = 1.
• The call succeeded.
• The attachment row still had RepoID = 2, but its IssueID was changed to the attacker issue.
• GetAttachmentLinkedTypeAndRepoID then resolved the attachment to attacker repository RepoID = 1.

Model-level comment-path behavior:

• The same cross-repository attachment UUID was passed to UpdateCommentAttachments for attacker comment ID = 1.
• The call succeeded.
• The attachment row still had RepoID = 2, but its IssueID and CommentID were changed to the attacker's issue/comment.
• The linked repository used for access checks became attacker repository RepoID = 1.

Negative control:

• Existing release test TestAddReleaseAttachmentsRejectsDifferentRepo passes and confirms the release path rejects the same class of cross-repository attachment linkage.

Detailed verifier and step-by-step runbook are available on request.

Suggested Fix

Add repository and linkage validation before updating issue/comment attachments.

Recommended checks:

• Load the target issue for UpdateIssueAttachments and derive its RepoID.
• Load the target comment's issue for UpdateCommentAttachments and derive its RepoID.
• Reject any attachment whose RepoID differs from the target issue repository.
• Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.
• If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.
• Preserve any legacy RepoID = 0 migration behavior only when it can be proven safe for the target repository.

Also consider a cleanup/audit query for existing inconsistent rows where attachment.issue_id != 0 and attachment.repo_id differs from the linked issue repository.

Regression Tests

Add tests that fail before the fix and pass after it:

• UpdateIssueAttachments rejects an attachment whose RepoID differs from the target issue's RepoID.
• UpdateCommentAttachments rejects an attachment whose RepoID differs from the target comment issue's RepoID.
• Same-repository unlinked attachment linking still works for normal issue/comment editing.
• Attachments already linked to a different issue/comment cannot be moved by passing their UUID in files[].
• Existing release guard test remains passing.