Gitea EUVD-2026-41608

The Gitea instance must have Actions enabled and be using the Artifacts V4 API, and the attacker must hold a valid authenticated account able to run or trigger at least one Actions task (PR:L) in order to obtain a validly signed artifact URL as the exploitation primitive. The HMAC ambiguity then lets a signature valid for the attacker's own repository/task be accepted for a different repository or task, enabling cross-repository artifact read and cross-task upload-state write. Limiting factors: Actions is not enabled on every Gitea deployment, exploitation is not anonymous (it requires low-privilege credentials plus the ability to run a workflow), and single-tenant instances where all users are already trusted see materially reduced real-world risk.

The signals are largely consistent toward high priority: CVSS 3.1 base 9.6 with AV:N/AC:L/PR:L/UI:N and a scope change (S:C) reflecting the cross-repository boundary crossing, C:H (reading other repos' private artifacts) and I:H (writing cross-task upload state), A:N. PR:L means exploitation requires an authenticated account with Actions access - not fully anonymous - which tempers the raw score on multi-user instances where any user can register and run workflows. No EPSS score, KEV entry, or POC was provided, so real-world exploitation pressure is currently unquantified: high theoretical impact but no evidence yet of active or automated exploitation. The vendor (Gitea) self-reported and shipped a fix, which typically indicates responsible disclosure rather than in-the-wild abuse. Net: treat as a genuine high priority for any Gitea instance running Actions with untrusted or multi-user access, but the absence of KEV/POC/EPSS evidence points to targeted rather than mass exploitation risk.

An attacker registers or already holds a low-privilege account on a shared Gitea instance and triggers a workflow to obtain a legitimately signed Artifacts V4 URL. Exploiting the HMAC ambiguity, they re-scope that signed URL to a victim repository, downloading its private build artifacts (which may contain source, credentials, or secrets) and writing forged upload-state into another team's task. No public POC has been identified, but the low attack complexity (AC:L) makes weaponization straightforward once the signing scheme is understood.