Pulp Ansible EUVD-2026-94171

Requires an authenticated user with permission to create or sync an Ansible collection remote (PR:L) in Pulp/AAP/Satellite, that remote must use bearer-token refresh, and the attacker must be able to point it at a server they control. The decisive condition is that another token download for a different remote must have run on the same worker process, populating the shared module-level token variable - without that, there is nothing to leak. Limiting factors: exploitation is confined to shared or multi-tenant deployments where multiple remotes use distinct tokens on the same worker; single-tenant or single-token setups have little to steal, and the dependency on concurrent/prior refresh activity means success is not fully attacker-controlled. No user interaction is required and only confidentiality of a token is affected.

This is a credible but moderate-priority issue, not a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) correctly models a network-reachable, low-privilege confidentiality-only flaw with no integrity or availability impact, which matches the description (content in Pulp is not altered and the service is not stopped). The real risk is credential disclosure: an authenticated tenant who can configure/sync a collection remote can harvest a bearer token that was obtained for a *different* remote because the token is cached in a single module-level variable shared across token downloads in that worker (CWE-488, exposure of a resource to the wrong session). No EPSS score, CISA KEV entry, POC reference, or SSVC decision was supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation - this is not a mass-exploitation candidate. One honest caveat: successful theft depends on another remote's token having populated the shared variable in the same worker, a timing/multi-tenant condition the attacker does not fully control, which argues for higher attack complexity than the AC:L in the input vector suggests; see assessed vector below. The attacker also needs legitimate privileges to create/sync remotes (PR:L), so impact is largely scoped to multi-tenant or shared-automation deployments where distinct remotes use distinct tokens.

In a multi-tenant Pulp/AAP deployment, a low-privileged but authorized user creates an Ansible collection remote that uses bearer-token refresh and points it at a server they control. When a sync runs on a worker that previously refreshed a token for another tenant's remote, the attacker's remote receives that other remote's access token and can replay it against the upstream service that issued it. No public POC is referenced, so this is a plausibility scenario rather than a demonstrated exploit.