CVE-2026-54548: kas: Persistent SSH Host Key Checking Disablement
Summary
kas persistently disables SSH host key checking for the invoking user when internal SSH key setup is triggered via SSHPRIVATEKEY or SSHPRIVATEKEYFILE and no user-specific SSH configuration file exists so far.
When this path is used, kas creates ~/.ssh/config with a global Host rule containing StrictHostKeyChecking no. This was intended to ease the use of kas in short-lived CI environments that lack a pre-configured set of known hosts. In case a local user had no SSH configuration file so far, this approach weakens SSH host authenticity verification beyond the lifetime and scope of the kas command, increasing the risk of successful man-in-the-middle attacks against future SSH connections made by the same user.
Patches
Such SSH configurations were created since the very first public release. The issue is addressed now by commit <FILLME> which is part of kas version 5.4.
Workarounds
Since kas 2.6.3, a local user's SSH configuration is only written if it didn't exist before. From that version on, the issue can be avoided by creating an own ~/.ssh/config prior to calling kas. If kas was already called, ~/.ssh/config should be inspected and undesired settings created by kas should be removed.
Other sources
kas is a setup tool for bitbake based projects. Prior to 5.4, internal SSH key setup triggered by SSHPRIVATEKEY or SSHPRIVATEKEYFILE creates ~/.ssh/config when no user-specific SSH configuration exists and adds a global Host rule containing StrictHostKeyChecking no. In kas/libcmds.py, sshnohostkeycheck() runs without checking ctx.managedenv, so the setting persists after kas exits and affects future SSH sessions by the same local user, extending beyond the intended short-lived continuous integration environment. A later SSH connection can therefore accept an attacker-controlled host key without verification, increasing the risk of a man-in-the-middle attack that compromises session confidentiality or integrity. This issue is fixed in version 5.4.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/kasto a version that resolves this vulnerability.Fixed in 5.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 5.4 - Configuration
Inspect the invoking user's ~/.ssh/config after kas was called, and remove any undesired settings created by kas (e.g., the global 'Host *' rule with 'StrictHostKeyChecking no').
kas (internal SSH configuration via SSH_PRIVATE_KEY / SSH_PRIVATE_KEY_FILE) ~/.ssh/config Host * StrictHostKeyChecking = StrictHostKeyChecking no -> remove undesired settings created by kas - Configuration
Create an own ~/.ssh/config prior to calling kas, so kas does not write a global 'Host *' rule that disables SSH host authenticity verification.
kas (use of pre-created SSH config) ~/.ssh/config (existence) = Create ~/.ssh/config before calling kas to avoid kas creating a global Host * rule with 'StrictHostKeyChecking no'.
Event History
Frequently Asked Questions
Which users are exposed to the persistent configuration change?
The affected path applies when kas performs internal SSH key setup through SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE and the invoking user does not already have a ~/.ssh/config file. kas then creates a user-level configuration that can affect later SSH connections made by that same user.
What would an attacker need to take advantage of this condition?
An attacker would need an opportunity to perform a man-in-the-middle attack against a future SSH connection made by the affected user. The created Host * rule disables strict host-key checking globally for that user's SSH client.
Are installations with an existing SSH configuration affected by this behavior?
Since kas 2.6.3, kas writes the local SSH configuration only when ~/.ssh/config did not already exist. Creating an SSH configuration before running kas avoids this path on those versions.
What should be checked if kas has already been run?
Inspect ~/.ssh/config for a global Host * entry containing StrictHostKeyChecking no. This configuration should be reviewed because it weakens host authenticity verification beyond the kas invocation.
What version contains the fix?
The issue is addressed in kas version 5.4.