Gitea CVE-2026-22874

Exploitation requires an authenticated Gitea account (CVSS PR:L) with permission to create a webhook or start a repository migration/mirror - these are the exact features whose allow-list filtering is incomplete. The attacker must supply a target URL/host that bypasses the (present but incomplete) SSRF allow-list, and there must be a reachable internal service worth hitting from the Gitea host. Limiting factors: it is not exploitable unauthenticated, so instances that disable self-registration and restrict webhook/migration creation to trusted users substantially reduce risk; impact also depends on the Gitea server having network reachability to sensitive internal endpoints. Affects Gitea up to and including 1.26.2 on default configurations of those features.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, base 9.6) drives the critical score largely through the scope change (S:C) and high confidentiality/integrity impact, reflecting that a successful SSRF reaches systems beyond Gitea's own security authority. Importantly, PR:L confirms exploitation requires an authenticated account with privileges to create webhooks or initiate migrations, so this is not an unauthenticated internet-wide threat. No EPSS score, KEV listing, or POC was provided: there is no evidence of active exploitation or public exploit code, which tempers the raw 9.6. The realistic priority is 'patch promptly, especially on instances that permit self-registration or untrusted users,' rather than emergency response - the criticality is real but gated behind authentication and dependent on having sensitive internal services reachable from the Gitea host. Note the A:N in the vector is consistent with SSRF (data exposure/pivot, not denial of service).

An attacker registers or uses an existing low-privileged account on an internet-facing Gitea instance, then configures a repository webhook or starts a repository migration pointing at an internal address (e.g. a cloud metadata endpoint or internal service) encoded in a form that slips past the incomplete allow-list check. Gitea's server then issues the request from inside the trusted network and returns or acts on the response, exposing internal data or reaching services the attacker could not otherwise contact. No public exploit is currently identified, and success depends on the attacker having the low-privilege access denoted by CVSS PR:L.