What is the CVSS score of CVE-2026-59766?

CVE-2026-59766 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N.

Is there a patch available for CVE-2026-59766?

Yes, a patch is available for CVE-2026-59766. Update the affected software to the latest version immediately.

Gitea CVE-2026-59766

MEDIUM

Incorrect Authorization (CWE-863)

2026-07-21 https://github.com/go-gitea/gitea

GHSA-qf2f-qh6p-7v89

Authentication Bypass Oracle Gitea Suse

4.3

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

4.3 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

vuln.today AI

4.3 MEDIUM

PR:L because a previously-issued valid API token is required; C:L because only metadata (repo names, URLs, issue titles) is exposed, not repository content.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jul 21, 2026 - 20:36 vuln.today

Analysis Generated

Jul 21, 2026 - 20:36 vuln.today

DescriptionGitHub Advisory

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:

Control: GET /api/v1/repos/admin/starred-test → 404.
GET /api/v1/user/starred → leaks admin/starred-test, private:true, clone_url.
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

getStarredRepos: drop (or minimally redact) repos where permission.HasAnyUnitAccessOrPublicAccess()

is false for the caller.

ListMyTrackedTimes: filter tracked-time entries by current repo access.
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).

AnalysisAI

Private repository metadata and issue titles leak to revoked Gitea users via two REST API endpoints that omit post-revocation authorization checks, constituting an incomplete fix relative to CVE-2026-20800. Former collaborators with a still-valid API token can call GET /api/v1/user/starred to receive full repository objects - including clone_url and ssh_url - for private repos they starred, and GET /api/v1/user/times to retrieve private issue titles and states for issues on which they logged time, indefinitely after repo access is revoked. Impact is metadata-only; no public exploit code has been identified at time of analysis and no CISA KEV listing exists.

Technical ContextAI

Gitea is a self-hosted Git service written in Go (package code.gitea.io/gitea). The root cause is CWE-863 (Incorrect Authorization): both affected handlers fetch records keyed on the caller's user identity - starred repos and time-tracking entries - without subsequently re-validating that the caller retains current permission on the associated repository. getStarredRepos() does compute a per-repo permission object, but the filtering step is absent, so all starred repos are returned regardless of current access. ListMyTrackedTimes() queries by UserID only and calls LoadAttributes, which hydrates full issue metadata including title and state. CVE-2026-20800 patched the notification endpoint for the same class of bug but left these two sibling endpoints unaddressed. The fix is introduced in Gitea 1.27.0, which adds access filtering at output time for both handlers.

RemediationAI

Upgrade to Gitea 1.27.0 or later, the vendor-released patch that introduces access filtering at output time for both getStarredRepos() and ListMyTrackedTimes(). The release is available at https://github.com/go-gitea/gitea/releases/tag/v1.27.0 and the advisory at https://github.com/go-gitea/gitea/security/advisories/GHSA-qf2f-qh6p-7v89. If immediate upgrade is not feasible, invalidate or rotate API tokens for all revoked collaborators at the time of access removal - this eliminates the attack vector entirely since the leakage requires a valid token, though it is an operational burden and must be applied to every revocation event going forward. As a secondary measure, administrators can manually clear a revoked user's stars and time entries for private repositories, though this is labor-intensive and does not scale. Neither workaround addresses the underlying code defect; patching to 1.27.0 is the only durable fix.