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 4. "getStarredRepos": drop (or minimally redact) repos where "permission.HasAnyUnitAccessOrPublicAccess()" is false for the caller. 5. "ListMyTrackedTimes": filter tracked-time entries by current repo access. 6. 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).