CVE-2026-103868
Description
A flaw was found in pulp-container when it authenticates to an upstream registry. Basic and bearer credentials from one remote are reused for later downloads in the same worker. A user who can sync a container remote, and can point that remote at a server they control, receives the username, password, or bearer token stored for a different remote, and can reuse that credential at the upstream registry. Content stored in Pulp is not changed, and the service is not stopped.
Statement
This vulnerability is rated as Moderate by Red Hat Product Security. This vulnerability affects pulp-container's authenticated download from container remotes.
The caller here must already be allowed to sync a container remote and to set its URL. The API keeps those credentials write-only, so the sync is how another account obtains them. Once any authenticated sync has filled the worker, a later sync reads the cache at will. That is not a race.
The caller needs container.sync_containerrepository and the ability to set the remote URL. No other setting is required. A deployment that never syncs an authenticated container remote has nothing stored to disclose. The cache is process-wide, including across Pulp domains, and it remains until the worker exits.
This is a separate CVE from the pulp-ansible token cache (CVE-2026-103869). A different repository and independently fixable.
The shared cache code was added in `pulp-container 1.3.0`.
RHUI ships this code, and an RHUI admin can type a registry URL when adding a container. Pulp here runs on a separate node, only that admin can reach it. End users have no path to the sync API. The admin who can reach it already configures those registry credentials and administers the node. That is not the same exposure as a Pulp user who can sync but does not already hold the credential. Hence, it is not affected because Vulnerable Code cannot be Controlled by Adversary.
Additionally, RHUI's container API client packages do not run the downloader. It does not contain `RegistryAuthHttpDownloader`. Hence, it is not affected.
Mitigation
Red Hat is not aware of a practical temporary workaround that fully mitigates this issue or meets Red Hat Product Security's standards for usability, deployment, applicability, or stability. Customers are advised to apply the relevant security updates when they become available.
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 | 6.5 | N/A | 6.5 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | None | N/A | None |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data
Data can "bleed" from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool. Storing user data in Servlet member fields introduces a data access race condition.
Acknowledgements
Red Hat would like to thank gwolfs (Independent Security Researcher) for reporting this issue.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
