Gitea EUVD-2026-41626

Exploitation requires an authenticated Gitea user account - anonymous access is insufficient. The time-tracking feature must be enabled in the Gitea instance (it is enabled by default). The attacker must know or be able to enumerate a valid numeric time-entry ID belonging to another issue; since IDs are sequential integers returned in API list responses, this is trivial for any user with repository read access. Limiting factors: the attacker cannot read time entries they are not authorized to view; impact is confined to deletion of time-tracking records (no data exfiltration, no code execution); and the attacker must already hold a valid Gitea account or API token for the instance.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, score 5.3) claims no privileges are required (PR:N), but this conflicts with the technical evidence: both the API and web integration tests require an authenticated session or token, as shown by loginUser() and AddTokenAuth(token) in the test code. This metric appears incorrect - PR:L (low privileges, authenticated user) is more accurate, which would reduce the base score to approximately 4.3. Real-world risk is low: EPSS is 0.16% (5th percentile), SSVC reports exploitation: none and technical impact: partial, and there is no KEV listing. The impact is limited to deletion of time-tracking entries across issues - no confidentiality loss, no code execution, no service disruption. SSVC notes the attack is automatable (low complexity, no user interaction once authenticated), but the narrow impact class keeps this in low operational priority for most organizations. The discrepancy between PR:N in the NVD CVSS and the authenticated-only code paths should be verified with the Gitea security team.

An authenticated Gitea user enumerates numeric time-entry IDs from issues they have access to - IDs are sequential integers visible in API responses. The attacker then sends a DELETE request to an issue URL they can access (e.g., /api/v1/repos/victim/repo/issues/1/times/99) substituting time ID 99 from a different issue, causing that entry to be silently deleted without the legitimate owner's involvement. No public exploit code has been identified at time of analysis.