CVE-2026-96594 in Gitea
Summary
by MITRE • 10/07/2026
The Gitea API endpoint `GET /api/v1/repos/{owner}/{repo}/media/{filepath}` wrote files of up to 1 KiB that are stored directly in Git, not in LFS, to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was therefore rendered by the browser on the Gitea origin. A user who can push to a repository could run JavaScript in the session of a victim who opens the media URL and act with the victim's permissions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified involves a critical security flaw within the Gitea application, specifically affecting the API endpoint GET /api/v1/repos/{owner}/{repo}/media/{filepath}. This endpoint is designed to serve file content from repositories, but it fails to apply necessary HTTP response headers when serving files that are stored directly in Git rather than via Large File Storage. The technical root cause lies in the omission of Content-Type and Content-Disposition headers for these specific media types. When a user commits an HTML file to a repository, Gitea serves this content through the API endpoint without instructing the browser on how to handle it properly. Consequently, modern web browsers interpret the response as executable script or markup rather than static data, leading to direct execution of any embedded JavaScript within the context of the Gitea origin.
This flaw creates a severe Cross-Site Scripting risk that is exacerbated by its location in an API endpoint often used for programmatic access and potentially automated tools. An attacker who possesses push permissions to a repository can craft a malicious HTML payload containing arbitrary JavaScript code. When another user, particularly one with administrative or elevated privileges within the Gitea instance, accesses this media URL through their browser session, the malicious script executes immediately. Because the request originates from the same origin as the application itself, it bypasses standard Same-Origin Policy protections that might otherwise restrict cross-domain attacks. The attacker can thus perform actions on behalf of the victim, such as modifying repository settings, stealing authentication tokens stored in local storage or cookies, exfiltrating sensitive data visible within the interface, or even escalating privileges if the victim has broader access rights.
From a classification perspective, this vulnerability aligns with CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as Cross-Site Scripting (XSS). More specifically, it represents an Unrestricted File Upload scenario where the uploaded content type is not properly validated or sanitized before being served to clients. In terms of offensive security frameworks like MITRE ATT&CK, this behavior facilitates techniques related to Client-side Injection and potentially Credential Access if session tokens are harvested. The lack of proper Content-Type headers prevents browsers from enforcing MIME-type sniffing protections that might otherwise block the execution of scripts in contexts where they should be treated as plain text or binary data.
The operational impact is significant because it allows for persistent, repository-based attacks that do not require exploiting server-side logic flaws beyond the initial file upload and serving mechanism. Once an attacker commits their payload, any subsequent access to that media file by a privileged user can result in immediate compromise of that user's session. This undermines the integrity and confidentiality guarantees provided by Gitea’s authentication model. Mitigation strategies must focus on enforcing strict Content-Type headers for all served files, ensuring they are set to application/octet-stream or text/plain depending on context, rather than allowing browsers to guess based on file extension or content sniffing. Additionally, implementing a Content-Security-Policy header that restricts script execution from media endpoints can provide an additional layer of defense. Developers should also consider validating the MIME type against allowed lists and ensuring that all API responses include appropriate security headers regardless of whether the underlying storage is Git objects or LFS pointers.