Description

A flaw was found in pulpcore's content serving application. Files uploaded to Pulp file-type repositories are served with their original content type (e.g., text/html for .html files, image/svg+xml for .svg files) and without a Content-Disposition: attachment header when using local filesystem storage. An authenticated user or attacker with content upload permissions can upload a specially crafted HTML or SVG file containing JavaScript, which executes in the browser of any user who visits the file URL, resulting in stored cross-site scripting (XSS) in the context of the host application.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-01T16:17:36.360Z",
  "pubdate": "2026-09-01T16:17:36.360Z",
  "executiveSummary": "A stored cross-site scripting (XSS) vulnerability exists within the pulpcore content serving application when configured for local filesystem storage.\nThe vulnerability arises due to the application serving user-uploaded files with their original MIME types, such as text/html or image/svg+xml, without enforcing a Content-Disposition: attachment header.\nAn authenticated attacker with content upload permissions can leverage this behavior to host malicious HTML or SVG files containing arbitrary JavaScript payloads.\nWhen a victim accesses the URL of the uploaded file, the browser interprets the malicious script within the context of the host application's origin.\nThis flaw allows for unauthorized script execution, potentially leading to session hijacking, data exfiltration, or the performance of unauthorized actions on behalf of the victim.\nThe risk is significant for organizations relying on Pulp for file management, as it enables stored XSS attacks targeting administrative users or other authenticated entities accessing the repository content.\nExploitation requires an account with sufficient permissions to upload content, followed by a victim interacting with the specifically crafted file URL.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of Content-Type headers and the absence of security-focused HTTP headers for files served from the local filesystem storage backend in pulpcore.\nWhen files are uploaded to Pulp file-type repositories, the application serves them using the MIME type associated with the file extension (e.g., .html files are served as text/html).\nBecause the server does not append a Content-Disposition: attachment header, browsers do not force a download; instead, they render the file content directly in the browser tab.\nIf an attacker uploads a malicious .html file containing <script> tags or a .svg file with embedded JavaScript via an <iframe> or <script> element, the browser will execute this code upon navigation to the file URL.\nThe exploitation flow proceeds as follows: First, an authenticated attacker with repository write access crafts a file (e.g., payload.html) containing malicious JavaScript. Second, the attacker uploads this file to the pulpcore repository via the appropriate API endpoints.\nThird, the attacker shares the direct URL of the uploaded file with a target user. When the target user—typically an administrator or another authorized user—navigates to this URL, the pulpcore server responds with the file's content and the original, untrusted MIME type.\nThe browser processes the response, identifies the executable nature of the HTML/SVG content, and executes the embedded JavaScript within the domain of the host application.\nThis execution happens in the security context of the origin, granting the malicious script full access to cookies, localStorage, and session tokens associated with the pulpcore instance, provided they are not protected by the HttpOnly flag.\nThe vulnerability is limited to installations utilizing local filesystem storage, as this configuration directly exposes the server's response headers regarding MIME type identification without intermediary processing.\nThe impact includes the potential for session theft, credential harvesting via DOM manipulation, or the automation of destructive actions (e.g., deleting repositories, modifying configurations) performed via background AJAX requests initiated by the script.\nThe attack is persistent (stored) because the payload remains hosted on the server indefinitely until manually removed or the repository is deleted, making it an effective vector for long-term target compromise."
}