Skip to content

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`)

Moderate
bircni published GHSA-66m4-5jjr-2rg5 Jul 13, 2026

Package

gomod gitea.dev (Go)

Affected versions

<= 1.26.4

Patched versions

1.27.0

Description

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.goDeleteCollaboration() — 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).

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
High
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

CVE ID

CVE-2026-58440

Weaknesses

No CWEs

Credits