https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 26 Oct 2026 23:08:20 +0000 https://db.gcve.eu/vuln/cve-2026-57886 <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>Cross-repository issue/comment attachment re-linking can expose private attachment content</p> <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>Cross-repository issue/comment attachment re-linking can expose private attachment content</p> https://db.gcve.eu/vuln/cve-2026-57886 https://db.gcve.eu/vuln/ghsa-6c6r-5xr4-cr5m <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Summary</p> <p>Gitea&#39;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&#39;s repository authorization context.</p> <p>## Affected</p> <p>- 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.</p> <p>## Description / Root Cause</p> <p>`files[]` values from issue/comment edit flows are passed to `updateAttachments` in `routers/web/repo/issue.go:589-629`. That helper calls:</p> <p>- `models/issues/issue_update.go:267-278` (`UpdateIssueAttachments`) - `models/issues/comment.go:623-642` (`UpdateCommentAttachments`)</p> <p>Both functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row&#39;s `RepoID` matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.</p> <p>Attachment reads then use the linked issue/release repository to decide access:</p> <p>- `services/repository/repository.go:185-2…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Summary</p> <p>Gitea&#39;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&#39;s repository authorization context.</p> <p>## Affected</p> <p>- 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.</p> <p>## Description / Root Cause</p> <p>`files[]` values from issue/comment edit flows are passed to `updateAttachments` in `routers/web/repo/issue.go:589-629`. That helper calls:</p> <p>- `models/issues/issue_update.go:267-278` (`UpdateIssueAttachments`) - `models/issues/comment.go:623-642` (`UpdateCommentAttachments`)</p> <p>Both functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row&#39;s `RepoID` matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.</p> <p>Attachment reads then use the linked issue/release repository to decide access:</p> <p>- `services/repository/repository.go:185-2…</p> https://db.gcve.eu/vuln/ghsa-6c6r-5xr4-cr5m