Red Hat Satellite EUVD-2026-97235

Exploitation requires an authenticated Foreman/Satellite 6 account that has already been granted permission to delete permission filters for at least one role (PR:L); a fully unprivileged or anonymous user cannot trigger it. The attacker then abuses the filter-lookup-by-identifier API path, which fails to re-apply the caller's permission search limit, to delete filters belonging to OTHER roles. Limiting factors: the targeted roles must be 'unlocked' (locked roles are not affected), and the caller must already hold filter-delete rights in some scope, so this is primarily an insider/compromised-semi-privileged-account vector rather than a default-configuration remote-unauthenticated issue.

This is a genuine but moderate-priority authorization flaw (CWE-639, Insecure Direct Object Reference) in Foreman's permission-filter API, as shipped in Red Hat Satellite 6. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N = 6.5 Medium) is internally consistent with the description: network-reachable, low complexity, no user interaction, but requiring an already-authenticated low-privileged account (PR:L) that has been granted delete rights on at least one role's filters. The impact is purely integrity (I:H) - unauthorized deletion of other roles' filters - with no confidentiality or availability metric set, though in practice destroying filters can degrade legitimate users' access. Signals are limited: no EPSS score was provided, this is NOT on CISA KEV, and no public POC is referenced, so there is no evidence of active or widespread exploitation. The requirement for a pre-existing authenticated, partially-privileged account substantially lowers real-world risk versus the raw network attack vector; this reads as a privilege-boundary/IDOR bug exploitable by semi-trusted insiders or compromised low-tier accounts rather than an anonymous internet-facing threat. Treat it as a standard-cadence patch priority, not an emergency.

A user who has been delegated permission to manage (delete) permission filters for a single role authenticates to the Foreman/Satellite API, then supplies the identifier of a filter belonging to a different, unlocked role. Because the API loads the filter by ID without re-applying the caller's permission scope, the deletion succeeds and the other role silently loses the access that filter granted. No public exploit code is referenced, and exploitation requires an existing low-privileged account.