Pulp before 2.3.0 uses the same the same certificate authority key and certificate for all installations.

The Qpid server on Red Hat Satellite 6 does not properly restrict message types, which allows remote authenticated users with administrative access on a managed content host to execute arbitrary code via a crafted message, related to a pickle processing problem in pulp.

pulp-consumer-client 2.4.0 through 2.6.3 does not check the server's TLS certificate signatures when retrieving the server's public key upon registration.

server/bin/pulp-gen-ca-certificate in Pulp before 2.8.2 allows local users to read the generated private key.

Pulp before 2.8.3 creates a temporary directory during CA key generation in an insecure manner.

The Node certificate in Pulp before 2.8.3 contains the private key, and is stored in a world-readable file in the "/etc/pki/pulp/nodes/" directory, which allows local users to gain access to sensitive data.

The pulp-gen-nodes-certificate script in Pulp before 2.8.3 allows local users to leak the keys or write to arbitrary files via a symlink attack.

pulp.spec in the installation process for Pulp 2.8.3 generates the RSA key pairs used to validate messages between the pulp server and pulp consumers in a directory that is world-readable before later modifying the permissions, which might allow local users to read the generated RSA keys via reading the key files while the installation process is running.

client/consumer/cli.py in Pulp before 2.8.3 writes consumer private keys to etc/pki/pulp/consumer/consumer-cert.pem as world-readable, which allows remote authenticated users to obtain the consumer private keys and escalate privileges by reading /etc/pki/pulp/consumer/consumer-cert, and authenticating as a consumer user.

The pulp-qpid-ssl-cfg script in Pulp before 2.8.5 allows local users to obtain the CA key.

Pulp before 2.8.5 uses bash's $RANDOM in an unsafe way to generate passwords.

In Pulp before version 2.16.2, secrets are passed into override_config when triggering a task and then become readable to all users with read access on the distributor/importer. An attacker with API access can then view these secrets.

pulp 2.16.x and possibly older is vulnerable to an improper path parsing. A malicious user or a malicious iso feed repository can write to locations accessible to the 'apache' user. This may lead to overwrite of published content on other iso repositories.

The collection remote for pulp_ansible stores tokens in plaintext instead of using pulp's encrypted field and exposes them in read/write mode via the API () instead of marking it as write only.

A flaw was found in the Pulp package. When a role-based access control (RBAC) object in Pulp is set to assign permissions on its creation, it uses the `AutoAddObjPermsMixin` (typically the add_roles_for_object_creator method). This method finds the object creator by checking the current authenticated user. For objects that are created within a task, this current user is set by the first user with any permissions on the task object. This means the oldest user with model/domain-level task permissions will always be set as the current user of a task, even if they didn't dispatch the task. Therefore, all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.