CWE-322
AllowedKey Exchange without Entity Authentication
Abstraction: Base · Status: Draft
The product performs a key exchange with an actor without verifying the identity of that actor.
50 vulnerabilities reference this CWE, most recent first.
GHSA-G9V5-GJWF-9RWX
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-30 16:53Apache Airflow providers-google's ComputeEngineSSHHook disables SSH host-key verification by default, exposing SSH traffic between an Airflow worker and a Compute Engine VM to in-path network attackers who can intercept or modify the session. Users are advised to upgrade to apache-airflow-providers-google 22.0.0 or later.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "apache-airflow-providers-google"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "22.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45361"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T16:53:05Z",
"nvd_published_at": "2026-05-25T10:16:15Z",
"severity": "HIGH"
},
"details": "Apache Airflow providers-google\u0027s `ComputeEngineSSHHook` disables SSH host-key verification by default, exposing SSH traffic between an Airflow worker and a Compute Engine VM to in-path network attackers who can intercept or modify the session. Users are advised to upgrade to `apache-airflow-providers-google` 22.0.0 or later.",
"id": "GHSA-g9v5-gjwf-9rwx",
"modified": "2026-06-30T16:53:05Z",
"published": "2026-05-26T13:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45361"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/pull/66746"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/commit/120dbed3462cedcb980aac022c587ba434249eb1"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/airflow"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-airflow-providers-google/PYSEC-2026-166.yaml"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/3lpj7ppwxp7jtp81rnxk75xvln7qd7h2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/24/9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache Airflow providers-google\u0027s `ComputeEngineSSHHook` disables SSH host-key verification by default"
}
GHSA-HQVF-45JJ-MCCQ
Vulnerability from github – Published: 2026-08-06 20:15 – Updated: 2026-08-06 20:15Summary
The AWS Command Line Interface (AWS CLI) is a unified tool to manage AWS services from the command line. An issue exists where the EMR SSH helper commands (aws emr ssh, aws emr socks, aws emr put, aws emr get) passed StrictHostKeyChecking=no to the underlying SSH client, disabling host key verification.
Impact
A network-positioned actor could perform a man-in-the-middle action to intercept SSH sessions and file transfers between the client and EMR cluster instances. Successful exploitation requires the actor to have network access on the path between the client machine and the EMR cluster endpoint. This could result in full visibility of commands executed, files transferred, and credentials passed over the SSH session.
Impacted versions: AWS CLI v1 <= 1.45.27, AWS CLI v2 <= 2.35.2
Patches
This issue has been addressed in AWS CLI v1 version 1.45.28 and AWS CLI v2 version 2.35.3. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
There is no workaround. The insecure SSH option was hardcoded and could not be overridden by the user.
References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Acknowledgement
We would like to thank Ali Sunbul for collaborating on this issue through the coordinated vulnerability disclosure process.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.45.27"
},
"package": {
"ecosystem": "PyPI",
"name": "awscli"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.45.28"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-18654"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T20:15:30Z",
"nvd_published_at": "2026-08-03T20:17:17Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe AWS Command Line Interface (AWS CLI) is a unified tool to manage AWS services from the command line. An issue exists where the EMR SSH helper commands (`aws emr ssh`, `aws emr socks`, `aws emr put`, `aws emr get`) passed `StrictHostKeyChecking=no` to the underlying SSH client, disabling host key verification.\n\n### Impact\nA network-positioned actor could perform a man-in-the-middle action to intercept SSH sessions and file transfers between the client and EMR cluster instances. Successful exploitation requires the actor to have network access on the path between the client machine and the EMR cluster endpoint. This could result in full visibility of commands executed, files transferred, and credentials passed over the SSH session.\n\nImpacted versions: AWS CLI v1 \u003c= 1.45.27, AWS CLI v2 \u003c= 2.35.2\n\n### Patches\nThis issue has been addressed in AWS CLI v1 version 1.45.28 and AWS CLI v2 version 2.35.3. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.\n\n### Workarounds\nThere is no workaround. The insecure SSH option was hardcoded and could not be overridden by the user.\n\n### References\nIf you have any questions or comments about this advisory, we ask that you contact AWS Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n### Acknowledgement\nWe would like to thank Ali Sunbul for collaborating on this issue through the coordinated vulnerability disclosure process.",
"id": "GHSA-hqvf-45jj-mccq",
"modified": "2026-08-06T20:15:30Z",
"published": "2026-08-06T20:15:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-cli/security/advisories/GHSA-hqvf-45jj-mccq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18654"
},
{
"type": "WEB",
"url": "https://aws.amazon.com/security/security-bulletins/2026-071-aws"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-cli"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-cli/blob/develop/CHANGELOG.rst"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-cli/blob/v2/CHANGELOG.rst"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AWS CLI: Disabled SSH host key verification in Amazon AWS CLI EMR helper commands"
}
GHSA-MXG3-432P-MR72
Vulnerability from github – Published: 2026-05-15 17:17 – Updated: 2026-05-15 17:17Summary
The --tunnel / -t flag opens an outbound SSH connection to localhost.run:22 with HostKeyCallback: ssh.InsecureIgnoreHostKey(). The Go documentation for that function states verbatim: "It should not be used for production code." With the callback disabled the client accepts any host key the server presents, so an attacker who can intercept the operator's TCP connection to localhost.run:22 (any router on the path, malicious local network, ARP/DNS spoof on the operator's LAN, BGP hijack, malicious VPN) can present their own SSH host key, terminate the SSH session locally, and proxy onward — sitting transparently in the middle of the tunnel.
Because localhost.run does TLS termination at their end, the HTTP traffic on the SSH leg is plaintext, so the on-path attacker reads and rewrites every request and response in cleartext. The goshs operator gets no warning; the public URL works normally.
Affected Code
File: tunnel/tunnel.go
func Start(localIP string, localPort int) (*Tunnel, error) {
config := &ssh.ClientConfig{
User: "nokey",
Auth: []ssh.AuthMethod{ssh.Password("")},
HostKeyCallback: ssh.InsecureIgnoreHostKey(), // accepts any server key
Timeout: 10 * time.Second,
BannerCallback: func(banner string) error { return nil },
}
client, err := ssh.Dial("tcp", "localhost.run:22", config)
...
}
There is no fallback verification — no ssh.FixedHostKey, no known_hosts read, no TOFU pin. Every invocation of goshs --tunnel is equally vulnerable.
Exploit Chain
- Operator runs
goshs --tunnel.tunnel.Start()opens an SSH client tolocalhost.run:22withInsecureIgnoreHostKey(). - Attacker positioned on the network path (compromised router, café Wi-Fi MITM, malicious VPN exit, hostile ISP, BGP hijack, or
arpspoof+ DNS spoof on the operator's LAN) intercepts the outbound TCP connection tolocalhost.run:22and answers with their own SSH server. - The attacker's fake SSH server presents an attacker-generated host key. The goshs client's
HostKeyCallbackreturns nil unconditionally. Handshake completes; the client believes it is talking tolocalhost.run. - The attacker proxies the SSH session onward to the real
localhost.run:22, forwarding the URL capture soStart()reads back the genuinehttps://*.lhr.lifeline and returns successfully. The operator sees the public URL printed to stdout exactly as expected. - Every HTTP request arriving at the public URL is routed over the SSH session. The attacker reads every URL, query string, header, body, and
Authorizationvalue sent by every visitor. - For each response the attacker can rewrite the body or headers — serving modified files, injecting HTML/JS, redirecting requests, or stripping
Set-Cookieattributes. - Captured basic-auth credentials give the attacker authenticated access to upload, share-link, catcher, clipboard, and CLI endpoints. If goshs is running credential-collection listeners (SMB/LDAP/SMTP), the captured NTLM hashes and SMTP messages flowing through the tunnel are also exposed.
Impact
- Confidentiality (High): all HTTP request and response content is readable by the on-path attacker (URLs, headers, basic-auth
Authorization, file contents, share-link tokens, the?goshs-infoJSON dump). - Integrity (High): attacker can modify responses in-flight — replace served files, inject
<script>into HTML responses, swap offered binaries for backdoored ones. - Availability: not affected.
Preconditions
- Operator must be running
goshs --tunnel/goshs -t. - Attacker must hold a network-on-path position between the operator and
localhost.run:22(LAN MITM, malicious Wi-Fi, hostile ISP/VPN, BGP hijack, or DNS spoofing combined with an attacker-controlled SSH endpoint).
Fix (applied in v2.0.7)
ssh.InsecureIgnoreHostKey() has been replaced with a Trust-On-First-Use (TOFU) host key callback backed by ~/.config/goshs/known_hosts.
Behaviour after the fix:
-
On first connection: goshs accepts the host key presented by
localhost.run, writes it to~/.config/goshs/known_hosts(mode0600), and prints two warning lines:WARN tunnel: pinned new host key for localhost.run:22 (SHA256:<fingerprint>) in ~/.config/goshs/known_hosts WARN tunnel: verify with: ssh-keyscan localhost.run 2>/dev/null | ssh-keygen -l -f -The operator should compare the printed fingerprint against thessh-keyscanoutput to confirm no MITM occurred on that first connection. -
On subsequent connections: the stored key is loaded via
golang.org/x/crypto/ssh/knownhostsand the presented key is verified against it. A mismatch returns a typedHostKeyMismatchErrorand goshs exits immediately with:FATAL tunnel: ssh: host key mismatch for localhost.run:22 — possible MITM attack. If localhost.run legitimately rotated its key, delete ~/.config/goshs/known_hosts and reconnect
Files changed:
| File | Change |
|---|---|
config/config.go |
Added Dir() — creates and returns ~/.config/goshs (mode 0700) |
main.go |
Calls config.Dir() on every startup to ensure the directory exists |
tunnel/tunnel.go |
Replaced InsecureIgnoreHostKey() with buildTOFUCallback(knownHostsFile); added exported HostKeyMismatchError type |
httpserver/server.go |
Resolves ~/.config/goshs/known_hosts via config.Dir(), passes it to tunnel.Start(); fatal-exits on HostKeyMismatchError |
Implementation uses only already-vendored dependencies (golang.org/x/crypto/ssh/knownhosts is part of the existing golang.org/x/crypto direct dependency — no new modules added).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.6"
},
"package": {
"ecosystem": "Go",
"name": "goshs.de/goshs/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-15T17:17:38Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe `--tunnel` / `-t` flag opens an outbound SSH connection to `localhost.run:22` with `HostKeyCallback: ssh.InsecureIgnoreHostKey()`. The Go documentation for that function states verbatim: *\"It should not be used for production code.\"* With the callback disabled the client accepts any host key the server presents, so an attacker who can intercept the operator\u0027s TCP connection to `localhost.run:22` (any router on the path, malicious local network, ARP/DNS spoof on the operator\u0027s LAN, BGP hijack, malicious VPN) can present their own SSH host key, terminate the SSH session locally, and proxy onward \u2014 sitting transparently in the middle of the tunnel.\n\nBecause `localhost.run` does TLS termination at their end, the HTTP traffic on the SSH leg is plaintext, so the on-path attacker reads and rewrites every request and response in cleartext. The goshs operator gets no warning; the public URL works normally.\n\n### Affected Code\n\n**File:** `tunnel/tunnel.go`\n\n```go\nfunc Start(localIP string, localPort int) (*Tunnel, error) {\n config := \u0026ssh.ClientConfig{\n User: \"nokey\",\n Auth: []ssh.AuthMethod{ssh.Password(\"\")},\n HostKeyCallback: ssh.InsecureIgnoreHostKey(), // accepts any server key\n Timeout: 10 * time.Second,\n BannerCallback: func(banner string) error { return nil },\n }\n client, err := ssh.Dial(\"tcp\", \"localhost.run:22\", config)\n ...\n}\n```\n\nThere is no fallback verification \u2014 no `ssh.FixedHostKey`, no `known_hosts` read, no TOFU pin. Every invocation of `goshs --tunnel` is equally vulnerable.\n\n### Exploit Chain\n\n1. Operator runs `goshs --tunnel`. `tunnel.Start()` opens an SSH client to `localhost.run:22` with `InsecureIgnoreHostKey()`.\n2. Attacker positioned on the network path (compromised router, caf\u00e9 Wi-Fi MITM, malicious VPN exit, hostile ISP, BGP hijack, or `arpspoof` + DNS spoof on the operator\u0027s LAN) intercepts the outbound TCP connection to `localhost.run:22` and answers with their own SSH server.\n3. The attacker\u0027s fake SSH server presents an attacker-generated host key. The goshs client\u0027s `HostKeyCallback` returns nil unconditionally. Handshake completes; the client believes it is talking to `localhost.run`.\n4. The attacker proxies the SSH session onward to the real `localhost.run:22`, forwarding the URL capture so `Start()` reads back the genuine `https://*.lhr.life` line and returns successfully. The operator sees the public URL printed to stdout exactly as expected.\n5. Every HTTP request arriving at the public URL is routed over the SSH session. The attacker reads every URL, query string, header, body, and `Authorization` value sent by every visitor.\n6. For each response the attacker can rewrite the body or headers \u2014 serving modified files, injecting HTML/JS, redirecting requests, or stripping `Set-Cookie` attributes.\n7. Captured basic-auth credentials give the attacker authenticated access to upload, share-link, catcher, clipboard, and CLI endpoints. If goshs is running credential-collection listeners (SMB/LDAP/SMTP), the captured NTLM hashes and SMTP messages flowing through the tunnel are also exposed.\n\n### Impact\n\n- **Confidentiality (High):** all HTTP request and response content is readable by the on-path attacker (URLs, headers, basic-auth `Authorization`, file contents, share-link tokens, the `?goshs-info` JSON dump).\n- **Integrity (High):** attacker can modify responses in-flight \u2014 replace served files, inject `\u003cscript\u003e` into HTML responses, swap offered binaries for backdoored ones.\n- **Availability:** not affected.\n\n### Preconditions\n\n- Operator must be running `goshs --tunnel` / `goshs -t`.\n- Attacker must hold a network-on-path position between the operator and `localhost.run:22` (LAN MITM, malicious Wi-Fi, hostile ISP/VPN, BGP hijack, or DNS spoofing combined with an attacker-controlled SSH endpoint).\n\n---\n\n### Fix (applied in v2.0.7)\n\n`ssh.InsecureIgnoreHostKey()` has been replaced with a **Trust-On-First-Use (TOFU)** host key callback backed by `~/.config/goshs/known_hosts`.\n\n**Behaviour after the fix:**\n\n- On **first connection**: goshs accepts the host key presented by `localhost.run`, writes it to `~/.config/goshs/known_hosts` (mode `0600`), and prints two warning lines:\n ```\n WARN tunnel: pinned new host key for localhost.run:22 (SHA256:\u003cfingerprint\u003e) in ~/.config/goshs/known_hosts\n WARN tunnel: verify with: ssh-keyscan localhost.run 2\u003e/dev/null | ssh-keygen -l -f -\n ```\n The operator should compare the printed fingerprint against the `ssh-keyscan` output to confirm no MITM occurred on that first connection.\n\n- On **subsequent connections**: the stored key is loaded via `golang.org/x/crypto/ssh/knownhosts` and the presented key is verified against it. A mismatch returns a typed `HostKeyMismatchError` and goshs exits immediately with:\n ```\n FATAL tunnel: ssh: host key mismatch for localhost.run:22 \u2014 possible MITM attack.\n If localhost.run legitimately rotated its key, delete ~/.config/goshs/known_hosts and reconnect\n ```\n\n**Files changed:**\n\n| File | Change |\n|------|--------|\n| `config/config.go` | Added `Dir()` \u2014 creates and returns `~/.config/goshs` (mode `0700`) |\n| `main.go` | Calls `config.Dir()` on every startup to ensure the directory exists |\n| `tunnel/tunnel.go` | Replaced `InsecureIgnoreHostKey()` with `buildTOFUCallback(knownHostsFile)`; added exported `HostKeyMismatchError` type |\n| `httpserver/server.go` | Resolves `~/.config/goshs/known_hosts` via `config.Dir()`, passes it to `tunnel.Start()`; fatal-exits on `HostKeyMismatchError` |\n\n**Implementation uses only already-vendored dependencies** (`golang.org/x/crypto/ssh/knownhosts` is part of the existing `golang.org/x/crypto` direct dependency \u2014 no new modules added).",
"id": "GHSA-mxg3-432p-mr72",
"modified": "2026-05-15T17:17:38Z",
"published": "2026-05-15T17:17:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/patrickhener/goshs/security/advisories/GHSA-mxg3-432p-mr72"
},
{
"type": "WEB",
"url": "https://github.com/patrickhener/goshs/commit/8f409cb08aacc6e94704334e8b1fb2cd50f5dd98"
},
{
"type": "PACKAGE",
"url": "https://github.com/patrickhener/goshs"
},
{
"type": "WEB",
"url": "https://github.com/patrickhener/goshs/releases/tag/v2.0.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "goshs: SSH host key verification disabled, allowing transparent MITM of every tunnelled HTTP request"
}
GHSA-Q5X2-4347-HRG2
Vulnerability from github – Published: 2024-05-14 18:31 – Updated: 2024-08-12 18:30A vulnerability was found in Satellite. When running a remote execution job on a host, the host's SSH key is not being checked. When the key changes, the Satellite still connects it because it uses "-o StrictHostKeyChecking=no". This flaw can lead to a man-in-the-middle attack (MITM), denial of service, leaking of secrets the remote execution job contains, or other issues that may arise from the attacker's ability to forge an SSH key. This issue does not directly allow unauthorized remote execution on the Satellite, although it can leak secrets that may lead to it.
{
"affected": [],
"aliases": [
"CVE-2024-4871"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T16:17:37Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Satellite. When running a remote execution job on a host, the host\u0027s SSH key is not being checked. When the key changes, the Satellite still connects it because it uses \"-o StrictHostKeyChecking=no\". This flaw can lead to a man-in-the-middle attack (MITM), denial of service, leaking of secrets the remote execution job contains, or other issues that may arise from the attacker\u0027s ability to forge an SSH key. This issue does not directly allow unauthorized remote execution on the Satellite, although it can leak secrets that may lead to it.",
"id": "GHSA-q5x2-4347-hrg2",
"modified": "2024-08-12T18:30:44Z",
"published": "2024-05-14T18:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4871"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2024:4589"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-4871"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2278627"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q7J7-7R72-9H66
Vulnerability from github – Published: 2024-11-12 21:30 – Updated: 2024-11-13 18:31A vulnerability in Brocade Fabric OS versions before 9.2.2 could allow man-in-the-middle attackers to conduct remote Service Session Hijacking that may arise from the attacker's ability to forge an SSH key while the Brocade Fabric OS Switch is performing various remote operations initiated by a switch admin.
{
"affected": [],
"aliases": [
"CVE-2024-7516"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-322"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T19:15:18Z",
"severity": "HIGH"
},
"details": "A vulnerability in Brocade Fabric OS versions before 9.2.2 could allow man-in-the-middle attackers to conduct remote Service Session Hijacking that may arise from the attacker\u0027s ability to forge an SSH key while the Brocade Fabric OS Switch is performing various remote operations initiated by a switch admin.",
"id": "GHSA-q7j7-7r72-9h66",
"modified": "2024-11-13T18:31:59Z",
"published": "2024-11-12T21:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7516"
},
{
"type": "WEB",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/25177"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:H/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-R48R-J8FX-MQ2C
Vulnerability from github – Published: 2022-09-30 00:41 – Updated: 2022-10-03 19:46Impact
An attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.
Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver.
These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.
Patches
matrix-js-sdk has been modified to only accept Olm-encrypted to-device messages.
Out of caution, several other checks have been audited or added:
- Cleartext m.room_key, m.forwarded_room_key and m.secret.send to_device messages are discarded.
- Secrets received from untrusted devices are discarded.
- Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt).
- The origin of a to-device message should only be determined by observing the Olm session which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver.
Workarounds
As this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack.
We are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging.
As an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer verifying with your security passphrase instead.
References
Blog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients
For more information
If you have any questions or comments about this advisory, e-mail us at security@matrix.org.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "matrix-js-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "19.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39251"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T00:41:24Z",
"nvd_published_at": "2022-09-28T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nAn attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield.\n\nAdditionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver.\n\nThese attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.\n\n### Patches\n\nmatrix-js-sdk has been modified to only accept Olm-encrypted to-device messages.\n\nOut of caution, several other checks have been audited or added:\n- Cleartext `m.room_key`, `m.forwarded_room_key` and `m.secret.send` to_device messages are discarded.\n- Secrets received from untrusted devices are discarded.\n- Key backups are only usable if they have a valid signature from a trusted device (no more local trust, or trust-on-decrypt).\n- The origin of a to-device message should only be determined by observing the Olm session which managed to decrypt the message, and not by using claimed sender_key, user_id, or any other fields controllable by the homeserver.\n\n### Workarounds\n\nAs this attack requires coordination between a malicious home server and an attacker, if you trust your home server no particular workaround is needed. Notice that the backup spoofing attack is a particularly sophisticated targeted attack.\n\nWe are not aware of this attack being used in the wild, though specifying a false positive-free way of noticing malicious key backups key is challenging.\n\nAs an abundance of caution, to avoid malicious backup attacks, you should not verify your new logins using emoji/QR verifications methods until patched. Prefer verifying with your security passphrase instead.\n\n### References\nBlog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients\n\n### For more information\nIf you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).\n",
"id": "GHSA-r48r-j8fx-mq2c",
"modified": "2022-10-03T19:46:42Z",
"published": "2022-09-30T00:41:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-r48r-j8fx-mq2c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39251"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/commit/a587d7c36026fe1fcf93dfff63588abee359be76"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-js-sdk"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-js-sdk/releases/tag/v19.7.0"
},
{
"type": "WEB",
"url": "https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202210-35"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "matrix-js-sdk subject to user spoofing via Olm/Megolm protocol confusion"
}
GHSA-RWXW-P86H-G9Q6
Vulnerability from github – Published: 2024-09-09 12:31 – Updated: 2024-09-09 15:30Improper host key checking in active check 'Check SFTP Service' and special agent 'VNX quotas and filesystem' in Checkmk before Checkmk 2.3.0p15, 2.2.0p33, 2.1.0p48 and 2.0.0 (EOL) allows man-in-the-middle attackers to intercept traffic
{
"affected": [],
"aliases": [
"CVE-2024-6572"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-09T10:15:01Z",
"severity": "MODERATE"
},
"details": "Improper host key checking in active check \u0027Check SFTP Service\u0027 and special agent \u0027VNX quotas and filesystem\u0027 in Checkmk before Checkmk 2.3.0p15, 2.2.0p33, 2.1.0p48 and 2.0.0 (EOL) allows man-in-the-middle attackers to intercept traffic",
"id": "GHSA-rwxw-p86h-g9q6",
"modified": "2024-09-09T15:30:40Z",
"published": "2024-09-09T12:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6572"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/17148"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-VJFW-CPMH-XWV3
Vulnerability from github – Published: 2026-09-11 20:45 – Updated: 2026-09-11 20:45Vulnerability
Central Dogma's Git mirror SSH client installs an Apache MINA SSHD ServerKeyVerifier lambda that returns true unconditionally for every outbound SSH connection used by git+ssh:// mirrors. The accompanying lines disable the known_hosts and ~/.ssh/config fallbacks, and a repo-wide search confirms that no host-key pinning mechanism (no acceptedHostKeys, knownHosts, KnownHostsServerKeyVerifier, StaticServerKeyVerifier, or RequiredServerKeyVerifier) exists anywhere in server-mirror-git/. Operators have no opt-in way to enable verification. Every outbound mirror connection blindly trusts whatever host key the remote presents.
Evidence
File: server-mirror-git/src/main/java/com/linecorp/centraldogma/server/internal/mirror/SshGitMirror.java
Lines 143-160 (especially 149) on branch main @ commit d64a5151:
private SshClient createSshClient() {
final ClientBuilder builder = ClientBuilder.builder();
// Do not use local file system.
builder.hostConfigEntryResolver(HostConfigEntryResolver.EMPTY); // line 146
builder.fileSystemFactory(NoneFileSystemFactory.INSTANCE); // line 147
// Do not verify the server key.
builder.serverKeyVerifier((clientSession, remoteAddress, serverKey) -> true); // line 149
...
}
Verification:
- Read confirmed on 2026-05-21 against
main@d64a5151. - A multi-agent code audit verified that no operator-facing pinning field exists on
SshKeyCredential,PasswordCredential, orMirrorContext. - Exploit PoC reproduced locally with a
paramiko-based fake SSH server bound to 127.0.0.1. The fake server presents an ephemeral RSA host key never seen before; the Central Dogma mirror client accepts the connection and proceeds to authentication, logging the offered username and public-key fingerprint. A correctly hardened SSH client would refuse the connection before reaching the authentication phase. - Full PoC artifacts (read-only, loopback-only) at
~/centraldogma-poc/C1_ssh_hostkey_bypass/on the reporter's workstation.
Impact
Threat model: An on-path attacker on the corporate network — ARP spoofing on the LAN, internal DNS poisoning, malicious internal DNS overriding github.com or the configured internal git hostname, BGP hijack, sidecar/CNI compromise in Kubernetes, or any process able to answer TCP on the resolved IP. No Central Dogma account required; only network position.
- Direction
LOCAL_TO_REMOTE: the attacker impersonating the remote git server receives the entire mirrored repository contents over the SSH session. Central Dogma is a configuration store, so this typically exfiltrates DB credentials, third-party API keys, certificates, feature flags, and any other secret configuration committed to mirrored repositories. - Direction
REMOTE_TO_LOCAL: the attacker can serve arbitrary commits which Central Dogma materializes into the local repo and then broadcasts to every subscribing microservice via the watch API. This is a supply-chain root-of-trust compromise across all downstream services consuming Central Dogma configuration. - Credential theft chain with finding H2 (mirror credentials are not bound to a hostname): an SSH key or access token configured for
github.comcan be captured by the attacker's fake server and replayed against the real upstream, extending impact beyond Central Dogma itself.
Scope is Changed (CVSS) because exploitation alters trust assumptions of every downstream client of Central Dogma, not just Central Dogma itself.
How to fix
- Add an
acceptedHostKeys: List<String>field toSshKeyCredentialandPasswordCredential(or toMirrorContext). Values are SHA-256 fingerprints of trusted remote SSH server host keys, e.g.SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. - Replace the accept-all lambda at
SshGitMirror.java:149with a verifier that computes the SHA-256 fingerprint of the presented host key and compares it against the credential's allowlist using a constant-time comparison. - Refuse to connect when
acceptedHostKeysis empty — fail-closed. Do not implement implicit TOFU. - Optionally provide an admin-only
dogma mirror probe-host-key <remote>tool that performs a single audited connection, prints the server's fingerprint, and prompts the operator to add it to the credential. This makes TOFU an explicit, audited operation. - Update
SshGitMirrorTest.javaandit/mirror/*tests to pin a test fingerprint or use the explicit trust-once tool, so the regression cannot silently return.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.linecorp.centraldogma:centraldogma-server-mirror-git"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.84.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-11745"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-11T20:45:50Z",
"nvd_published_at": "2026-06-22T03:16:42Z",
"severity": "HIGH"
},
"details": "# Vulnerability\n\nCentral Dogma\u0027s Git mirror SSH client installs an Apache MINA SSHD `ServerKeyVerifier` lambda that returns `true` unconditionally for every outbound SSH connection used by `git+ssh://` mirrors. The accompanying lines disable the `known_hosts` and `~/.ssh/config` fallbacks, and a repo-wide search confirms that no host-key pinning mechanism (no `acceptedHostKeys`, `knownHosts`, `KnownHostsServerKeyVerifier`, `StaticServerKeyVerifier`, or `RequiredServerKeyVerifier`) exists anywhere in `server-mirror-git/`. Operators have no opt-in way to enable verification. Every outbound mirror connection blindly trusts whatever host key the remote presents.\n\n## Evidence\n\nFile: `server-mirror-git/src/main/java/com/linecorp/centraldogma/server/internal/mirror/SshGitMirror.java`\nLines 143-160 (especially 149) on branch `main` @ commit `d64a5151`:\n\n```java\nprivate SshClient createSshClient() {\n final ClientBuilder builder = ClientBuilder.builder();\n // Do not use local file system.\n builder.hostConfigEntryResolver(HostConfigEntryResolver.EMPTY); // line 146\n builder.fileSystemFactory(NoneFileSystemFactory.INSTANCE); // line 147\n // Do not verify the server key.\n builder.serverKeyVerifier((clientSession, remoteAddress, serverKey) -\u003e true); // line 149\n ...\n}\n```\n\nVerification:\n\n- Read confirmed on 2026-05-21 against `main` @ `d64a5151`.\n- A multi-agent code audit verified that no operator-facing pinning field exists on `SshKeyCredential`, `PasswordCredential`, or `MirrorContext`.\n- Exploit PoC reproduced locally with a `paramiko`-based fake SSH server bound to 127.0.0.1. The fake server presents an ephemeral RSA host key never seen before; the Central Dogma mirror client accepts the connection and proceeds to authentication, logging the offered username and public-key fingerprint. A correctly hardened SSH client would refuse the connection before reaching the authentication phase.\n- Full PoC artifacts (read-only, loopback-only) at `~/centraldogma-poc/C1_ssh_hostkey_bypass/` on the reporter\u0027s workstation.\n\n## Impact\n\nThreat model: An on-path attacker on the corporate network \u2014 ARP spoofing on the LAN, internal DNS poisoning, malicious internal DNS overriding `github.com` or the configured internal git hostname, BGP hijack, sidecar/CNI compromise in Kubernetes, or any process able to answer TCP on the resolved IP. No Central Dogma account required; only network position.\n\n1. **Direction `LOCAL_TO_REMOTE`**: the attacker impersonating the remote git server receives the entire mirrored repository contents over the SSH session. Central Dogma is a configuration store, so this typically exfiltrates DB credentials, third-party API keys, certificates, feature flags, and any other secret configuration committed to mirrored repositories.\n2. **Direction `REMOTE_TO_LOCAL`**: the attacker can serve arbitrary commits which Central Dogma materializes into the local repo and then broadcasts to every subscribing microservice via the watch API. This is a supply-chain root-of-trust compromise across all downstream services consuming Central Dogma configuration.\n3. **Credential theft chain with finding H2** (mirror credentials are not bound to a hostname): an SSH key or access token configured for `github.com` can be captured by the attacker\u0027s fake server and replayed against the real upstream, extending impact beyond Central Dogma itself.\n\nScope is `Changed` (CVSS) because exploitation alters trust assumptions of every downstream client of Central Dogma, not just Central Dogma itself.\n\n## How to fix\n\n1. Add an `acceptedHostKeys: List\u003cString\u003e` field to `SshKeyCredential` and `PasswordCredential` (or to `MirrorContext`). Values are SHA-256 fingerprints of trusted remote SSH server host keys, e.g. `SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8`.\n2. Replace the accept-all lambda at `SshGitMirror.java:149` with a verifier that computes the SHA-256 fingerprint of the presented host key and compares it against the credential\u0027s allowlist using a constant-time comparison.\n3. Refuse to connect when `acceptedHostKeys` is empty \u2014 fail-closed. Do not implement implicit TOFU.\n4. Optionally provide an admin-only `dogma mirror probe-host-key \u003cremote\u003e` tool that performs a single audited connection, prints the server\u0027s fingerprint, and prompts the operator to add it to the credential. This makes TOFU an explicit, audited operation.\n5. Update `SshGitMirrorTest.java` and `it/mirror/*` tests to pin a test fingerprint or use the explicit trust-once tool, so the regression cannot silently return.",
"id": "GHSA-vjfw-cpmh-xwv3",
"modified": "2026-09-11T20:45:50Z",
"published": "2026-09-11T20:45:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/line/centraldogma/security/advisories/GHSA-vjfw-cpmh-xwv3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11745"
},
{
"type": "PACKAGE",
"url": "https://github.com/line/centraldogma"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "Central Dogma: SSH host-key verification permanently disabled in Git mirror (SshGitMirror)"
}
GHSA-VW6G-9HPF-V3CQ
Vulnerability from github – Published: 2026-07-13 18:30 – Updated: 2026-07-14 03:31The Apache Airflow Git provider runs its git-over-SSH operations with StrictHostKeyChecking=no by default, disabling SSH host-key verification. An attacker who can intercept the network path between an Airflow worker and the Git server can impersonate the server (man-in-the-middle), capturing the SSH deploy key or injecting malicious repository content. Deployments that use the Git DAG bundle or Git provider to clone over SSH with a deploy key are affected. The fix changes the default to verify host keys; upgrade to apache-airflow-providers-git 0.4.1 or later and configure a known_hosts file.
{
"affected": [],
"aliases": [
"CVE-2026-58065"
],
"database_specific": {
"cwe_ids": [
"CWE-322"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-13T16:16:41Z",
"severity": "HIGH"
},
"details": "The Apache Airflow Git provider runs its git-over-SSH operations with `StrictHostKeyChecking=no` by default, disabling SSH host-key verification. An attacker who can intercept the network path between an Airflow worker and the Git server can impersonate the server (man-in-the-middle), capturing the SSH deploy key or injecting malicious repository content. Deployments that use the Git DAG bundle or Git provider to clone over SSH with a deploy key are affected. The fix changes the default to verify host keys; upgrade to apache-airflow-providers-git `0.4.1` or later and configure a `known_hosts` file.",
"id": "GHSA-vw6g-9hpf-v3cq",
"modified": "2026-07-14T03:31:34Z",
"published": "2026-07-13T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58065"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/pull/69103"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/fjmclngfksz2kp7llpcjxzdz568h0zhc"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/13/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W4PR-4VJG-HFFH
Vulnerability from github – Published: 2022-09-30 22:56 – Updated: 2022-09-30 22:56When matrix-nio before 0.20 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn't check that the device that responded matches the device the key was requested from.
This allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack.
For more information
If you have any questions or comments about this advisory, e-mail us at poljar@termina.org.uk.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "matrix-nio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39254"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-322"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T22:56:17Z",
"nvd_published_at": "2022-09-29T15:15:00Z",
"severity": "HIGH"
},
"details": "When matrix-nio before 0.20 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn\u0027t check that the device that responded matches the device the key was requested from.\n\nThis allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack.\n\n### For more information\nIf you have any questions or comments about this advisory, e-mail us at [poljar@termina.org.uk](mailto:poljar@termina.org.uk).",
"id": "GHSA-w4pr-4vjg-hffh",
"modified": "2022-09-30T22:56:17Z",
"published": "2022-09-30T22:56:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/poljar/matrix-nio/security/advisories/GHSA-w4pr-4vjg-hffh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39254"
},
{
"type": "WEB",
"url": "https://github.com/poljar/matrix-nio/commit/b1cbf234a831daa160673defd596e6450e9c29f0"
},
{
"type": "PACKAGE",
"url": "https://github.com/poljar/matrix-nio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "When matrix-nio receives forwarded room keys, the receiver doesn\u0027t check if it requested the key from the forwarder"
}
Mitigation
Ensure that proper authentication is included in the system design.
Mitigation
Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.
No CAPEC attack patterns related to this CWE.