Go · code.gitea.io/gitea
Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content
Gitea's issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker's repository authorization context.
main commit a39b2775edcb3ba53def96794491b91335117d81 (v1.27.0-dev-352-ga39b2775ed).files[] values from issue/comment edit flows are passed to updateAttachments in routers/web/repo/issue.go:589-629. That helper calls:
models/issues/issue_update.go:267-278 (UpdateIssueAttachments)models/issues/comment.go:623-642 (UpdateCommentAttachments)Both functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row's RepoID matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.
Attachment reads then use the linked issue/release repository to decide access:
services/repository/repository.go:185-207 returns the repository ID from IssueID or ReleaseID.routers/web/repo/attachment.go:153-184 checks read permission on that linked repository.routers/web/repo/attachment.go:216-224 opens and serves the file from the attachment's storage path after the linked-repository permission check succeeds.For the global /attachments/{uuid} route in routers/web/web.go:872-876, there is no current repository context, so the early attach.RepoID mismatch check in ServeAttachment does not protect against this re-linking case.
A patched sibling path already demonstrates the intended invariant: models/repo/release.go:179-215 rejects release attachments whose RepoID differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.
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.
Full HTTP/E2E observation:
/attachments/{uuid} and received 404./attachments/{uuid} and received 200; the response body contained the unique issue marker.200; the response body contained the unique comment marker.Model-level issue-path behavior:
RepoID = 2 and IssueID = 4 was passed to UpdateIssueAttachments for attacker issue ID = 1, whose RepoID = 1.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:
UpdateCommentAttachments for attacker comment ID = 1.RepoID = 2, but its IssueID and CommentID were changed to the attacker's issue/comment.RepoID = 1.Negative control:
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.
Add repository and linkage validation before updating issue/comment attachments.
Recommended checks:
UpdateIssueAttachments and derive its RepoID.UpdateCommentAttachments and derive its RepoID.RepoID differs from the target issue repository.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.
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.files[].Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.