GHSA-9v6p-xpcp-7488: Gitea stored XSS through legacy Actions artifact Content-Encoding
Legacy (v1 to v3) Actions artifact uploads stored the request's Content-Encoding header unchecked in the column that is served as the artifact's Content-Type on download, and a value starting with video/ or audio/ also removed the sandboxing Content-Security-Policy. A user who can run an Actions job could upload an artifact that a browser renders as HTML on the Gitea origin when the direct artifact download URL is opened, and the URL is reachable anonymously on public repositories. A victim who opens the link runs the attacker's script with their own session, which for an administrator means control of the instance. Legacy uploads now store only the gzip marker, and the special serve headers are chosen only for valid media types.
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs permission to run an Actions job and to upload an artifact using the legacy v1 through v3 upload path. Exploitation also requires a victim to open the artifact's direct download URL in a browser.
When can an attacker deliver a link to an unauthenticated victim?
The direct artifact download URL is reachable anonymously for artifacts in public repositories. This makes public repositories a practical delivery path even when the victim has not signed in before opening the link.
What is the impact if an administrator opens a malicious artifact link?
The attacker's script runs with the victim's session on the Gitea origin. If the victim is an administrator, this can result in control of the Gitea instance.
Are newly uploaded artifacts still affected?
The corrected behavior stores only the gzip marker for legacy uploads and selects special serving headers only for valid media types. The issue concerns artifacts uploaded through the legacy v1 to v3 upload handling.