https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 05:23:22 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-12010 bdu:2026-12010 https://cve.radiocsirt.org/vuln/bdu:2026-12010 https://cve.radiocsirt.org/vuln/euvd-2026-333755 EUVD-2026-333755 https://cve.radiocsirt.org/vuln/euvd-2026-333755 https://cve.radiocsirt.org/vuln/fkie_cve-2026-24451 <p>Gitea 1.26.2 allows fork synchronization to continue after a parent repository changes from public to private, exposing data to a fork that should no longer be authorized.</p> <p>Gitea 1.26.2 allows fork synchronization to continue after a parent repository changes from public to private, exposing data to a fork that should no longer be authorized.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-24451 https://cve.radiocsirt.org/vuln/ghsa-wrf9-r3h7-7x5v <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>### Summary</p> <p>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.</p> <p>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.</p> <p>### Details</p> <p>Gitea provides the `merge-upstream` API to synchronize a fork with its parent repository.</p> <p>A typical workflow is:</p> <p>1. A repository is public. 2. Another user creates a fork. 3. The fork owner uses `merge-upstream` to receive updates from the parent repository.</p> <p>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.</p> <p>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`.</p> <p>As a result, commits created after the visibility change can be propagated into the fork through the normal fork synchronization workflow.</p> <p>### PoC</p> <p>#### Proof-of-Concept Code</p> <p>https://anonymous.4open.science/r/Gitea_PoC-EC93/4_poc_merge_upstream</p> <p>#### PoC Details</p> <p>1. User `alice` creates a public repository `alice/P`. 2. User `bob` forks the repository, creating `b…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>### Summary</p> <p>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.</p> <p>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.</p> <p>### Details</p> <p>Gitea provides the `merge-upstream` API to synchronize a fork with its parent repository.</p> <p>A typical workflow is:</p> <p>1. A repository is public. 2. Another user creates a fork. 3. The fork owner uses `merge-upstream` to receive updates from the parent repository.</p> <p>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.</p> <p>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`.</p> <p>As a result, commits created after the visibility change can be propagated into the fork through the normal fork synchronization workflow.</p> <p>### PoC</p> <p>#### Proof-of-Concept Code</p> <p>https://anonymous.4open.science/r/Gitea_PoC-EC93/4_poc_merge_upstream</p> <p>#### PoC Details</p> <p>1. User `alice` creates a public repository `alice/P`. 2. User `bob` forks the repository, creating `b…</p> https://cve.radiocsirt.org/vuln/ghsa-wrf9-r3h7-7x5v https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2027 <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um erweiterte Berechtigungen zu erlangen, sich als Benutzer auszugeben, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren und vertrauliche Informationen offenzulegen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um erweiterte Berechtigungen zu erlangen, sich als Benutzer auszugeben, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren und vertrauliche Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2027