Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content
Gitea — services/repository/collaboration.go (DeleteCollaboration) + webhook delivery
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.
services/repository/collaboration.go → DeleteCollaboration() — cleans watches/assignees only; no
webhook cleanup.Using the provided reproduction materials:
GET /api/v1/repos/admin/wh-repo (attacker) → 404.GET .../hooks → webhook still active=true.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.)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.
Reported as part of an incomplete-patch / authorization-residue measurement study (responsible disclosure).
为什么是这个 VPI(可解释·实验性)
VPI 计算依据
| 影响度 | 68.00 |
| 利用信号(无额外利用信号) | ×1.00 |
| VPI | 68.00 |
VPI 公式 vpi-v1