https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 19:45:25 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-15369 bdu:2026-15369 https://cve.radiocsirt.org/vuln/bdu:2026-15369 https://cve.radiocsirt.org/vuln/euvd-2026-352919 EUVD-2026-352919 https://cve.radiocsirt.org/vuln/euvd-2026-352919 https://cve.radiocsirt.org/vuln/fkie_cve-2026-58438 <p>Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access</p> <p>Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-58438 https://cve.radiocsirt.org/vuln/ghsa-xv9x-fj9g-vj6h <p><strong>Affected:</strong> Go: gitea.dev</p> <p>### Details `RemoveDependency` in `routers/web/repo/issue_dependency.go` takes a `removeDependencyID` form parameter identifying the other issue by its global numeric ID, and fetches it with `issues_model.GetIssueByID(ctx, depID)` - no repository or permission check at all. It then calls `issues_model.RemoveIssueDependency(ctx, ctx.Doer, issue, dep, depType)` (`models/issues/dependency.go`), which deletes the dependency join row and then writes a comment referencing the removal, attributed to the calling user, onto the dependency record.</p> <p>The sibling function in the very same file, `AddDependency`, does this correctly when the two issues are in different repos (which `ALLOW_CROSS_REPOSITORY_DEPENDENCIES`, on by default, permits):</p> <p>```go if issue.RepoID != dep.RepoID { if !setting.Service.AllowCrossRepositoryDependencies { ... } depRepoPerm, err := access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer) if !depRepoPerm.CanReadIssuesOrPulls(dep.IsPull) { return // you can&#39;t see this dependency } } ```</p> <p>`RemoveDependency` has no equivalent block at all - it goes straight from resolving `dep` by ID to deleting the link, regardless of which repo `dep` lives in or whether the caller can see it. I confirmed this same code is present in the current latest release, v1.26.4.</p> <p>### PoC Prerequisites: an account with write access to issues on some repo `ownerA/repoA`, and the global numeric issue ID of an issue in a private repo `repoB` that is (or was) legitimately depen…</p> <p><strong>Affected:</strong> Go: gitea.dev</p> <p>### Details `RemoveDependency` in `routers/web/repo/issue_dependency.go` takes a `removeDependencyID` form parameter identifying the other issue by its global numeric ID, and fetches it with `issues_model.GetIssueByID(ctx, depID)` - no repository or permission check at all. It then calls `issues_model.RemoveIssueDependency(ctx, ctx.Doer, issue, dep, depType)` (`models/issues/dependency.go`), which deletes the dependency join row and then writes a comment referencing the removal, attributed to the calling user, onto the dependency record.</p> <p>The sibling function in the very same file, `AddDependency`, does this correctly when the two issues are in different repos (which `ALLOW_CROSS_REPOSITORY_DEPENDENCIES`, on by default, permits):</p> <p>```go if issue.RepoID != dep.RepoID { if !setting.Service.AllowCrossRepositoryDependencies { ... } depRepoPerm, err := access_model.GetDoerRepoPermission(ctx, dep.Repo, ctx.Doer) if !depRepoPerm.CanReadIssuesOrPulls(dep.IsPull) { return // you can&#39;t see this dependency } } ```</p> <p>`RemoveDependency` has no equivalent block at all - it goes straight from resolving `dep` by ID to deleting the link, regardless of which repo `dep` lives in or whether the caller can see it. I confirmed this same code is present in the current latest release, v1.26.4.</p> <p>### PoC Prerequisites: an account with write access to issues on some repo `ownerA/repoA`, and the global numeric issue ID of an issue in a private repo `repoB` that is (or was) legitimately depen…</p> https://cve.radiocsirt.org/vuln/ghsa-xv9x-fj9g-vj6h https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2304 <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, sensible Informationen offenzulegen, Sitzungen zu übernehmen oder wiederzuverwenden oder einen Denial-of-Service-Zustand auszulösen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, sensible Informationen offenzulegen, Sitzungen zu übernehmen oder wiederzuverwenden oder einen Denial-of-Service-Zustand auszulösen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2304