https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 20:37:50 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-352923 EUVD-2026-352923 https://cve.radiocsirt.org/vuln/euvd-2026-352923 https://cve.radiocsirt.org/vuln/fkie_cve-2026-50105 <p>RSS/Atom feed handlers bypass API-token scope &amp; public-only confinement (incomplete fix of #37698)</p> <p>RSS/Atom feed handlers bypass API-token scope &amp; public-only confinement (incomplete fix of #37698)</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-50105 https://cve.radiocsirt.org/vuln/ghsa-6cqf-375w-639g <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>### Summary</p> <p>Gitea&#39;s RSS/Atom feed handlers accept API-token Basic auth but perform **no token-scope or public-only enforcement**. A personal access token that is correctly blocked (HTTP 403) from a private repository on `/raw`, `/media`, `/archive`, and `/releases/download/...` — because it is marked *public-only* or lacks the `repository` scope category — still returns that repository&#39;s private content through the feed routes. This is a token-confinement bypass and appears to be an incomplete fix of #37698, which added that scope enforcement to the download handlers but not to the sibling feed handlers.</p> <p>This is **not** a cross-user access bug: the requesting account must still legitimately have repo read access (`RepoAssignment` + `reqUnitCodeReader` are enforced). What is bypassed is the guarantee that a *confined* token cannot reach private content — which is exactly the property #37698 was shipped to provide for downloads, and which matters when such a token is handed to a third-party service/CI, leaked, or used in a lower-trust integration.</p> <p>### Details</p> <p>#37698 added `context.CheckTokenScopes` / `CheckRepoScopedToken` (`services/context/permission.go`) to the raw / media / archive / attachment download handlers, so a public-only or wrong-scope-category token cannot read private-repo content even when the owning user otherwise has access.</p> <p>The feed handlers are registered with `webAuth.AllowBasic` (so they accept token Basic auth) but call no scope / public-only check.…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>### Summary</p> <p>Gitea&#39;s RSS/Atom feed handlers accept API-token Basic auth but perform **no token-scope or public-only enforcement**. A personal access token that is correctly blocked (HTTP 403) from a private repository on `/raw`, `/media`, `/archive`, and `/releases/download/...` — because it is marked *public-only* or lacks the `repository` scope category — still returns that repository&#39;s private content through the feed routes. This is a token-confinement bypass and appears to be an incomplete fix of #37698, which added that scope enforcement to the download handlers but not to the sibling feed handlers.</p> <p>This is **not** a cross-user access bug: the requesting account must still legitimately have repo read access (`RepoAssignment` + `reqUnitCodeReader` are enforced). What is bypassed is the guarantee that a *confined* token cannot reach private content — which is exactly the property #37698 was shipped to provide for downloads, and which matters when such a token is handed to a third-party service/CI, leaked, or used in a lower-trust integration.</p> <p>### Details</p> <p>#37698 added `context.CheckTokenScopes` / `CheckRepoScopedToken` (`services/context/permission.go`) to the raw / media / archive / attachment download handlers, so a public-only or wrong-scope-category token cannot read private-repo content even when the owning user otherwise has access.</p> <p>The feed handlers are registered with `webAuth.AllowBasic` (so they accept token Basic auth) but call no scope / public-only check.…</p> https://cve.radiocsirt.org/vuln/ghsa-6cqf-375w-639g https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2304 <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, sensible Informationen offenzulegen, Sitzungen zu übernehmen oder wiederzuverwenden oder einen Denial-of-Service-Zustand auszulösen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, sensible Informationen offenzulegen, Sitzungen zu übernehmen oder wiederzuverwenden oder einen Denial-of-Service-Zustand auszulösen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2304