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).