REDHAT-BUG-2526807: Medium severity pulpcore content app vulnerability
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).
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed?
Satellite deployments using the default local filesystem storage are exposed because locally served content is returned without a Content-Disposition header. The affected content path shares the same hostname and HTTPS origin as the Satellite web UI.
Does the usual Django or Apache security configuration add protection for this content?
No. The content service is a separate aiohttp process, so Django SecurityMiddleware does not apply, and the Apache reverse-proxy configuration for /pulp/content/ adds no security headers.
How can I check whether a repository is serving potentially active content without download enforcement?
Request a file from a file-type repository through its /pulp/content/ URL and inspect the response headers. For local filesystem storage, the response is a bare FileResponse without Content-Disposition; HTML, SVG, and XHTML extensions are assigned active-content MIME types from the static map.
Does object storage behave differently?
Yes. The S3, Azure, and GCS redirect paths set Content-Disposition: attachment in _build_url(). This behavior is not applied when content is served from local filesystem storage.