Summary
Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content
Advisory details
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:
- Attacker (admin collaborator) creates a webhook → revoke access.
- Control:
GET /api/v1/repos/admin/wh-repo(attacker) → 404. GET .../hooks→ webhook stillactive=true.- 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 ongitea/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
- On revocation, delete/disable webhooks created by the removed collaborator (or hand them to the owner).
- Re-validate the creator's current repo access before each webhook delivery.
- 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).
References
- https://github.com/advisories/GHSA-66m4-5jjr-2rg5
- https://github.com/go-gitea/gitea/security/advisories/GHSA-66m4-5jjr-2rg5
- https://github.com/go-gitea/gitea/pull/38406
- https://github.com/go-gitea/gitea/pull/38426
- https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31
- https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf
- https://github.com/go-gitea/gitea/releases/tag/v1.27.0
Related vulnerabilities
All Supply chain →- MEDIUMCVE-2026-72792
SiYuan: Tag labels from password-protected documents are returned to readers who have not entered the password
- MEDIUMCVE-2026-63733
SurrealDB: Writes in a PERMISSIONS clause bypass table permissions
- HIGHGHSA-w8wf-3qvj-6xqf
OpenClaw Feishu permission tools could ignore per-account disablement
- HIGHGHSA-2q7j-2vhx-56g8
OpenClaw Feishu tools could ignore per-account disablement
- MEDIUMCVE-2026-56743
Cilium may unexpectedly allow ingress traffic from the local namespace when a Kubernetes NetworkPolicy is configured with an ipBlock match
- HIGHCVE-2026-73841
OpenChoreo: Cross-project command execution and wirelog view access via OpenChoreo openchoreo-api exec and wirelogs endpoints