kas: Persistent SSH Host Key Checking Disablement
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| siemens | kas | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Siemens | Kas |
|
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-mv8m-v9v6-5f94 | kas Persistently Disables SSH Host Key Checking |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.112% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Siemens
Siemens kas |
|
| Vendors & Products |
Siemens
Siemens kas |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | kas: Persistent SSH Host Key Checking Disablement | |
| Weaknesses | CWE-295 | |
| References |
| |
| Metrics |
cvssV3_1
|