CVE-2026-58440 is a medium-severity (CVSS 6.8) CWE-284 vulnerability in gitea.dev. O3 Security confirms whether CVE-2026-58440 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gitea: Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content
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.
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-58440 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-58440. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-58440 in your dependencies?
O3 detects CVE-2026-58440 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.