Common Weakness Enumeration

CWE-322

Allowed

Key Exchange without Entity Authentication

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product performs a key exchange with an actor without verifying the identity of that actor.

42 vulnerabilities reference this CWE, most recent first.

GHSA-7F6V-QRQR-M9GM

Vulnerability from github – Published: 2026-04-22 00:31 – Updated: 2026-04-22 00:31
VLAI
Details

Zero Motorcycles firmware versions 44 and prior enable an attacker to forcibly pair a device with the motorcycle via Bluetooth. Once paired, an attacker can utilize over-the-air firmware updating functionality to potentially upload malicious firmware to the motorcycle. The motorcycle must first be in Bluetooth pairing mode, and the attacker must be in proximity of the vehicle and understand the full pairing process, to be able to pair their device with the vehicle. The attacker's device must remain paired with and in proximity of the motorcycle for the entire duration of the firmware update.

Severity
6.4 (Medium)
CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H
5.9 (Medium)
CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-1354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-322"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T22:16:18Z",
    "severity": "MODERATE"
  },
  "details": "Zero Motorcycles firmware versions 44 and prior enable an attacker to \nforcibly pair a device with the motorcycle via Bluetooth. Once paired, \nan attacker can utilize over-the-air firmware updating functionality to \npotentially upload malicious firmware to the motorcycle. The motorcycle \nmust first be in Bluetooth pairing mode, and the attacker must be in \nproximity of the vehicle and understand the full pairing process, to be \nable to pair their device with the vehicle. The attacker\u0027s device must \nremain paired with and in proximity of the motorcycle for the entire \nduration of the firmware update.",
  "id": "GHSA-7f6v-qrqr-m9gm",
  "modified": "2026-04-22T00:31:40Z",
  "published": "2026-04-22T00:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1354"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-111-06.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-111-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/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-87RF-W489-PF79

Vulnerability from github – Published: 2025-01-11 00:32 – Updated: 2025-01-11 00:32
VLAI
Details

Backup uploads to ETM subject to man-in-the-middle interception

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47519"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-322"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-10T22:15:26Z",
    "severity": "HIGH"
  },
  "details": "Backup uploads to ETM subject to man-in-the-middle interception",
  "id": "GHSA-87rf-w489-pf79",
  "modified": "2025-01-11T00:32:05Z",
  "published": "2025-01-11T00:32:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47519"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisory/20454-security-advisory-0105"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CM7J-P8HC-97VJ

Vulnerability from github – Published: 2022-07-28 00:00 – Updated: 2022-12-12 20:36
VLAI
Summary
Jenkins Git client plugin 3.11.0 does not perform SSH host key verification
Details

Jenkins Git client plugin 3.11.0 and earlier does not perform SSH host key verification when connecting to Git repositories via SSH, enabling man-in-the-middle attacks. Git client Plugin 3.11.1 provides strategies for performing host key verification for administrators to select the one that meets their security needs. For more information see the plugin documentation.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:git-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36881"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-322"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-10T17:39:44Z",
    "nvd_published_at": "2022-07-27T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Git client plugin 3.11.0 and earlier does not perform SSH host key verification when connecting to Git repositories via SSH, enabling man-in-the-middle attacks. Git client Plugin 3.11.1 provides strategies for performing host key verification for administrators to select the one that meets their security needs. For more information see [the plugin documentation](https://github.com/jenkinsci/git-client-plugin#ssh-host-key-verification).",
  "id": "GHSA-cm7j-p8hc-97vj",
  "modified": "2022-12-12T20:36:46Z",
  "published": "2022-07-28T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/git-client-plugin/commit/88f52c6c9b18bca4ad210e3b9910a49433583fd9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/git-client-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-07-27/#SECURITY-1468"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/07/27/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Git client plugin 3.11.0 does not perform SSH host key verification"
}

GHSA-FPGF-PJJV-2QGM

Vulnerability from github – Published: 2022-09-30 04:37 – Updated: 2022-09-30 04:37
VLAI
Summary
matrix-android-sdk2 vulnerable to Olm/Megolm protocol confusion
Details

Impact

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. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.

These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm.

Patches

matrix-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.

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 using verify with passphrase.

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.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.36"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.matrix.android:matrix-android-sdk2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-322"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-30T04:37:39Z",
    "nvd_published_at": "2022-09-28T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\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. matrix-android-sdk2 would then additionally sign such a key backup with its device key, spilling trust over to other devices trusting the matrix-android-sdk2 device.\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-android-sdk2 has been modified to only accept Olm-encrypted to-device messages and to stop signing backups on a successful decryption.\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\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 using verify with passphrase.\n\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-fpgf-pjjv-2qgm",
  "modified": "2022-09-30T04:37:39Z",
  "published": "2022-09-30T04:37:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/matrix-android-sdk2/security/advisories/GHSA-fpgf-pjjv-2qgm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39248"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/matrix-android-sdk2/commit/77df720a238d17308deab83ecaa37f7a4740a17e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/matrix-android-sdk2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/matrix-android-sdk2/releases/tag/v1.5.1"
    },
    {
      "type": "WEB",
      "url": "https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients"
    }
  ],
  "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-android-sdk2 vulnerable to Olm/Megolm protocol confusion"
}

GHSA-G9V5-GJWF-9RWX

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-30 16:53
VLAI
Summary
Apache Airflow providers-google's `ComputeEngineSSHHook` disables SSH host-key verification by default
Details

Apache 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.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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-MXG3-432P-MR72

Vulnerability from github – Published: 2026-05-15 17:17 – Updated: 2026-05-15 17:17
VLAI
Summary
goshs: SSH host key verification disabled, allowing transparent MITM of every tunnelled HTTP request
Details

Summary

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

  1. Operator runs goshs --tunnel. tunnel.Start() opens an SSH client to localhost.run:22 with InsecureIgnoreHostKey().
  2. 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 to localhost.run:22 and answers with their own SSH server.
  3. The attacker's fake SSH server presents an attacker-generated host key. The goshs client's HostKeyCallback returns nil unconditionally. Handshake completes; the client believes it is talking to localhost.run.
  4. 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.
  5. 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.
  6. For each response the attacker can rewrite the body or headers — serving modified files, injecting HTML/JS, redirecting requests, or stripping Set-Cookie attributes.
  7. 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-info JSON 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 (mode 0600), 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 the ssh-keyscan output to confirm no MITM occurred on that first connection.

  • 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: 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).

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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:30
VLAI
Details

A 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.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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:31
VLAI
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's ability to forge an SSH key while the Brocade Fabric OS Switch is performing various remote operations initiated by a switch admin.

Severity
4.8 (Medium)
CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N
7.0 (High)
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
Show details on source website
To clipboard 

{
  "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:46
VLAI
Summary
matrix-js-sdk subject to user spoofing via Olm/Megolm protocol confusion
Details

Impact

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.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "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:30
VLAI
Details

Improper 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

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
6.3 (Medium)
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
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}
Mitigation
Architecture and Design

Ensure that proper authentication is included in the system design.

Mitigation
Implementation

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.

← Back to the CWE list