Foreman Ansible CVE-2026-92894

Requires an authenticated Red Hat Satellite 6 / Foreman account holding the edit_ansible_variables permission, running the foreman_ansible plugin. The core weakness is that the override-values destroy action resolves the LookupValue by ID alone without checking that it belongs to an AnsibleVariable within the caller's permission-filter scope, so the limiting factor is that the attacker must already have variable-edit rights and knowledge/enumeration of target record IDs. Impact is confined to deletion of override values (including Puppet smart-class-parameter overrides) - no read access or code execution. In deployments where all Ansible-variable editors are fully trusted and there are no RBAC scope filters, the practical risk is minimal.

This is a low-to-moderate authorization/IDOR flaw (CWE-863), not a high-severity issue. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) is internally consistent with the description: exploitation requires an authenticated user who already holds the edit_ansible_variables permission (PR:L), and impact is limited to integrity (I:L) via unauthorized deletion of LookupValue override records - there is no confidentiality (C:N) or availability (A:N) impact and no scope change (S:U). No EPSS score, KEV listing, POC, or SSVC data is provided; per the precision rules, exploitation status is 'no public exploit identified at time of analysis.' All signals point to a genuine but bounded privilege-boundary/permission-filter bypass rather than a widely weaponizable vulnerability: an attacker must first obtain a legitimate Satellite/Foreman account with variable-edit rights, and the payoff is deleting override values (including ones outside their filter scope and Puppet smart-class-parameter overrides) rather than reading data or gaining code execution. This is a real hardening priority for multi-tenant/RBAC-segmented Satellite deployments but should be prioritized below remote-unauth or RCE-class findings.

In a Red Hat Satellite / Foreman environment with role-based permission filters, a low-privileged operator granted edit_ansible_variables (scoped to only their own organization's Ansible variables) enumerates LookupValue record IDs and issues destroy requests for override values belonging to variables outside their filter scope - or to Puppet smart class parameters they should never touch. No public exploit is identified; the attack is a straightforward authenticated API call against a predictable integer record ID.