EUVD-2026-58167
GHSA-66m4-5jjr-2rg5
Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
PR:H required for prior admin collaboration to create webhooks; S:C because payloads cross revoked authorization boundary to external endpoint; I:N and A:N as no write or availability impact exists.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
Lifecycle Timeline
2DescriptionCVE.org
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.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 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).
AnalysisAI
Webhook persistence after collaborator revocation in Gitea (versions prior to 1.27.0) enables a former admin collaborator to receive ongoing real-time exfiltration of private repository content indefinitely after their access is removed. The DeleteCollaboration() function cleans watches and assignees but never removes or disables webhooks created by the departing user, and the webhook delivery subsystem fires payloads on every subsequent repository event without re-validating the creator's current access. The attack is invisible to the repository owner, requires no further action by the attacker post-revocation, and was runtime-confirmed on gitea/gitea:1.25.4; no public exploit has been identified at time of analysis.
Technical ContextAI
Gitea is a self-hosted Git service written in Go. The vulnerability resides in services/repository/collaboration.go within the DeleteCollaboration() function, which orchestrates cleanup when a collaborator's access is revoked: it removes the collaboration record, recalculates access levels, drops watchers, and unassigns issues - but performs no webhook lifecycle management. The webhook delivery path, separately, fires payloads synchronously on repository events without consulting current collaborator membership. CWE-863 (Incorrect Authorization) precisely describes the root cause: an authorization check that should exist at webhook delivery time is simply absent. The affected Go package is gitea.dev (CPE: pkg:go/gitea.dev), confirmed vulnerable below version 1.27.0 per GHSA-66m4-5jjr-2rg5. The GHSA advisory also references companion PRs addressing related access-subquery filtering in Actions run listings and SSH key length validation, suggesting the 1.27.0 release is a broader security hardening batch.
RemediationAI
Upgrade to Gitea v1.27.0 or later; this release incorporates the fixes from pull requests #38406 (https://github.com/go-gitea/gitea/pull/38406) and #38426 (https://github.com/go-gitea/gitea/pull/38426), with corresponding commits de4b8277e9cb576f2315fb03b5ab6478b42a1d31 and f69e15afe7496cc62e96dab244629c69eb31a7bf. If immediate upgrade is not possible, administrators should manually audit and remove webhooks created by any collaborator whose access has been or is being revoked, accessible via repository Settings → Webhooks - note that Gitea does not currently surface the webhook creator in the UI, so this requires cross-referencing webhook creation timestamps with collaboration history. As a partial mitigation, configuring ALLOWED_HOST_LIST in app.ini (refactored to the [security] section in PR #38406) to restrict webhook delivery to trusted external CIDR ranges or hostnames reduces the risk of exfiltration to arbitrary attacker-controlled infrastructure, though it does not remediate the root authorization failure. Restricting admin-level collaboration grants to fully trusted parties is a preventive control with no functional side effects. The advisory is at https://github.com/go-gitea/gitea/security/advisories/GHSA-66m4-5jjr-2rg5.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today