GHSA-MV8M-V9V6-5F94
Vulnerability from github – Published: 2026-08-26 14:18 – Updated: 2026-08-26 14:18Summary
kas persistently disables SSH host key checking for the invoking user when internal SSH key setup is triggered via SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE 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 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.3"
},
"package": {
"ecosystem": "PyPI",
"name": "kas"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54548"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-26T14:18:24Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nkas persistently disables SSH host key checking for the invoking user when internal SSH key setup is triggered via `SSH_PRIVATE_KEY` or `SSH_PRIVATE_KEY_FILE` and no user-specific SSH configuration file exists so far.\n\nWhen 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.\n\n### Patches\n\nSuch SSH configurations were created since the very first public release. The issue is addressed now by commit \u003cFILLME\u003e which is part of kas version 5.4.\n\n### Workarounds\n\nSince kas 2.6.3, a local user\u0027s SSH configuration is only written if it didn\u0027t 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.",
"id": "GHSA-mv8m-v9v6-5f94",
"modified": "2026-08-26T14:18:24Z",
"published": "2026-08-26T14:18:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siemens/kas/security/advisories/GHSA-mv8m-v9v6-5f94"
},
{
"type": "WEB",
"url": "https://github.com/siemens/kas/commit/1c1e861c9f241ce082b86bef6bedc7da9b676294"
},
{
"type": "PACKAGE",
"url": "https://github.com/siemens/kas"
},
{
"type": "WEB",
"url": "https://github.com/siemens/kas/releases/tag/5.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "kas Persistently Disables SSH Host Key Checking"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.