https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 20:37:49 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-352917 EUVD-2026-352917 https://cve.radiocsirt.org/vuln/euvd-2026-352917 https://cve.radiocsirt.org/vuln/fkie_cve-2026-58440 <p>Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`)</p> <p>Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`)</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-58440 https://cve.radiocsirt.org/vuln/ghsa-66m4-5jjr-2rg5 <p><strong>Affected:</strong> Go: gitea.dev</p> <p>## Affected product Gitea — `services/repository/collaboration.go` (`DeleteCollaboration`) + webhook delivery</p> <p>## Summary When a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing after the collaborator&#39;s access is revoked. Gitea&#39;s revocation cleanup `DeleteCollaboration` removes the collaboration record, recalculates accesses, drops watches, and unassigns issues — but it does **not** remove or disable webhooks the user created, and webhook delivery never re-checks whether the creator still has repo access. The former collaborator therefore receives the full payload (issue/comment bodies, commit data) of all future repository events at their controlled endpoint, indefinitely and invisibly.</p> <p>## Affected code - `services/repository/collaboration.go` → `DeleteCollaboration()` — cleans watches/assignees only; no webhook cleanup. - Webhook delivery path — fires on repo events without re-validating the creator&#39;s current access.</p> <p>## Steps to reproduce Using the provided reproduction materials: 1. Attacker (admin collaborator) creates a webhook → revoke access. 2. Control: `GET /api/v1/repos/admin/wh-repo` (attacker) → **404**. 3. `GET .../hooks` → webhook still `active=true`. 4. Admin creates a new issue **after** revocation → the catcher receives `action:&#34;opened&#34;`, `issue.title:&#34;CRITICAL SECRET: …&#34;`, `issue.body` (sentinel private key), `repository.private:true`. (Runtime-confirmed on `gitea/gitea:1.25.4`. Catcher is an internal…</p> <p><strong>Affected:</strong> Go: gitea.dev</p> <p>## Affected product Gitea — `services/repository/collaboration.go` (`DeleteCollaboration`) + webhook delivery</p> <p>## Summary When a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing after the collaborator&#39;s access is revoked. Gitea&#39;s revocation cleanup `DeleteCollaboration` removes the collaboration record, recalculates accesses, drops watches, and unassigns issues — but it does **not** remove or disable webhooks the user created, and webhook delivery never re-checks whether the creator still has repo access. The former collaborator therefore receives the full payload (issue/comment bodies, commit data) of all future repository events at their controlled endpoint, indefinitely and invisibly.</p> <p>## Affected code - `services/repository/collaboration.go` → `DeleteCollaboration()` — cleans watches/assignees only; no webhook cleanup. - Webhook delivery path — fires on repo events without re-validating the creator&#39;s current access.</p> <p>## Steps to reproduce Using the provided reproduction materials: 1. Attacker (admin collaborator) creates a webhook → revoke access. 2. Control: `GET /api/v1/repos/admin/wh-repo` (attacker) → **404**. 3. `GET .../hooks` → webhook still `active=true`. 4. Admin creates a new issue **after** revocation → the catcher receives `action:&#34;opened&#34;`, `issue.title:&#34;CRITICAL SECRET: …&#34;`, `issue.body` (sentinel private key), `repository.private:true`. (Runtime-confirmed on `gitea/gitea:1.25.4`. Catcher is an internal…</p> https://cve.radiocsirt.org/vuln/ghsa-66m4-5jjr-2rg5 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