CVE-2026-84232
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.
Statement
Red Hat Product Security has assessed this issue as a Moderate severity vulnerability.
This vulnerability affects pulpcore's content serving application, which is an aiohttp process separate from the Django REST API.
The confidentiality and integrity impact is limited because the session cookie in the host application (Foreman/Satellite) is set with the HttpOnly attribute, which prevents direct session token theft via JavaScript. The attacker's script can read visible page content and make authenticated API requests on behalf of the victim through the browser, but cannot exfiltrate the session itself or gain persistent access beyond the victim's active browser session. There is no availability impact.
In Red Hat Satellite, the /pulp/content/ path shares the same origin (protocol, hostname, and port) as the Satellite web UI, making the XSS effective against Satellite sessions.
Ansible Automation Platform and RHUI also ship pulpcore, but they do not use pulp_file repositories and therefore are not affected by this vulnerability.
Mitigation
If immediate update is not possible, administrators can add security headers to the Apache reverse proxy configuration for the /pulp/content/ path. On Satellite, add the following to the Apache configuration (e.g., via a custom .conf file in /etc/httpd/conf.d/ or via a Puppet override):
<Location /pulp/content>This forces all content downloads rather than inline rendering, and blocks script execution even if Content-Disposition is somehow bypassed.
Header set Content-Disposition "attachment"
Header set X-Content-Type-Options "nosniff"
Header set Content-Security-Policy "default-src 'none'; sandbox"
</Location>
After applying, restart Apache:
systemctl restart httpd
Alternatively, restrict file upload permissions in Satellite to only trusted users who require content management capabilities.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 5.4 | N/A | 5.4 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | Low | N/A | Low |
| User Interaction | Required | N/A | Required |
| Scope | Changed | N/A | Changed |
| Confidentiality | Low | N/A | Low |
| Integrity Impact | Low | N/A | Low |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
Understanding the Weakness (CWE)
Access Control,Confidentiality
Technical Impact: Bypass Protection Mechanism; Read Application Data
The most common attack performed with cross-site scripting involves the disclosure of private information stored in user cookies, such as session information. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity on behalf of the victim to an attacker-controlled system (such as sending all site cookies to a given E-mail address). This could be especially dangerous to the site if the victim has administrator privileges to manage that site. This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.
Integrity,Confidentiality,Availability
Technical Impact: Execute Unauthorized Code or Commands
In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws, for example, "drive-by hacking."
Confidentiality,Integrity,Availability,Access Control
Technical Impact: Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Read Application Data
The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running "Active X" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
