CVE-2026-84232: Pulpcore: python-pulpcore: stored cross-site scripting via inline rendering of uploaded html/svg content
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.
Other sources
The Pulp content app (pulpcore, aiohttp-based, separate from the Django REST API) serves files uploaded to file-type repositories at the URL path /pulp/content/<org>/Library/custom/<product>/<repo>/<filename>. Content-Type is determined from the file extension via a static MIME types map (pulpcore/app/mimetypes.py): .html → text/html, .svg → image/svg+xml, .xhtml → application/xhtml+xml.
Content-Disposition: attachment is set only for object-storage redirect paths (S3, Azure, GCS) in buildurl(). For local filesystem storage - the default in Satellite - the content app returns a bare FileResponse with no Content-Disposition header. There are no X-Content-Type-Options, CSP, or X-Frame-Options headers either.
Django's SecurityMiddleware does not apply because the content app is an entirely separate aiohttp process (pulpcore-content.service), not part of the Django WSGI application. The Apache reverse proxy for /pulp/content/ (configured via puppet-pulpcore) also adds no security headers.
Because /pulp/content/ is on the same origin as the Satellite web UI (same hostname, port 443), uploaded HTML/SVG files execute JavaScript in the Satellite application's security context. An authenticated user with content management permissions can upload a malicious HTML file, then send the URL to a victim. When the victim visits the URL while authenticated to Satellite, the attacker's script can read page content, make authenticated API calls, and perform actions as the victim.
Rails sets session cookies as HttpOnly by default, so direct cookie exfiltration via document.cookie is blocked. The attacker can still perform actions as the victim through AJAX requests to the Foreman and Pulp APIs.
The file upload requires permissions to manage products and repositories (createproducts, editproducts, or equivalent content management role). This is a standard operator-level capability, not admin-only. The victim must click the link (UI:R).
This is a purely web-layer attack. It does not require becoming the pulp system user or any OS-level access. The pulp content process performs the filesystem I/O, but the exploit is in the HTTP response headers (or lack thereof).
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using local filesystem storage are exposed because the content application returns uploaded files directly without a Content-Disposition: attachment header. Local filesystem storage is the default in Satellite.
What does an attacker need to exploit the flaw?
The attacker needs authenticated access or content upload permissions for a Pulp file-type repository. They must upload a crafted HTML, SVG, or XHTML file and cause another user to visit its content URL.
Are object-storage-backed deployments affected in the same way?
The described inline-rendering behavior applies to local filesystem storage. For S3, Azure, and GCS redirect paths, the application sets Content-Disposition: attachment in _build_url().
How can I identify potentially dangerous uploaded content?
Review file-type repository content served under /pulp/content/<org>/Library/custom/<product>/<repo>/<filename>, particularly uploaded files with .html, .svg, or .xhtml extensions. These extensions are assigned browser-renderable content types by the static MIME type map.