https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 11:35:03 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-333737 EUVD-2026-333737 https://cve.radiocsirt.org/vuln/euvd-2026-333737 https://cve.radiocsirt.org/vuln/fkie_cve-2026-28740 <p>Gitea versions up to and including 1.26.2 allow Git LFS object reuse to authorize private source objects for users who have repository access but lack Code-unit access.</p> <p>Gitea versions up to and including 1.26.2 allow Git LFS object reuse to authorize private source objects for users who have repository access but lack Code-unit access.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-28740 https://cve.radiocsirt.org/vuln/ghsa-2m9v-5q2g-58vq <p><strong>Affected:</strong> Go: gitea.dev</p> <p>## Summary</p> <p>A user with Code write access to one repository may be able to associate an existing Git LFS object from a private source repository with their target repository, even when they do not have Code access to the source repository that currently owns the LFS object.</p> <p>The issue appears to be caused by the source-object authorization check using broad repository accessibility instead of requiring Code-unit access to at least one repository that owns the requested LFS object.</p> <p>## Impact</p> <p>This issue breaks the expected authorization boundary between repository units.</p> <p>A user who does not have Code access to a private source repository should not be able to reuse or associate Git LFS objects owned by that repository. However, because the source-object accessibility check accepts broad repository access, non-Code access such as Issues access may be sufficient for the LFS object to be treated as accessible.</p> <p>If the reused object becomes downloadable through the attacker-controlled target repository after metadata association, this can result in cross-repository Git LFS content disclosure.</p> <p>The target repository write authorization is still enforced. The problem is specifically in the authorization decision for whether the source LFS object is accessible and may be reused.</p> <p>## Preconditions</p> <p>The attacker needs:</p> <p>* an authenticated Gitea account; * Code write access to a target repository; * non-Code access, such as Issues access, to a private source repository; * knowledge o…</p> <p><strong>Affected:</strong> Go: gitea.dev</p> <p>## Summary</p> <p>A user with Code write access to one repository may be able to associate an existing Git LFS object from a private source repository with their target repository, even when they do not have Code access to the source repository that currently owns the LFS object.</p> <p>The issue appears to be caused by the source-object authorization check using broad repository accessibility instead of requiring Code-unit access to at least one repository that owns the requested LFS object.</p> <p>## Impact</p> <p>This issue breaks the expected authorization boundary between repository units.</p> <p>A user who does not have Code access to a private source repository should not be able to reuse or associate Git LFS objects owned by that repository. However, because the source-object accessibility check accepts broad repository access, non-Code access such as Issues access may be sufficient for the LFS object to be treated as accessible.</p> <p>If the reused object becomes downloadable through the attacker-controlled target repository after metadata association, this can result in cross-repository Git LFS content disclosure.</p> <p>The target repository write authorization is still enforced. The problem is specifically in the authorization decision for whether the source LFS object is accessible and may be reused.</p> <p>## Preconditions</p> <p>The attacker needs:</p> <p>* an authenticated Gitea account; * Code write access to a target repository; * non-Code access, such as Issues access, to a private source repository; * knowledge o…</p> https://cve.radiocsirt.org/vuln/ghsa-2m9v-5q2g-58vq https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2027 <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um erweiterte Berechtigungen zu erlangen, sich als Benutzer auszugeben, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren und vertrauliche Informationen offenzulegen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um erweiterte Berechtigungen zu erlangen, sich als Benutzer auszugeben, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren und vertrauliche Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2027