GHSA-wrf9-r3h7-7x5v is a high-severity (CVSS 7.5) Information Exposure vulnerability in code.gitea.io/gitea. O3 Security confirms whether GHSA-wrf9-r3h7-7x5v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gitea: Fork Synchronization Continues After Parent Repository Changes from Public to Private
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-wrf9-r3h7-7x5v is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wrf9-r3h7-7x5v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wrf9-r3h7-7x5v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wrf9-r3h7-7x5v in your dependencies?
O3 detects GHSA-wrf9-r3h7-7x5v across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.