dbcve.org
PulpApplication · Pulpproject

CVE-2024-7143

HIGH · 8.3 CVSS v3.1 Published 2024-08-07
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
89/100
Remediation priority · High
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

In Pulp's RBAC implementation, when objects are created within tasks, the `AutoAddObjPermsMixin.add_roles_for_object_creator` method incorrectly identifies the object creator by checking the current authenticated user. For task contexts, this defaults to the first user with any permissions on the task object—specifically the oldest user with model/domain-level task permissions—rather than the actual user who dispatched the task. This causes all permissions on task-created objects to be incorrectly assigned to this oldest user instead of the real creator.

MitigationModify the task context user resolution to use the actual task dispatching user instead of the first user with task permissions, ensuring `add_roles_for_object_creator` correctly assigns permissions to the user who created the object.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
PulpApplication
Affected:all versions

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
Low

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify tasks that create objects in your Pulp instance
    Review your task history or Pulp logs to find tasks that created objects (content, repositories, or other resources). Note the task ID and the user who dispatched each task.
    Affected if You have tasks that created objects via task dispatching (this vulnerability only affects objects created within tasks, not objects created via direct API calls).
  2. Retrieve the task dispatcher for a sample task
    Use Pulp API or CLI to query the task details: `pulp task show <task-id>` or via API `GET /pulp/api/v3/tasks/<task-id>/`. Look for the 'created_by' or 'dispatching_user' field.
    Affected if The task has a 'created_by' or 'dispatching_user' field showing the actual user who dispatched the task.
  3. Check ownership/permissions on objects created by that task
    For the object created by the task (e.g., a repository, content, or other resource), query its permissions or ownership using Pulp API: `GET /pulp/api/v3/<resource-type>/<resource-uuid>/` and inspect the 'pulp_owner' field or role assignments.
    Affected if The object shows a 'pulp_owner' or has permissions assigned to a user other than the task dispatcher (specifically, to the oldest user with any task permissions).
  4. Compare dispatcher vs assigned owner
    Compare the user identified in step 2 (task dispatcher) with the user identified in step 3 (object owner/permissions). If they differ, the vulnerability is present.
    Affected if The object owner/permissions are assigned to a different user than the one who dispatched the task, this indicates the bug is active.

You are affected if you have created any objects through Pulp tasks and those objects have permissions assigned to a user other than the actual task dispatcher.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Modify the task context user resolution to use the actual task dispatching user instead of the first user with task permissions, ensuring `add_roles_for_object_creator` correctly assigns permissions to the user who created the object.

Fix this in Pulp Scoped from the published advisory
  • Consultation3.0 h
  • Implementation8.0 h
  • Testing6.0 h
  • Review / QA4.0 h
21.0 hours of engineering $3,660
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,856.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2024-7143 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2024-7143 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data