CVE-2026-103869: Pulp-ansible: bearer tokens are reused across remotes in a worker
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.
Other sources
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.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs permission to sync an Ansible collection remote that uses token refresh and must be able to configure that remote to point to a server they control. The vulnerable worker must previously have refreshed a token for a different remote.
Are all collection remotes affected?
No. The token-refresh path is used only when a collection remote has both a token and an auth_url configured. The issue arises when workers handle more than one such remote because the refreshed token is shared at the module level rather than stored per remote or token URL.
What could an attacker obtain or do?
The attacker can receive an access token that was obtained for a different remote and reuse it against the service that issued that token. The described impact does not modify content stored in Pulp or stop the service.
How can I determine whether exposure is possible in my environment?
Review whether users who can create or modify and sync collection remotes can configure remotes with both token and auth_url, particularly to arbitrary externally controlled servers. Also determine whether the same worker processes token-refresh requests for multiple remotes.
What is a mitigation if an update cannot be applied immediately?
Restrict the ability to configure or sync collection remotes that use token refresh, and prevent such remotes from targeting attacker-controlled or untrusted servers. Reducing shared-worker use for multiple token-refresh remotes also limits the condition in which one remote receives another remote's token.