Red Hat Satellite CVE-2026-5135

Authentication with a low-privilege account is required - specifically, the target account must hold the host-edit permission within Foreman/Satellite. The exploitation mechanism relies on manipulating the match field of a lookup value override via nested host attributes in the API request, meaning the attacker must have at least one existing lookup value override to retarget (or the ability to create one). The vulnerability is most impactful in multi-organization or multi-location Satellite deployments where organizational boundaries are used as an access control boundary. Single-organization deployments with uniform host-edit grants across all administrators experience reduced marginal impact since the boundary being crossed may not represent a meaningful trust separation. Exploitation does not require administrative (PR:H) access, special network positioning beyond standard HTTPS connectivity to the Satellite server, or any victim interaction.

The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) reflects a network-accessible, low-complexity exploit requiring only low-privilege authentication with no user interaction, producing high integrity impact but no confidentiality or availability loss. This vector is internally consistent with the description: any user who holds a standard host-edit role can mount the attack remotely. The S:U (scope unchanged) designation is the most notable limiting factor - the CVSS model constrains blast radius to within the vulnerable component's authorization domain, yet the description explicitly states cross-organizational and cross-location boundary violations occur, suggesting the practical impact may exceed what S:U implies. No EPSS data was supplied, but the absence of both a public exploit and KEV listing indicates no confirmed widespread opportunistic exploitation. Real-world priority is moderate: organizations running multi-tenant Satellite deployments with strict organizational separation (e.g., managed service providers, large enterprises with delegated admin models) face meaningful risk of privilege escalation across trust boundaries, while single-org deployments with uniform host-edit policies face lower marginal risk.

An authenticated Red Hat Satellite user assigned a host-edit role within Organization A crafts an API request that modifies the match field of an existing smart variable lookup value override using nested host attributes referencing a host in Organization B. The server's authorization check validates the user's host-edit permission but fails to verify that the resolved target host falls within the user's permitted organizational scope, silently applying the override to the out-of-scope host. This allows the attacker to push arbitrary configuration values - such as altered Puppet class parameters or smart variable assignments - to hosts they should not control, potentially modifying security settings, credentials, or application configurations on those systems. No public proof-of-concept has been identified, but the attack is straightforward for any user already familiar with the Foreman/Satellite API.