A flaw was found in pulp-rpm when it publishes a distribution tree. Addon and variant ids from .treeinfo are used as directory names. A user who can sync or upload that tree can make the publish task create a new directory outside the task work area and write that tree's repository metadata and packages there, as the Pulp worker user. An existing file or directory is not replaced. The flaw does not disclose data and does not stop the service.

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.

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.

RegistryAuthHttpDownloader.registryauth is a class attribute (pulpcontainer/app/downloaders.py). Every instance in the worker shares one basic-auth value and one bearer token. A later download in that process, including another remote, task, or domain, sends the Authorization header stored by an earlier authenticated sync. Remote username, password, and clientkey are write-only on the API, so the syncing account cannot read them back. The caller obtains them by pointing a remote they can sync at a server they control. Introduced in dbef26e7, first release 1.3.0. This is a separate CVE from the pulp-ansible token cache: different repository, independently fixable.

A path traversal vulnerability was found in pulpcore. The content upload API accepts a 'fileurl' parameter that allows users with file repository privileges to specify a local file URL for Pulp to download and store. A URL scheme validation check uses a string prefix comparison that only rejects URLs beginning with 'file://', but Python's URL parser recognizes the 'file:' scheme without double slashes, creating a mismatch between what is validated and what is dispatched to the file downloader. An authenticated user with low-privilege repository permissions can supply a specially crafted URL using relative path traversal sequences to read any file accessible to the Pulp server process. In deployments that include Pulp Container, successful exploitation allows an attacker to read the container registry token signing private key and forge bearer tokens, granting unauthorized access to all private container repositories in the affected registry.

A path traversal vulnerability was found in pulpcore's relativepathvalidator (pulpcore/app/serializers/fields.py). The validator only checks os.path.isabs() to block paths starting with "/", but does not block "../" directory traversal sequences anywhere in the path.

When a user creates content via POST /api/v3/content/file/files/ with a crafted relativepath (e.g., "looking/normal/../../../../etc/cron.d/backdoor"), the value passes validation and is stored in ContentArtifact.relativepath. During FilesystemExport (pulpcore/app/tasks/export.py), os.path.join(path, relativepath) resolves outside the export directory, and the raw artifact content (fully attacker-controlled) is written to the escaped path.

The process runs as the "pulp" system user. File permission bits cannot be set by the attacker. FilesystemExport is only accessible to admin-level users (SSL cert auth in Satellite, admin role in RBAC deployments).

Affected: pulpcore (all versions through current HEAD 3.110.0.dev) Fix: Not yet available (coordinating with upstream) Reporter: Martin Brodeur (independent security researcher) PSIRT Ticket: PSIRTSUPT-7617

Hi, From [2]: #### CVE-2024-7923: Authentication bypass in Pulpcore An authentication bypass vulnerability has been identified in Pulpcore when deployed by the Foreman Installer with Gunicorn versions prior to 22.0. This issue arises from the way Apache is configured to do certificate authentication and pass this information to the Gunicorn backend, without unsetting all headers coming from a possibly malicious client. Affects Katello 4.0.0 and higher Fix released in Foreman 3.10.1, 3.11.2, 3.12.0 GitHub PR puppet-pulpcore#357 #### CVE-2024-7012: Authentication bypass in Foreman An authentication bypass vulnerability has been identified in Foreman when deployed by the Foreman Installer with External Authentication. This issue arises from the way Apache is configured to do certificate authentication and pass this information to the Puma backend, without unsetting all headers coming from a possibly malicious client. Affects Foreman 2.2.0 and higher Fix released in Foreman 3.10.1, 3.11.2, 3.12.0 GitHub PR puppet-foreman#1181 Further References: [1] https://community.theforeman.org/t/foreman-3-11-2-is-now-available/39370 [2] https://theforeman.org/security.html#2024-7923 [3] https://access.redhat.com/security/cve/CVE-2024-7012 [4] https://access.redhat.com/security/cve/CVE-2024-7923 https://projects.theforeman.org/issues/37786?tab=changesets https://projects.theforeman.org/issues/37787?tab=changesets

Kind regards, Christian

When an RBAC object in Pulp is set to assign perms on its creation it uses the AutoAddObjPermsMixin, typically the method addrolesforobjectcreator. 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 perms on the task object. This means the oldest user with model/domain-level task perms will always be set to the current user of a task even if they didn't dispatch the task. Thus all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.

A flaw was found in pulp 2.16.x and possibly older. 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.

It was found that spec file generating RSA keys, used for authenticating messages between server and consumers, as post installation step does this in world-readable directories for a brief moment.

Vulnerable code:

https://github.com/pulp/pulp/blob/master/pulp.spec#L473-L486 https://github.com/pulp/pulp/blob/master/pulp.spec#L894-L903

It was found that newly generated CA keys by running pulp-gen-ca-certificate (which is run by spec file when pulp is installed) script are insufficiently protected against reading by other users for the time the script runs.

Vulnerable code:

https://github.com/pulp/pulp/blob/2.8.0/server/bin/pulp-gen-ca-certificate

It is reported by Austin Macdonald that pulp fails to properly remove existing permissions when an object is deleted (e.g. a user account), if an object with the same name is later created it will inherit the previous permissions leading to a potential privilege escalation. Please note that due to the manner in which pulp is used in Satellite6 it is not vulnerable.