Gitea CVE-2026-20800 sibling endpoints not covered: revoked user still reads private repo objects via /api/v1/user/starred and private issue titles via /api/v1/user/times
Summary
CVE-2026-20800 fixed private-info leakage to revoked users only for the notification endpoint. Two sibling endpoints that return data keyed on the caller's own relationship still do not re-check repo access at output time:GET /api/v1/user/starred—getStarredRepos()computes a per-repo permission but still lists every
full_name, private, clone_url, ssh_url)
of a now-inaccessible private repo is returned.
GET /api/v1/user/times—ListMyTrackedTimes()queries byUserIDonly andLoadAttributesbrings
title, state), leaking private issue titles after revocation.Steps to reproduce
Using the provided reproduction materials, as a revoked user:- Control:
GET /api/v1/repos/admin/starred-test→ 404. GET /api/v1/user/starred→ leaksadmin/starred-test,private:true,clone_url.GET /api/v1/user/times→ leaksissue.title = "SECRET: …",state.
(Runtime-confirmed on gitea/gitea:1.25.4. Oracle = planted sentinel title; no real secret exfiltrated.)
Impact
A former collaborator can enumerate private repos they starred and read private issue titles they logged time on, indefinitely after access revocation. Metadata only (no repo content / comment bodies). Low.Suggested remediation
getStarredRepos: drop (or minimally redact) repos wherepermission.HasAnyUnitAccessOrPublicAccess()
ListMyTrackedTimes: filter tracked-time entries by current repo access.- Optionally clear a user's stars / time entries for a private repo on revocation.