Red Hat Satellite CVE-2026-107151

Requires that Red Hat Satellite 6 remote execution be configured in 'pull' or 'pull-mqtt' mode - this specific deployment mode is a hard precondition; the default push (SSH) mode is not stated to be affected. The attacker must additionally already know the identifier of a currently running remote-execution job and submit the forged progress/completion callback during that job's execution window. No authentication or one-time token is needed because the callback handler accepts the report when the token is missing (CWE-306), and no user interaction is required. Limiting factors that reduce real-world risk: the non-default pull/pull-mqtt configuration dependency, the need to know a valid live job ID, and the narrow timing window, all reflected in CVSS AC:H.

This is a moderate-severity integrity issue, not a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, base 5.9) is internally consistent with the description: network-reachable (AV:N), unauthenticated (PR:N), but high attack complexity (AC:H) because the attacker must already know the identifier of a specific running job and act within its execution window, and the only impact is integrity (I:H) - falsifying job output/status - with no confidentiality or availability loss. Exploitation status is 'no public exploit identified at time of analysis': there is no CISA KEV listing, no POC reference, and no EPSS score in the provided data, so exploitation probability cannot be quantified from the inputs. The realistic risk is targeted tampering with automation/audit results rather than mass exploitation - a network attacker who knows a job ID can make a remote-execution job falsely report success or failure, which undermines operational trust and audit integrity but does not directly grant code execution or data access. Conflicting/limiting signal to note explicitly: CVSS says AV:N and PR:N (sounds broadly remotely exploitable), but the description's requirement to know a live job identifier plus the pull/pull-mqtt-mode precondition materially narrow real-world exploitability - this is the AC:H factor and should temper the raw 5.9 score downward for most deployments.

In an environment where remote execution runs in pull or pull-mqtt mode, an attacker who has learned the identifier of an in-flight job sends a crafted progress/completion callback to the smart_proxy_dynflow endpoint without the required one-time token. Because the token is not enforced, the proxy accepts the attacker-supplied output and records the job as succeeded or failed per the attacker's choice. No public exploit code is identified at time of analysis, but the technique is straightforward for someone with network reachability and knowledge of a valid job ID.