GHSA-66M4-5JJR-2RG5

Vulnerability from github – Published: 2026-07-21 20:11 – Updated: 2026-07-21 20:11
VLAI
Summary
Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content
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.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).

Show details on source website

{
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…