What is the CVSS score of CVE-2026-58440?

CVE-2026-58440 has a CVSS 3.1 base score of 6.8 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N.

Is there a patch available for CVE-2026-58440?

Yes, a patch is available for CVE-2026-58440. Update the affected software to the latest version immediately.

Gitea CVE-2026-58440

MEDIUM

Incorrect Authorization (CWE-863)

2026-07-21 https://github.com/go-gitea/gitea

GHSA-66m4-5jjr-2rg5

Gitea Authentication Bypass

6.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.8 MEDIUM

AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

vuln.today AI

6.8 MEDIUM

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.

3.1 AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jul 21, 2026 - 20:36 vuln.today

Analysis Generated

Jul 21, 2026 - 20:36 vuln.today

DescriptionGitHub Advisory

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 still active=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. …

Unlock full vulnerability intelligence

Risk assessment & exploitation conditions
Attack chain visualization
Remediation with exact patch versions
Threat intelligence from 22 sources
Personal watchlist & email alerts

Continue with Google Continue with GitHub

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access

Attain admin collaborator access on target private repo

Delivery

Create webhook pointing to attacker-controlled endpoint

Exploit

Owner revokes collaborator access via Gitea UI

Execution

DeleteCollaboration() omits webhook cleanup, webhook remains active=true

Persist

Subsequent repo events trigger webhook delivery without creator access re-check

Impact

Attacker passively receives full event payloads (issue bodies, commit data, secrets) indefinitely

Access

Attain admin collaborator access on target private repo

Delivery

Create webhook pointing to attacker-controlled endpoint

Exploit

Owner revokes collaborator access via Gitea UI

Execution

DeleteCollaboration() omits webhook cleanup, webhook remains active=true

Persist

Subsequent repo events trigger webhook delivery without creator access re-check

Impact

Attacker passively receives full event payloads (issue bodies, commit data, secrets) indefinitely

Vulnerability AssessmentAI

Exploitation	Exploitation requires the attacker to have previously held admin-level collaboration permission on a private Gitea repository, specifically sufficient permission to create repository-level webhooks (a capability restricted to admin collaborators, not base collaborators). … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment	The provided CVSS 3.1 vector AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N yields a score of 6.8 (Medium), which accurately reflects the threat model: the PR:H prerequisite (prior admin collaboration on the targeted repository) substantially limits the attack surface, while S:C and C:H capture that once established, full event payloads - issue bodies, commit data, repository metadata - cross the revoked authorization boundary to an attacker-controlled endpoint. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario	An attacker who holds admin collaborator access on a target private Gitea repository creates a webhook pointing to an endpoint they control, then waits for - or engineers - their access to be revoked by the repository owner. Despite the revocation, Gitea's `DeleteCollaboration()` leaves the webhook intact and active; every subsequent repository event (new issues, comments, commits, PR activity) delivers the full JSON payload - including issue titles, bodies, commit messages, and the `repository.private:true` flag - to the attacker's endpoint with no further action required. …
Remediation	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. … Detailed patch versions, workarounds, and compensating controls in full report.