Skip to main content
CVE-2024-7143VulnerabilityPublished Updated

CVE-2024-7143: Insecure Inherited Permissions

Source CVE Database V5

0

Not known to be exploited · CVSS 6.7 Medium.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 3.0 base score
6.7Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.6% chance of exploitation in 30 days – higher than 48% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 7 Aug 2024

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

AI-suggested

An official fix is available from Red Hat. Users should apply the updates provided in Red Hat Ansible Automation Platform 2.4, specifically automation-controller version 4.5.11 and python3-pulpcore version 3.28.32 or later, as detailed in Red Hat advisory RHSA-2024:6765. Applying these updates will correct the RBAC permission assignment behavior. No additional mitigation steps are indicated by the vendor advisory.

Description

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.

References

Community reviews

Loading reviews…