GPU VulnDB

Database/Control plane, storage & DevOps

pulp-ansible: collection remote token stored per worker leaks to an attacker-controlled remote

CVSS 6.5CVE-2026-103869Control plane, storage & DevOpscurated

Impact

pulp-ansible keeps the refreshed access token for collection remotes in a single module-level variable shared by every token download in a worker process. A user allowed to sync an Ansible remote, pointing it at a server they control, receives a token that was issued for a different remote and can replay it against the service that issued it. For an operator running Red Hat Satellite or Ansible Automation Platform as the fleet's content and configuration plane, that is credential disclosure for upstream content services - the credentials used to pull the collections that configure GPU nodes. Content already in Pulp is not modified and the service keeps running, so there is no availability impact to schedule around.

Who can reach it

Authenticated user with permission to create or edit an Ansible collection remote in Pulp (via Satellite or AAP) and the ability to point it at a host they control. No access to the host or to the victim remote's credentials is needed.

What to do

Apply the Red Hat updates for Ansible Automation Platform 2 and Satellite 6 as they ship (the record gives no fixed package versions - track the Red Hat CVE page) and restart the Pulp workers, since the leaked state lives in worker process memory. Meanwhile, restrict who may create or modify Ansible remotes to trusted operators, and rotate any upstream collection tokens that untrusted users could have had sync rights over.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.