fkie_cve-2026-50105

RSS/Atom feed handlers bypass API-token scope & public-only confinement (incomplete fix of #37698)

GHSA-6cqf-375w-639g — Gitea: RSS/Atom feed handlers bypass API-token scope & public-only confinement (incomplete fix of #37698)

Affected: Go: code.gitea.io/gitea

### Summary

Gitea'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'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.

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.

### Details

#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.

The feed handlers are registered with `webAuth.AllowBasic` (so they accept token Basic auth) but call no scope / public-only check.…

Most recent entries from all

fkie_cve-2026-50105

GHSA-6cqf-375w-639g — Gitea: RSS/Atom feed handlers bypass API-token scope & public-only confinement (incomplete fix of #37698)