Gitea CVE-2026-26307

Requires that the Gitea instance expose its repository code-search feature to the attacker and host at least one repository large enough for a git grep to be computationally expensive; the vulnerable code path is GrepSearch in modules/git/grep.go which ran with no timeout before 1.25.5. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N) the network-facing search endpoint is reachable without authentication or user interaction against default configurations, though on instances configured to require login for repository access the effective attacker must hold a valid account. Limiting factors: impact is availability-only (no data disclosure or modification), the search endpoint must be reachable, and instances with small repositories or anonymous-search disabled present less exploitable surface.

Signals are consistent but point to moderate, not critical, real-world urgency. The CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N, availability-only impact A:H) reflects an easy, network-reachable DoS with no confidentiality or integrity effect. SSVC aligns: Exploitation 'none' (no observed exploitation), Automatable 'yes' (a script can hammer the search endpoint), Technical Impact 'partial' (resource exhaustion, not takeover). EPSS is low at 0.18% (7th percentile), and the vulnerability is NOT in CISA KEV, so there is no evidence of active exploitation - the risk is availability degradation rather than compromise. One nuance to verify: CVSS scores this PR:N (unauthenticated), but real exposure depends on whether repository code search is reachable by anonymous users or only authenticated members on a given instance; on private/internal instances the practical attacker population is smaller. Overall this is a legitimate patch-soon DoS hardening issue, not a drop-everything emergency.

An attacker with access to the Gitea web interface (anonymously if code search is public, otherwise as a low-privilege user) submits a stream of deliberately expensive code-search queries against large repositories. Each unbounded git grep consumes CPU for an extended period, and by automating concurrent requests the attacker exhausts server resources and denies service to legitimate users. No public exploit code is required - the attack reuses the normal search feature.