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