https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 12 Oct 2026 08:31:50 +0000 https://vulnerability.circl.lu/vuln/cve-2026-58440 <p><strong>Affected:</strong> Gitea Open Source Git Server</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> <p><strong>Affected:</strong> Gitea Open Source Git Server</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://vulnerability.circl.lu/vuln/cve-2026-58440 https://vulnerability.circl.lu/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://vulnerability.circl.lu/vuln/ghsa-66m4-5jjr-2rg5