CVE-2024-7143 is a high severity (CVSS 8.3 in NVD) flaw in pulpcore, the core of the Pulp content repository. Objects created inside tasks get their permissions assigned to the wrong user. The pulpcore changelog lists fixes in 3.58.0, 3.57.1, 3.49.17, 3.39.20 and 3.28.32.
What's affected
The GitHub advisory GHSA-9m5j-4xx9-44j9 lists the pip package pulpcore at version 3.56.0 and earlier, and shows no patched version in its own metadata. The NVD record also lists Red Hat Ansible Automation Platform 2.0, which ships Pulp.
The fix versions come from the pulpcore changelog, where the same entry, "Fixed RBAC permissions being incorrectly assigned in tasks that create objects", appears under releases 3.58.0, 3.57.1, 3.49.17, 3.39.20 and 3.28.32. That covers several maintained branches. If you run another branch, check the changelog for the matching patch release. Red Hat's CVE page did not list fixed errata for specific products when we reviewed it, so check erratum RHSA-2024:6765 and your Red Hat subscription for packaged builds.
How to check if you're exposed
For a pip based install, run pip show pulpcore or pip list | grep pulpcore in the environment that runs Pulp. Compare the version to the patched releases for your branch.
For containerized or packaged installs, read the pulpcore version from the image or package metadata, and from the status endpoint of your Pulp API if you expose it to administrators.
Then look at behavior. Ask whether objects created by background tasks, such as repositories made through an API call that dispatches a task, ended up with permissions on an unexpected user. The oldest user holding model or domain level task permissions is the one to look at first.
You can also scan your Python manifests with the free in-browser dependency scan to see whether pulpcore appears in a build.
What to do now
- Upgrade pulpcore to a fixed release on your branch (3.58.0, 3.57.1, 3.49.17, 3.39.20 or 3.28.32, or later).
- Audit permissions on objects created by tasks since you deployed an affected version. Look for objects where the oldest task-permissioned user holds roles and the real creator holds none.
- Correct those role assignments by hand where the wrong user has access.
- Reduce the number of users with model or domain level task permissions, since the flaw hands new objects to that group.
- For Red Hat Ansible Automation Platform, apply the vendor errata referenced in RHSA-2024:6765.
Why it matters
The cause is CWE-277, insecure inherited permissions. Pulp finds the creator of a new object by looking at the current authenticated user. Inside a task, that current user is set by the first user with any permissions on the task object, which is the oldest user with model or domain level task permissions. So every object created in a task gets its permissions assigned to that one user, and the person who dispatched the task receives nothing.
Severity depends on who you ask. NVD scores it 8.3 (High, CVSS 3.1, privileges required low). Red Hat scores it 6.7 with privileges required high. The GitHub advisory shows 6.7 for CVSS 3.0, while its page also displays an 8.6 High CVSS 4.0 score. The sources agree on the weakness and differ on how much privilege an attacker needs.
Either way, the practical effect is a confidentiality and integrity problem: one user quietly owns things they did not create. The CVE is not in CISA's Known Exploited Vulnerabilities catalog, and none of the pages we read reports exploitation.
Quick check
Does the GitHub advisory name a patched version?
No. Its metadata lists affected versions up to 3.56.0 with no patched version. The fixed releases come from the pulpcore changelog.
Is there a workaround?
None of the advisory or Red Hat pages we read describe one. Upgrading is the fix, and fewer task-permissioned users limits the effect meanwhile.
Sources
- GitHub advisory GHSA-9m5j-4xx9-44j9
- Red Hat CVE page for CVE-2024-7143
- pulpcore changelog
- Safeguard Gold entry for CVE-2024-7143
Last reviewed: 19 October 2026.
