PT-2026-63306 · Go · Gitea.Dev
CVE-2026-58440
·
Publicado
2026-07-21
·
Atualizado
2026-07-21
CVSS v3.1
6.8
Média
| Vetor | AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N |
Affected product
Gitea —
services/repository/collaboration.go (DeleteCollaboration) + webhook deliverySummary
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).
Correção
Incorrect Authorization
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Enumeração de Fraquezas
Identificadores relacionados
Produtos afetados
Gitea.Dev