CVE-2026-58440 is a medium-severity (CVSS 6.8) CWE-284 vulnerability in gitea.dev. A fix is available for gitea.dev — see the affected versions and patch details below.
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`)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-58440.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-58440 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 380,066 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
gitea.devReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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.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).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | gitea.dev | all versions | 1.27.0go get gitea.dev@v1.27.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gitea.dev, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update gitea.dev to 1.27.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-58440 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A flaw was found in Gitea's `DeleteCollaboration` function. When a collaborator's repository access is revoked, existing webhooks created by that user remain active instead of being disabled or removed. An attacker who previously held collaborator permissions can leverage these orphaned webhooks to continuously…
To mitigate this vulnerability, repository administrators should manually audit and delete all webhooks created by a collaborator immediately upon revoking their access.Source: Red Hat security advisory for CVE-2026-58440 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-58440 in your dependencies?
Find it across Go, including transitive dependencies.