CVE-2026-54548: kas Setup Tool SSH Configuration Vulnerability

CVE-2026-54548 Overview

CVE-2026-54548 affects kas, a setup tool for BitBake-based projects used in Yocto and OpenEmbedded builds. Versions prior to 5.4 disable SSH host key verification globally when SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE is set. The ssh_no_host_key_check() routine in kas/libcmds.py writes a Host * rule with StrictHostKeyChecking no into ~/.ssh/config without checking whether kas is running in a managed continuous integration (CI) environment. The setting persists after kas exits, weakening SSH security for all future connections by the same user. This creates a persistent man-in-the-middle (MITM) exposure classified as improper certificate validation [CWE-295].

Critical Impact
Persistent global disabling of SSH host key verification enables man-in-the-middle attacks against later SSH sessions on the affected user account.

Affected Products

Siemens kas versions prior to 5.4
Local developer environments where SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE is set
Systems without a pre-existing ~/.ssh/config file

Discovery Timeline

2026-08-26 - CVE-2026-54548 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-54548

Vulnerability Analysis

The kas tool automates SSH credential setup for BitBake project fetches. When SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE is present in the environment, kas initializes an SSH agent and calls ssh_no_host_key_check(). That function creates ~/.ssh/config if none exists and inserts a Host * block containing StrictHostKeyChecking no and UserKnownHostsFile /dev/null. The change was intended for ephemeral CI runners where host key trust cannot be pre-provisioned. In local developer environments the file persists after kas exits and applies to every subsequent SSH connection made by that user.

Root Cause

The root cause is missing environment context validation. The pre-patch code path in kas/libcmds.py invoked ssh_no_host_key_check() unconditionally without consulting ctx.managed_env, the flag that indicates a well-known CI environment. As a result, a design decision meant for short-lived containers propagated into persistent user configuration.

Attack Vector

Exploitation requires local access with the affected user's privileges to trigger the misconfiguration, followed by a network position enabling MITM interception. Once StrictHostKeyChecking no is present in ~/.ssh/config, an attacker able to intercept traffic to any SSH destination can present an arbitrary host key. The client accepts the key silently, exposing session confidentiality and integrity.

python

                raise RuntimeError('SSH setup requested but could '
                                   f'not find "{tool}" in PATH')
        ssh_setup_agent()
-        ssh_no_host_key_check()
+        # disabling host key checking is persistent and not limited to kas,
+        # hence only do it in externally managed environments
+        if ctx.managed_env:
+            ssh_no_host_key_check()


class CleanupSSHAgent(Command):

Source: GitHub Commit 1c1e861. The patch gates the call behind ctx.managed_env, limiting host key check suppression to recognized CI environments.

Detection Methods for CVE-2026-54548

Indicators of Compromise

Presence of ~/.ssh/config containing a Host * block with StrictHostKeyChecking no on a workstation that runs kas.
Recent modification timestamp on ~/.ssh/config correlated with a kas invocation that set SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE.
SSH client logs showing new or changed host keys accepted without prompts on user endpoints.

Detection Strategies

Audit user home directories for .ssh/config files matching the kas-generated template with global StrictHostKeyChecking no.
Review shell history and CI job logs for kas commands executed outside recognized CI environments with SSH key variables set.
Correlate known_hosts divergence and unexpected SSH connections to hosts that were not previously trusted.

Monitoring Recommendations

Monitor process creation events for kas binary invocation and capture the environment variables to identify at-risk hosts.
Alert on writes to ~/.ssh/config by non-interactive processes.
Track outbound SSH connections from developer endpoints for host key mismatches or connections to unexpected fetch mirrors.

How to Mitigate CVE-2026-54548

Immediate Actions Required

Upgrade kas to version 5.4 or later on all developer workstations and build hosts.
Inspect and remove any Host *StrictHostKeyChecking no block from ~/.ssh/config that was inserted by earlier kas versions.
Rotate SSH host trust by clearing untrusted entries from ~/.ssh/known_hosts and re-verifying fingerprints for critical Git and fetch endpoints.

Patch Information

The fix is delivered in kas release 5.4. The commit gates ssh_no_host_key_check() behind the ctx.managed_env check so only CI environments recognized by kas disable host key verification. See the GitHub Security Advisory GHSA-mv8m-v9v6-5f94 for vendor details.

Workarounds

Avoid setting SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE on local workstations and instead expose an external agent through SSH_AUTH_SOCK.
Pre-create ~/.ssh/config with strict settings before running kas so the tool does not modify it.
Restrict kas execution to container-based or ephemeral CI environments where user state is discarded after each run.

bash

# Verify no persistent host-key bypass remains after upgrade
grep -nE 'Host \*|StrictHostKeyChecking' ~/.ssh/config

# Remove the kas-inserted block, then re-secure the file
chmod 600 ~/.ssh/config

# Prefer forwarding an external agent instead of exporting a key
export SSH_AUTH_SOCK=/run/user/$(id -u)/ssh-agent.sock