Summary
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.
Affected
- Component: web issue/comment attachment handling.
- Confirmed version:
maincommita39b2775edcb3ba53def96794491b91335117d81(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-207returns the repository ID fromIssueIDorReleaseID.routers/web/repo/attachment.go:153-184checks read permission on that linked repository.routers/web/repo/attachment.go:216-224opens 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.
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 received404. - 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 received200; 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 = 2andIssueID = 4was passed toUpdateIssueAttachmentsfor attacker issueID = 1, whoseRepoID = 1. - The call succeeded.
- The attachment row still had
RepoID = 2, but itsIssueIDwas changed to the attacker issue. GetAttachmentLinkedTypeAndRepoIDthen resolved the attachment to attacker repositoryRepoID = 1.
Model-level comment-path behavior:
- The same cross-repository attachment UUID was passed to
UpdateCommentAttachmentsfor attacker commentID = 1. - The call succeeded.
- The attachment row still had
RepoID = 2, but itsIssueIDandCommentIDwere changed to the attacker's issue/comment. - The linked repository used for access checks became attacker repository
RepoID = 1.
Negative control:
- Existing release test
TestAddReleaseAttachmentsRejectsDifferentRepopasses 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.
Regression Tests
Add tests that fail before the fix and pass after it:
UpdateIssueAttachmentsrejects an attachment whoseRepoIDdiffers from the target issue'sRepoID.UpdateCommentAttachmentsrejects an attachment whoseRepoIDdiffers from the target comment issue'sRepoID.- 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.
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.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-57886 has a CVSS score of 5.9 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.27.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Add repository and linkage validation before updating issue/comment attachments.
Recommended checks:
- Load the target issue for
UpdateIssueAttachmentsand derive itsRepoID. - Load the target comment's issue for
UpdateCommentAttachmentsand derive itsRepoID. - Reject any attachment whose
RepoIDdiffers 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 = 0migration 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.
Frequently Asked Questions
- What is CVE-2026-57886? CVE-2026-57886 is a medium-severity missing authorization vulnerability in code.gitea.io/gitea (go), affecting versions < 1.27.0. It is fixed in 1.27.0. The application does not perform an authorization check before performing a sensitive operation.
- How severe is CVE-2026-57886? CVE-2026-57886 has a CVSS score of 5.9 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of code.gitea.io/gitea are affected by CVE-2026-57886? code.gitea.io/gitea (go) versions < 1.27.0 is affected.
- Is there a fix for CVE-2026-57886? Yes. CVE-2026-57886 is fixed in 1.27.0. Upgrade to this version or later.
- Is CVE-2026-57886 exploitable, and should I be worried? Whether CVE-2026-57886 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-57886 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-57886? Upgrade
code.gitea.io/giteato 1.27.0 or later.