CVE-2026-103869
Description
A flaw was found in pulp-ansible's bearer-token refresh for collection remotes. The access token is kept in one module-level variable and reused for every token download in that worker. A user who can sync an Ansible remote that uses token refresh, and can point that remote at a server they control, receives an access token obtained for a different remote, and can reuse it at the service that issued it. Content stored in Pulp is not changed, and the service is not stopped.
Statement
This flaw has been rated as Moderate by Red Hat Product Security. The vulnerability affects pulp-ansible's bearer-token refresh for collection remotes.
The caller here must already be allowed to sync an Ansible remote configured for token refresh. The collection remote token is write-only on the API, so the sync is how another account obtains it. Once one refresh has filled the worker, a later sync reads the cache at will.
The caller needs ansible.sync_ansiblerepository on a remote that has both a token and an auth_url. That pair is the ordinary Galaxy and Automation Hub refresh-token configuration. No further setting is required. Remotes that do not refresh a token never enter this path. The stored token is process-wide, including across Pulp domains, and it remains until the worker exits.
The vulnerable global was added in pulp-ansible 0.6.0
It has same root cause as reported pulp_container finding (CVE-2026-103868). This is a separate CVE from the pulp-container, as it has different codebase, and independently fixable.
Note: RHUI does not ship pulp-ansible.
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
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.
