CVE-2026-58440

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.

## Affected product Gitea — `services/repository/collaboration.go` (`DeleteCollaboration`) + webhook delivery ## Summary When a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing after the collaborator's access is revoked. Gitea'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. ## 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's current access. ## 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:"opened"`, `issue.title:"CRITICAL SECRET: …"`, `issue.body` (sentinel private key), `repository.private:true`. (Runtime-confirmed on `gitea/gitea:1.25.4`. Catcher is an internal sentinel listener; the payload is a planted sentinel, not real data; nothing is sent to any external/metadata endpoint.) ## Impact Authenticated former admin-collaborator → ongoing real-time exfiltration of private content created after revocation; invisible to the owner; scope crosses from the application boundary to data the user should no longer access. ## Suggested remediation 1. On revocation, delete/disable webhooks created by the removed collaborator (or hand them to the owner). 2. Re-validate the creator's current repo access before each webhook delivery. 3. At minimum, warn admins on revocation if the user created webhooks. ## Credit Reported as part of an incomplete-patch / authorization-residue measurement study (responsible disclosure).

Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content in gitea.dev