CVE-2026-59766

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 starred repo (no filtering), so the full repo object (full_name, private, clone_url, ssh_url) of a now-inaccessible private repo is returned. - GET /api/v1/user/times — ListMyTrackedTimes() queries by UserID only and LoadAttributes brings in the issue (title, state), leaking private issue titles after revocation. Steps to reproduce Using the provided reproduction materials, as a revoked user: 1. Control: GET /api/v1/repos/admin/starred-test → 404. 2. GET /api/v1/user/starred → leaks admin/starred-test, private:true, clone_url. 3. GET /api/v1/user/times → leaks issue.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 1. getStarredRepos: drop (or minimally redact) repos where permission.HasAnyUnitAccessOrPublicAccess() is false for the caller. 2. ListMyTrackedTimes: filter tracked-time entries by current repo access. 3. Optionally clear a user's stars / time entries for a private repo on revocation. Credit Reported as part of an incomplete-patch measurement study (responsible disclosure).

[![CVE-2026-59766 status](https://www.csirts.com/badge/CVE-2026-59766)](https://www.csirts.com/cve/CVE-2026-59766)