Gitea EUVD-2026-58124

Exploitation requires an authenticated Gitea session with at minimum repository admin privileges on the target repository - a non-admin authenticated user cannot access webhook listing endpoints. For broader harvesting, org admin access enables GET /api/v1/orgs/{org}/hooks, and site admin enables GET /api/v1/admin/hooks. The vulnerability is triggered whenever at least one webhook has an authorization header configured (Bearer token, Basic auth, or API key); webhooks without authorization headers are not affected. No special or non-default Gitea configuration is required - any standard installation running a vulnerable version with webhooks using authorization headers is affected. Exploitation is bounded by the value of the third-party credentials stored: if all webhook destinations are low-sensitivity, the real-world impact is limited. The key limiting factor is the requirement for elevated Gitea admin privileges, which meaningfully reduces the attacker population compared to an unauthenticated flaw.

The CVSS 3.1 score of 2.7 Low is driven primarily by the high privilege requirement (PR:H), which correctly reflects that exploitation demands an authenticated repository admin session. The network attack vector (AV:N) and low complexity (AC:L) mean that once admin credentials are in hand, exploitation is trivial - a single HTTP GET request. No EPSS data was provided in the input, and this vulnerability is not in CISA KEV, indicating no confirmed active exploitation at time of analysis. No public POC has been identified. The real-world risk is elevated in shared or multi-tenant Gitea deployments where multiple admins co-manage repositories, as any one admin can harvest credentials configured by another admin to access external third-party systems. In single-admin or access-controlled deployments, practical exploitability is substantially lower. The Low CVSS score is technically defensible but may underrepresent business impact in environments where webhook secrets authenticate to high-value downstream services such as cloud APIs, deployment pipelines, or security tooling.

An authenticated Gitea repository admin issues a standard GET /api/v1/repos/{owner}/{repo}/hooks request using their own valid session token. The API response includes the full plaintext Bearer token or API key that a different admin had configured on a webhook to authenticate deliveries to an external CI/CD system. The attacker then uses this harvested credential directly against the external service, bypassing Gitea entirely. No public exploit code exists; exploitation requires only curl or any HTTP client with a valid admin token.