GHSA-66M4-5JJR-2RG5
Vulnerability from github – Published: 2026-07-21 20:11 – Updated: 2026-07-21 20:11Affected 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
- 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).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "gitea.dev"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58440"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:11:36Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Affected product\nGitea \u2014 `services/repository/collaboration.go` (`DeleteCollaboration`) + webhook delivery\n\n## Summary\nWhen a collaborator with admin permission on a private repo creates a webhook, that webhook keeps firing\nafter the collaborator\u0027s access is revoked. Gitea\u0027s revocation cleanup `DeleteCollaboration` removes the\ncollaboration record, recalculates accesses, drops watches, and unassigns issues \u2014 but it does **not**\nremove or disable webhooks the user created, and webhook delivery never re-checks whether the creator still\nhas repo access. The former collaborator therefore receives the full payload (issue/comment bodies, commit\ndata) of all future repository events at their controlled endpoint, indefinitely and invisibly.\n\n## Affected code\n- `services/repository/collaboration.go` \u2192 `DeleteCollaboration()` \u2014 cleans watches/assignees only; no\n webhook cleanup.\n- Webhook delivery path \u2014 fires on repo events without re-validating the creator\u0027s current access.\n\n## Steps to reproduce\nUsing the provided reproduction materials:\n1. Attacker (admin collaborator) creates a webhook \u2192 revoke access.\n2. Control: `GET /api/v1/repos/admin/wh-repo` (attacker) \u2192 **404**.\n3. `GET .../hooks` \u2192 webhook still `active=true`.\n4. Admin creates a new issue **after** revocation \u2192 the catcher receives `action:\"opened\"`,\n `issue.title:\"CRITICAL SECRET: \u2026\"`, `issue.body` (sentinel private key), `repository.private:true`.\n(Runtime-confirmed on `gitea/gitea:1.25.4`. Catcher is an internal sentinel listener; the payload is a\nplanted sentinel, not real data; nothing is sent to any external/metadata endpoint.)\n\n## Impact\nAuthenticated former admin-collaborator \u2192 ongoing real-time exfiltration of private content created after\nrevocation; invisible to the owner; scope crosses from the application boundary to data the user should no\nlonger access.\n\n## Suggested remediation\n1. On revocation, delete/disable webhooks created by the removed collaborator (or hand them to the owner).\n2. Re-validate the creator\u0027s current repo access before each webhook delivery.\n3. At minimum, warn admins on revocation if the user created webhooks.\n\n## Credit\nReported as part of an incomplete-patch / authorization-residue measurement study (responsible disclosure).",
"id": "GHSA-66m4-5jjr-2rg5",
"modified": "2026-07-21T20:11:36Z",
"published": "2026-07-21T20:11:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-66m4-5jjr-2rg5"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38406"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/38426"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked \u2192 ongoing real-time exfiltration of private repo content"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.