Skip to main content
Press slash or control plus K to focus the search. Use the arrow keys to navigate results and press enter to open a threat.
Reconnecting to live updates…

CVE-2024-4871: Key Exchange without Entity Authentication

0
Medium
VulnerabilityCVE-2024-4871cvecve-2024-4871
Published: Tue May 14 2024 (05/14/2024, 14:27:41 UTC)
Source: CVE Database V5

Description

A vulnerability was found in Satellite. When running a remote execution job on a host, the host's SSH key is not being checked. When the key changes, the Satellite still connects it because it uses "-o StrictHostKeyChecking=no". This flaw can lead to a man-in-the-middle attack (MITM), denial of service, leaking of secrets the remote execution job contains, or other issues that may arise from the attacker's ability to forge an SSH key. This issue does not directly allow unauthorized remote execution on the Satellite, although it can leak secrets that may lead to it.

AI-Powered Analysis

AILast updated: 11/20/2025, 19:45:44 UTC

Technical Analysis

CVE-2024-4871 identifies a security weakness in Satellite version 3.9.1.8 related to SSH host key verification during remote execution jobs. Satellite connects to hosts via SSH to run commands remotely, but due to the use of the SSH option '-o StrictHostKeyChecking=no', it does not verify if the host's SSH key has changed. This omission disables the standard SSH mechanism that prevents connecting to a host with an unexpected or forged key, which is critical for authenticating the remote host's identity. Consequently, an attacker positioned to intercept or manipulate network traffic can perform a man-in-the-middle (MITM) attack by presenting a forged SSH key. This can lead to several security consequences: interception or modification of commands and data sent during remote execution, leakage of sensitive secrets contained within these jobs, and potential denial of service by disrupting trusted connections. Although the vulnerability does not directly allow unauthorized remote code execution on Satellite itself, the exposure of secrets could enable attackers to escalate privileges or compromise other systems. The vulnerability requires low privileges on the Satellite system but no user interaction, and the attack vector is network-based. The CVSS v3.1 score of 6.8 reflects the high impact on confidentiality and integrity, moderate attack complexity, and the lack of availability impact. No known exploits are currently reported in the wild, but the risk remains significant due to the nature of SSH key trust bypass.

Potential Impact

For European organizations, the impact of CVE-2024-4871 can be substantial, especially those relying on Satellite 3.9.1.8 for managing infrastructure and executing remote jobs. The vulnerability undermines the trust model of SSH connections, potentially exposing sensitive operational secrets such as credentials, configuration data, or proprietary scripts. This exposure can facilitate lateral movement within networks, privilege escalation, or data exfiltration. Additionally, MITM attacks could disrupt critical management operations, leading to denial of service or operational delays. Organizations in regulated sectors (e.g., finance, healthcare, government) face increased compliance risks due to potential data breaches. The medium severity rating indicates a moderate but non-negligible threat that requires timely remediation to prevent exploitation. The absence of direct remote code execution reduces immediate risk but does not eliminate the threat of indirect compromise through leaked secrets.

Mitigation Recommendations

To mitigate CVE-2024-4871, European organizations should: 1) Upgrade Satellite to a patched version where SSH host key verification is properly enforced, as soon as a fix is available. 2) If immediate patching is not possible, manually configure SSH client options used by Satellite to enable strict host key checking by removing or overriding '-o StrictHostKeyChecking=no'. 3) Implement network-level protections such as SSH bastion hosts or jump servers with strict key management policies to reduce exposure to MITM attacks. 4) Monitor SSH connection logs for unexpected host key changes or anomalies indicating potential MITM attempts. 5) Rotate any secrets or credentials used in remote execution jobs to limit the impact of potential leaks. 6) Employ network segmentation and zero-trust principles to restrict access to Satellite-managed hosts. 7) Educate administrators about the risks of disabling SSH host key verification and enforce secure SSH configurations across infrastructure. These steps go beyond generic advice by focusing on configuration hardening, operational monitoring, and credential hygiene specific to the Satellite environment.

Need more detailed analysis?Upgrade to Pro Console

Technical Details

Data Version
5.2
Assigner Short Name
redhat
Date Reserved
2024-05-14T14:03:36.786Z
Cvss Version
3.1
State
PUBLISHED

Threat ID: 691f6d0840b920e2708759bb

Added to database: 11/20/2025, 7:33:28 PM

Last enriched: 11/20/2025, 7:45:44 PM

Last updated: 1/7/2026, 4:17:44 AM

Views: 55

Community Reviews

0 reviews

Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.

Sort by
Loading community insights…

Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.

Actions

PRO

Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.

Please log in to the Console to use AI analysis features.

Need more coverage?

Upgrade to Pro Console in Console -> Billing for AI refresh and higher limits.

For incident response and remediation, OffSeq services can help resolve threats faster.

Latest Threats