CVE-2026-57886

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

Published

2026-07-21

Modified

2026-07-21

Aliases

GHSA-6c6r-5xr4-cr5m

Sources

github-advisory

Summary

## Summary 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. ## Affected - Component: web issue/comment attachment handling. - Confirmed version: `main` commit `a39b2775edcb3ba53def96794491b91335117d81` (`v1.27.0-dev-352-ga39b2775ed`). - Fixed in: not fixed at the time of validation. - Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic. ## Description / Root Cause `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. ## 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 `Re

Affected packages

Remediation: Upgrade to 1.27.0 or later.

References

• https://github.com/advisories/GHSA-6c6r-5xr4-cr5m