CVE-2026-54548: Persistent SSH Host Key Checking Disablement in Siemens kas

The open-source setup and orchestration tool kas, developed by Siemens, is designed to configure and build BitBake-based projects, particularly within embedded Linux and Yocto Project environments. To retrieve code dependencies from private repositories, kas frequently manages SSH credentials and handles authentication key injection via environment variables. The attack surface centers on the utility's automated environment configuration routines, which operate with the privileges of the executing user on the host system.\n\nWhen processing SSH credentials, the tool seeks to prevent build pipelines from hanging on interactive host confirmation prompts. However, the mechanism implemented in vulnerable versions of kas alters global, persistent SSH configurations rather than restricting the change to an isolated session. This behavior introduces a persistent degradation of the host's security baseline, altering the cryptographic trust assumptions of the entire local user account.\n\nThe vulnerability, identified as CVE-2026-54548 and GHSA-mv8m-v9v6-5f94, represents an improper certificate and host validation flaw (CWE-295). It affects developers running kas directly on local workstations, leaving their future SSH transactions exposed to intercepting adversaries.

The root cause of CVE-2026-54548 lies in the implementation of the SSH initialization sequence in kas/libcmds.py. When a user specifies private keys using the SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE environment variables, kas executes an environment-provisioning sequence. This sequence includes a call to an internal function named ssh_no_host_key_check().\n\nThe ssh_no_host_key_check() function is designed to configure the SSH client to bypass interactive server validation prompts. If the invoking user does not have a pre-existing SSH configuration file located at ~/.ssh/config, the function dynamically instantiates this file. It then appends a global wildcard host configuration block:\n\ntext\nHost *\n StrictHostKeyChecking no\n\n\nThis directive instructs the OpenSSH client to automatically accept any host key presented by any remote server, bypassing the cryptographic verification of the remote host. Because the configuration is written to the persistent user home directory (~/.ssh/config) rather than an ephemeral environment or a temporary, process-specific config file, the security settings remain degraded long after the kas execution completes.

In vulnerable releases of kas, the SSH initialization routine unconditionally executes host key checking disablement regardless of the underlying environment. Below is the code diff highlighting the fix applied in version 5.4:\n\nudiff\nFile: kas/libcmds.py\n@@ -446,7 +446,10 @@ def execute(self, ctx):\n raise RuntimeError('SSH setup requested but could '\n f'not find "{tool}" in PATH')\n ssh_setup_agent()\n- ssh_no_host_key_check()\n+ # disabling host key checking is persistent and not limited to kas,\n+ # hence only do it in externally managed environments\n+ if ctx.managed_env:\n+ ssh_no_host_key_check()\n\n\nThe patched code introduces a context check using the ctx.managed_env property. This property evaluates whether the application is running within an externally managed and transient environment, such as a containerized CI/CD pipeline or a dedicated build runner. If ctx.managed_env is false (as is the case on a standard local workstation), the execution of ssh_no_host_key_check() is bypassed.\n\nThis modification represents a robust fix because it preserves the automation convenience required for automated pipelines while preventing local developer environments from being silently reconfigured. It addresses the core flaw by restricting the side-effect to environments that are expected to be destroyed after the build process completes.

Exploitation of this vulnerability is opportunistic and occurs in two phases: the environment-poisoning phase and the subsequent intercept phase. The attacker does not need to compromise the kas utility itself, but rather exploits the degraded state left behind by the tool.\n\nDuring the poisoning phase, a developer executes a vulnerable version of kas locally with SSH parameters configured. The tool silently creates or appends the wildcard configuration to ~/.ssh/config. At this stage, the workstation's SSH client is configured to blind-trust any server identity. This configuration persists across reboots and shells.\n\nmermaid\ngraph LR\n A["Developer Workstation"] -->|"1. Runs kas (creates config)"| B["~/.ssh/config (Poisoned)"]\n B -->|"2. Runs 'ssh git@github.com'"| C["Rogue Router / Spoofed DNS"]\n C -->|"3. Proxies connection without warning"| D["Attacker Server (MITM)"]\n\n\nIn the intercept phase, the victim executes a normal SSH command, such as syncing a Git repository over SSH. If the attacker is positioned on the same local area network (LAN), controls the local DNS, or has compromised a routing hop, they can redirect the traffic to a malicious SSH server. Because host key checking is disabled globally, the victim's SSH client connects to the attacker-controlled machine without displaying the standard security warning, enabling the attacker to harvest credentials or modify code payloads.

The CVSS 3.1 base score for this vulnerability is 3.3 (Low), reflecting the local execution vector and high complexity required to exploit the resulting vulnerability. The vulnerability itself does not allow direct remote code execution; rather, it degrades a fundamental transport security mechanism.\n\nThe practical risk in development teams remains significant. Software developers represent high-value targets. If a developer's workstation is modified to trust all SSH hosts, any subsequent access to corporate source code servers, production staging environments, or internal infrastructure becomes vulnerable to interception and active credential theft.\n\nFurthermore, because this configuration change is persistent, the vulnerability survives beyond the lifetime of the specific project that used kas. The system remains in an insecure state until the user manually inspects and fixes the configuration file, creating a long-term risk of exposure.

To detect if a developer workstation has been affected by this vulnerability, security administrators or users must inspect the local SSH configuration file.\n\nRun the following command to check for the global wildcard bypass:\n\nbash\ncat ~/.ssh/config 2>/dev/null | grep -A 2 "Host \*"\n\n\nIf the command returns StrictHostKeyChecking no under a global Host * rule and the user did not intentionally configure it, the configuration is poisoned. To remediate the environment, edit ~/.ssh/config to remove the insecure directives or delete the file entirely if it was created solely by kas:\n\nbash\nrm -f ~/.ssh/config\n\n\nThe primary mitigation is upgrading kas to version 5.4 or higher. This update restricts the disabling of host key verification to isolated, transient CI environments.