CVE-2026-54548
LowCVSS 3.3Summary
kas, a setup tool for bitbake based projects, prior to 5.4, internal SSH key setup triggered by SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE creates ~/.ssh/config when no user-specific SSH configuration exists and adds a global Host * rule containing StrictHostKeyChecking no. In kas/libcmds.py, ssh_no_host_key_check() runs without checking ctx.managed_env, 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.
Risk Assessment
Increased risk of man-in-the-middle attacks on user SSH sessions, which could compromise confidentiality and integrity of transmitted data.
Recommendation
Update kas to version 5.4 or later. After updating, remove or fix entries in ~/.ssh/config to avoid dangerous rules.
Other vulnerabilities in kas
See all- CVE-2026-47192Low
kas is a setup tool for bitbake based projects. In versions from 4.8 to before 5.3, kas checks out and processes repositories and configuration includes prior to validating signatures of those repositories. Under very specific conditions, this may allow an attacker to replace the original repository with one under their control.
- CVE-2026-47191Low
kas is a setup tool for bitbake based projects. Prior to version 5.3, when relying solely on a git commit ID (SHA-1 or SHA-256) to verify repository integrity, users may be tricked into checking out a branch of the same name from a compromised repository. This primarily affects SHA-256 commit IDs, as SHA-1 may be vulnerable to hash collisions.
Original NVD description (English source)
kas is a setup tool for bitbake based projects. Prior to 5.4, internal SSH key setup triggered by SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE creates ~/.ssh/config when no user-specific SSH configuration exists and adds a global Host * rule containing StrictHostKeyChecking no. In kas/libcmds.py, ssh_no_host_key_check() runs without checking ctx.managed_env, 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.