REDHAT-BUG-2544603: Medium severity Pulp Pulp Ansible vulnerability
AUTHTOKEN in pulpansible/app/downloaders.py is a module global. TokenAuthHttpDownloader.getorupdatetoken() returns that global to any downloader in the process. It is not stored per remote or per token URL. The refresh path runs only when the remote has both token and authurl. A worker that has already refreshed one remote's token sends that access token as the bearer for a later remote. The collection remote token field is write-only. Introduced by 57f5775b, first release 0.6.0. It has same root cause as reported pulpcontainer finding (CVE-2026-103868). This is a separate CVE from the pulp-container, as it has different codebase, and independently fixable.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to token crossover?
The issue was introduced in Pulp Ansible 0.6.0. Exposure requires a worker process that handles collection remotes, including at least one remote configured with both a token and an auth_url.
What sequence causes a token to be sent to another remote?
A worker first refreshes a token for one remote, then processes a downloader for a later remote in the same process. The later downloader can receive the previously refreshed token because the token is held in a process-wide module global rather than being associated with a specific remote or token URL.
Does a remote without both token and auth_url avoid the problem?
Such a remote does not trigger the token refresh path, because refresh runs only when both fields are configured. However, the downloader can still be given a token already cached globally by an earlier remote in the same worker process.
How can operators assess whether their environment is at risk?
Identify Pulp Ansible deployments based on code introduced in or after release 0.6.0, then review collection remote configurations for remotes that have both token and auth_url set. Prioritize workers that may process more than one remote in the same process.