https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 09:20:08 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-352921 EUVD-2026-352921 https://cve.radiocsirt.org/vuln/euvd-2026-352921 https://cve.radiocsirt.org/vuln/fkie_cve-2026-56443 <p>Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118</p> <p>Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-56443 https://cve.radiocsirt.org/vuln/ghsa-7p4h-3gxq-x3h3 <p><strong>Affected:</strong> Go: code.gitea.io/gitea, Go: gitea.dev</p> <p>## Summary</p> <p>After [PR #37118](https://github.com/go-gitea/gitea/pull/37118) / **CVE-2026-25714** (`fix: Unify public-only token filtering in API queries and repo access checks`, merged 2026-05-18, backport `#37773` to 1.26.2 — the May 2026 unification pass for public-only token filtering, reporter Medoedus per the 1.26.2 release notes), the `public-only` PAT scope is still bypassable on **Repository** and **Package** scope categories when the owner&#39;s `Visibility = Limited` (instance-internal).</p> <p>The sibling `Org` / `User` / `ActivityPub` cases in the same `checkTokenPublicOnly` switch correctly reject Limited owners via `!Visibility.IsPublic()`. The Repository / Package cases use `repo.IsPrivate` or `Owner.Visibility.IsPrivate()`, both of which return `false` for `VisibleTypeLimited` — so a `public-only` PAT strictly exceeds anonymous reach on a Limited owner.</p> <p>Tested on `gitea/gitea:1.26.2`. The decisive marker is that PR #37118&#39;s unification IS applied in the version under test (User-category PROBE returns `403 &#34;token scope is limited to public users&#34;`). Despite that, the Repository-category PROBE on the same Limited owner with the same PAT returns `200` and serves content.</p> <p>## Affected entry points (4 spots)</p> <p>| File:Line | Function | Affected surface | |---|---|---| | `routers/api/v1/api.go:292` | `checkTokenPublicOnly` Package case | API v1 packages | | `routers/api/packages/api.go:76` | `reqPackageAccess` middleware | All 24 native package registries (`/api/packages/&lt;typ…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea, Go: gitea.dev</p> <p>## Summary</p> <p>After [PR #37118](https://github.com/go-gitea/gitea/pull/37118) / **CVE-2026-25714** (`fix: Unify public-only token filtering in API queries and repo access checks`, merged 2026-05-18, backport `#37773` to 1.26.2 — the May 2026 unification pass for public-only token filtering, reporter Medoedus per the 1.26.2 release notes), the `public-only` PAT scope is still bypassable on **Repository** and **Package** scope categories when the owner&#39;s `Visibility = Limited` (instance-internal).</p> <p>The sibling `Org` / `User` / `ActivityPub` cases in the same `checkTokenPublicOnly` switch correctly reject Limited owners via `!Visibility.IsPublic()`. The Repository / Package cases use `repo.IsPrivate` or `Owner.Visibility.IsPrivate()`, both of which return `false` for `VisibleTypeLimited` — so a `public-only` PAT strictly exceeds anonymous reach on a Limited owner.</p> <p>Tested on `gitea/gitea:1.26.2`. The decisive marker is that PR #37118&#39;s unification IS applied in the version under test (User-category PROBE returns `403 &#34;token scope is limited to public users&#34;`). Despite that, the Repository-category PROBE on the same Limited owner with the same PAT returns `200` and serves content.</p> <p>## Affected entry points (4 spots)</p> <p>| File:Line | Function | Affected surface | |---|---|---| | `routers/api/v1/api.go:292` | `checkTokenPublicOnly` Package case | API v1 packages | | `routers/api/packages/api.go:76` | `reqPackageAccess` middleware | All 24 native package registries (`/api/packages/&lt;typ…</p> https://cve.radiocsirt.org/vuln/ghsa-7p4h-3gxq-x3h3 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