fkie_cve-2026-24791

Public-only tokens bypass private-resource restrictions on `/api/v1/user` self routes

GHSA-wrr5-99h5-gq57 — Gitea: Public-only tokens bypass private-resource restrictions on `/api/v1/user` self routes

Affected: Go: code.gitea.io/gitea

## Summary

Many authenticated self routes under `/api/v1/user/...` do not enforce the `public-only` token restriction. As a result, a token or OAuth grant marked `public-only`, but otherwise carrying the route-required read/write scope category, can access or modify private account resources through self routes.

The canonical private-user endpoint correctly rejects the same tokens, for example `GET /api/v1/users/{privateUser}` returns `403`. The bypass exists because the generic `/api/v1/user` route group requires user scope and `reqToken()`, but does not enforce the token's public-only restriction for most self routes.

This is a systemic token/OAuth scope-boundary bypass, not a single endpoint bug.

This appears related to the previously fixed public-only token issue tracked as [CVE-2025-68941 / GHSA-xfq3-qj7j-4565](https://github.com/advisories/GHSA-xfq3-qj7j-4565), which affected Gitea `< 1.22.3`. The behavior described here reproduces on tested main checkout `6a2706626904`. A representative SSH-key self-route PoC also reproduces on tested releases through v1.26.1. In other words, this should be treated as an incomplete fix / residual gap in a different route family, not as a duplicate of the older advisory.

## Affected Code

The generic `/api/v1/user` group is mounted with user scope and `reqToken()`:

- `routers/api/v1/api.go:1008-1128`

`tokenRequiresScopes()` sets `ctx.PublicOnly` when the token contains `public-only`, but the public-only restriction is enforced o…

Most recent entries from all

bdu:2026-10561

fkie_cve-2026-24791

GHSA-wrr5-99h5-gq57 — Gitea: Public-only tokens bypass private-resource restrictions on `/api/v1/user` self routes