CVE-2026-24451 is a high-severity (CVSS 7.5) Information Exposure vulnerability in code.gitea.io/gitea. A fix is available for code.gitea.io/gitea — see the affected versions and patch details below.
Gitea fork synchronization can expose private parent repository data
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-24451.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-24451 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
code.gitea.io/giteaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The POST /api/v1/repos/{owner}/{repo}/merge-upstream endpoint continues to synchronize commits from a parent repository after the parent repository has been changed from public to private.
A fork created while the parent repository was public can still receive commits made after the parent repository becomes private. As a result, content added during the private period becomes available through the fork repository after synchronization.
Details
Gitea provides the merge-upstream API to synchronize a fork with its parent repository.
A typical workflow is:
- A repository is public.
- Another user creates a fork.
- The fork owner uses
merge-upstreamto receive updates from the parent repository.
However, if the parent repository is later changed from public to private, the synchronization endpoint continues to import new commits from the parent repository into the fork.
In testing on Gitea 1.26.2, a fork owner who can no longer directly access the parent repository is still able to synchronize newly created commits from the parent repository into the fork by calling merge-upstream.
As a result, commits created after the visibility change can be propagated into the fork through the normal fork synchronization workflow.
PoC
Proof-of-Concept Code
https://anonymous.4open.science/r/Gitea_PoC-EC93/4_poc_merge_upstream
PoC Details
- User
alicecreates a public repositoryalice/P. - User
bobforks the repository, creatingbob/P. alicechangesalice/Pfrom public to private.- Verify that
bobcan no longer directly access the parent repository:
GET /api/v1/repos/alice/P
Response:
404 Not Found
GET /api/v1/repos/alice/P/contents/README.md
Response:
404 Not Found
- While the repository is private,
alicecommits a new file:
secret.txt
- Verify that
bobcannot directly access the new file from the parent repository:
GET /api/v1/repos/alice/P/contents/secret.txt
Response:
404 Not Found
bobsynchronizes the fork:
POST /api/v1/repos/bob/P/merge-upstream
Response:
200 OK
- The newly added file is now available through the fork repository:
GET /api/v1/repos/bob/P/contents/secret.txt
Response:
200 OK
The attached PoC reproduces the behavior end-to-end.
As a control test, attempting to access the private-period commit directly through the fork's Git API before synchronization fails:
GET /api/v1/repos/bob/P/git/commits/<private-period-commit-sha>
Response:
404 Not Found
This indicates that the commit becomes available in the fork only after the merge-upstream operation synchronizes it from the parent repository.
Impact
A fork created while a repository is public can continue receiving updates from the parent repository after the parent repository is changed to private.
Consequently, content committed after the visibility change may become available through fork synchronization even when the fork owner can no longer directly access the parent repository.
The impact is limited to content that is synchronized from the parent repository into the affected fork. The issue does not allow modification of the parent repository or access to repositories that were never forked.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.gitea.io/gitea | all versions | 1.26.3go get code.gitea.io/gitea@v1.26.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update code.gitea.io/gitea to 1.26.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-24451 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-24451 in your dependencies?
Find it across Go, including transitive dependencies.