Red Hat Satellite EUVD-2026-67003

Requires an authenticated session with at least low-privileged Content View permissions in any organization within the targeted Red Hat Satellite 6 instance - anonymous or unauthenticated access is insufficient. The Satellite instance must be configured with multiple organizations for the cross-tenant boundary violation to be meaningful; a single-organization deployment has no foreign filters to access. The attacker must supply a valid Content View Filter ID belonging to a different organization, which requires either prior knowledge, enumeration via predictable integer IDs, or lateral movement. Exploitation is strictly limited to Content View Filter Rule data - no system-level access, no RCE, and no impact outside Satellite's content management plane. Unpublished Content Views are the primary target; published views are read-only from the filter-rule perspective.

Real-world risk is moderate and context-dependent. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) accurately reflects that the attack is network-reachable, requires no special complexity or user interaction, but mandates a valid authenticated session with at least low-level Content View permissions. EPSS data was not provided in the source intelligence, limiting probabilistic exploitation assessment. No CISA KEV listing and no known POC further reduce urgency for most environments. The vulnerability only matters in multi-organization Satellite deployments - single-org environments have no cross-tenant boundary to cross. Even a small internal team managing several satellite organizations should treat this as a real integrity concern, since an attacker with any foothold account could silently tamper with another organization's unpublished Content View filter configuration, potentially introducing unreviewed packages into a patching pipeline before the Content View is published. That said, the S:U (unchanged scope) and absence of confidentiality or integrity impact beyond filter-rule metadata keeps this firmly in the Medium tier with no evidence of active exploitation pressure.

An attacker with a low-privileged account in Organization A - such as a developer or contractor with Content View read access - enumerates or guesses Content View Filter IDs from Organization B by probing the Content View Filter Rules API with sequential or known identifiers. Because the authorization check stops at the Content View permission boundary rather than the filter's organizational ownership, the API returns or accepts modifications to filter rules from Organization B, allowing the attacker to exfiltrate filter rule details or alter unpublished Content View filter configurations in a foreign organization without detection. No public POC exists at time of analysis, but the attack is mechanically straightforward for anyone familiar with REST API enumeration.