https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 14 Oct 2026 10:29:59 +0000 https://db.gcve.eu/vuln/cve-2026-58435 <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>Gitea LFS Deploy-Key Privilege Escalation</p> <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>Gitea LFS Deploy-Key Privilege Escalation</p> https://db.gcve.eu/vuln/cve-2026-58435 https://db.gcve.eu/vuln/ghsa-rh79-75qm-gwjr <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Vulnerability Header</p> <p>| Field | Value | | ------------------- | ----------------------------------------------------------- | | Vulnerability Title | Gitea LFS Deploy-Key Privilege Escalation | | Severity Rating | High | | Bug Category | Insufficient Authorization | | Location | `services/lfs/server.go:268`, `routers/private/serv.go:275` | | Affected Versions | 1.25.5 |</p> <p>## Executive Summary</p> <p>Gitea&#39;s LFS server (`services/lfs/server.go:268`) uses the `UserID` embedded in an LFS JWT to make cross-repository authorization decisions via `LFSObjectAccessible()`. This would be safe if the JWT `UserID` always matched the actual requesting principal — but for deploy keys, `routers/private/serv.go:275` sets `UserID = repo.OwnerID` instead of any identity representing the deploy key itself. As a result, an attacker who holds a write deploy key for any single repo owned by a victim can obtain a legitimate JWT (via the standard SSH `git-lfs-authenticate` flow) that Gitea will honor as if the victim themselves were making the request. The attacker can then exfiltrate LFS objects from any private repo the victim owns — no admin credentials, no server secrets, no brute force required. If the victim is a site administrator, every LFS object…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Vulnerability Header</p> <p>| Field | Value | | ------------------- | ----------------------------------------------------------- | | Vulnerability Title | Gitea LFS Deploy-Key Privilege Escalation | | Severity Rating | High | | Bug Category | Insufficient Authorization | | Location | `services/lfs/server.go:268`, `routers/private/serv.go:275` | | Affected Versions | 1.25.5 |</p> <p>## Executive Summary</p> <p>Gitea&#39;s LFS server (`services/lfs/server.go:268`) uses the `UserID` embedded in an LFS JWT to make cross-repository authorization decisions via `LFSObjectAccessible()`. This would be safe if the JWT `UserID` always matched the actual requesting principal — but for deploy keys, `routers/private/serv.go:275` sets `UserID = repo.OwnerID` instead of any identity representing the deploy key itself. As a result, an attacker who holds a write deploy key for any single repo owned by a victim can obtain a legitimate JWT (via the standard SSH `git-lfs-authenticate` flow) that Gitea will honor as if the victim themselves were making the request. The attacker can then exfiltrate LFS objects from any private repo the victim owns — no admin credentials, no server secrets, no brute force required. If the victim is a site administrator, every LFS object…</p> https://db.gcve.eu/vuln/ghsa-rh79-75qm-gwjr