CWE-322 CVEs | Waratek

Look up CVE IDs Status Exploitation Severity

Reset

Overview 36 matches · 2 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5

36matches 2in Waratek scope5.6% 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 2 5.6% Outside Waratek scope 3 8.3% Not applicable 31 86.1% Withdrawn CVE 0 0.0%

Critical 5 13.9% High 21 58.3% Medium 10 27.8% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 36 100.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 2 5.6% Forecast only 0 0.0% No public exploit 34 94.4%

split by StatusSeverityProtectionExploit maturity peak 10 / quarter

Q3 211 Not applicable1 High1 not blocked1 No public exploit1 Q4 210 Q1 220 Q2 220 Q3 2210 No exploit published1 Outside Waratek scope2 Not applicable7 High10 not blocked10 No public exploit10 Q4 220 Q1 230 Q2 230 Q3 230 Q4 230 Q1 240 Q2 241 Not applicable1 Medium1 not blocked1 No public exploit1 Q3 241 Not applicable1 Medium1 not blocked1 No public exploit1 Q4 241 Not applicable1 High1 not blocked1 No public exploit1 Q1 251 Not applicable1 High1 not blocked1 No public exploit1 Q2 251 Outside Waratek scope1 High1 not blocked1 No public exploit1 Q3 251 Not applicable1 Medium1 not blocked1 Proof of concept only1 Q4 251 Not applicable1 Medium1 not blocked1 No public exploit1 Q1 263 Not applicable3 Critical1 High2 not blocked3 No public exploit3 Q2 265 No exploit published1 Not applicable4 High4 Medium1 not blocked5 Proof of concept only1 No public exploit4 Q3 264 Not applicable4 Critical1 High1 Medium2 not blocked4 No public exploit4 Q4 266 Not applicable6 Critical3 Medium3 not blocked6 No public exploit6

Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25Q4 25Q2 26Q4 26

36 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2026-126641	Medium	2026-11-12	Not applicable	No public exploit	A host key verification flaw was found in ansible-pylibssh and in the ansible.netcommon libssh connection plugin. When trust-on-first-use is enabled (host_key_auto_add on the libssh connection plugin, or AutoAddPolicy in ansible-pylibssh), a host that is already present in known_hosts but now presents a different key is accepted without warning. The pylibssh Session.verify_knownhost() method passes the SSH_KNOWN_HOSTS_CHANGED and SSH_KNOWN_HOSTS_OTHER states to the same missing_host_key() policy hook used for unknown hosts, and the bundled AutoAddPolicy/RejectPolicy classes (as well as ansible.netcommon's MyAddPolicy, which is modeled on paramiko's AutoAddPolicy) therefore add the changed key and continue the connection rather than aborting as paramiko's BadHostKeyException path would. As a result the controller authenticates to the substitute host, runs the play there, and appends the new key to known_hosts, which can disclose connection credentials to an attacker performing a machine-in-the-middle attack. Default configurations (host_key_checking enabled, host_key_auto_add unset) are not affected; non-interactive runs fail closed.
CVE-2026-94423	Critical	2026-10-21	Not applicable	No public exploit	Net::LibSSH versions before 0.004 for Perl authenticate to an unverified server because connect never checks the host key against known_hosts. connect reports success as soon as ssh_connect returns SSH_OK. libssh leaves the known-hosts check to the application, and this binding never makes it, so the strict_hostkeycheck and knownhosts options are set on the session and then decide nothing. Password, agent and public-key authentication, channel and SFTP operations all run on a session whose peer was never identified, so an attacker who can redirect the connection receives the password when password authentication is used, and commands and data sent over the session.
CVE-2026-94140	Critical	2026-10-21	Not applicable	No public exploit	Rex versions through 1.16.1 for Perl accept an unknown SSH host key for remote rsync transfers because sync hardcodes StrictHostKeyChecking=no. Every remote branch of sync builds its ssh command with that option, for password authentication, for private-key authentication and for the fallback. The ssh options a caller sets through set_openssh_opt reach the OpenSSH transport but not this command, so there is no configuration that restores host key checking for the transfer. An attacker who can redirect the connection before the real host key is known presents their own and the transfer proceeds: under password authentication sync sends the connection password to that server, an upload writes the selected local files to it, and a download writes what it returns to the local destination.
CVE-2026-94135	Medium	2026-10-15	Not applicable	No public exploit	The Apache Airflow SFTP provider's deferrable code paths (`SFTPTrigger`, `SFTPHookAsync`, `SFTPClientPool`) disable SSH host-key verification by default unless the connection explicitly sets `no_host_key_check` to false. Deployments that run SFTP sensors or operators in deferrable mode are affected. An attacker in a machine-in-the-middle position between the triggerer and the SFTP server can impersonate the server and capture the credentials or data exchanged. Users of apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-sftp 7.0.0 or later. This is a separate defect from CVE-2026-94134 (the synchronous SSH hook default, which also affects the SFTP hook); users who applied the fix for one also need this release for the other - apache-airflow-providers-sftp 7.0.0 fixes both.
CVE-2026-94134	Critical	2026-10-15	Not applicable	No public exploit	The Apache Airflow SSH provider hook disables SSH host-key verification by default: unless `host_key` is configured or `no_host_key_check` is explicitly set to false, it accepts any server key. This affects SSH and SFTP connections that rely on the default. An attacker in a machine-in-the-middle position between the worker and the SSH or SFTP server can impersonate the server and capture the credentials or data a task sends. Users of apache-airflow-providers-ssh and apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-ssh 7.0.0 and apache-airflow-providers-sftp 7.0.0 or later. The deferrable SFTP code paths had the same default and are covered separately by CVE-2026-94135; apache-airflow-providers-sftp 7.0.0 fixes both.
CVE-2026-107675	Medium	2026-10-08	Not applicable	No public exploit	FFmpeg through 9.0.2 contains a missing host key verification vulnerability in the libssh-based sftp protocol handler that allows network attackers to impersonate SFTP servers. Attackers performing man-in-the-middle, DNS, or ARP spoofing can capture passwords supplied in sftp URLs, serve forged media, or receive uploaded output.
CVE-2026-77703	Medium	2026-09-24	Not applicable	No public exploit	Key exchange without entity authentication vulnerability in HAVELSAN Inc. Liman Render Engine allows Adversary in the Middle (AiTM). This issue affects Liman Render Engine: from 1.0 before 1.2-75.
CVE-2026-89422	Critical	2026-09-22	Not applicable	No public exploit	Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A pre_shared_key extension in the ServerHello that the client never offered causes the client to complete the handshake without validating the server's certificate, so ssl:connect returns {ok, Socket} against a peer holding no certificate, no private key and no prior session. tls_client_connection_1_3:handle_server_hello/2 passes the received extension to tls_gen_connection_1_3:handle_resumption/2, which sets resumption = true on its mere presence without checking that the client offered a PSK. tls_handshake_1_3:get_pre_shared_key/4 meanwhile falls back to the all-zero "no PSK" value and keys the handshake with the ordinary non-PSK schedule, so the attacker's own ephemeral key suffices. The resumption flag then routes maybe_resumption/1 straight to wait_finished, skipping the certificate-handling states, so certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not. This issue affects OTP from OTP 22.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7.
CVE-2026-18654	Medium	2026-08-03	Not applicable	No public exploit	Key exchange without entity authentication in the EMR SSH helper commands in Amazon AWS CLI before 1.45.28 and AWS CLI v2 before 2.35.3 might allow man-in-the-middle attackers to intercept SSHsessions and file transfers via network positioning between the client and the EMR cluster endpoint. To remediate this issue, users should upgrade to AWS CLI v1 1.45.28 or later, or AWS CLI v2 2.35.3 or later.
CVE-2026-58065	High	2026-07-13	Not applicable	No public exploit	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.
CVE-2026-11745	High	2026-06-22	No exploit published	Proof of concept only	A vulnerability has been identified in centraldogma-server-mirror-git versions prior to 0.84.0, where the Git mirror SSH client does not verify remote host keys for git+ssh:// connections, allowing an on-path attacker to perform man-in-the-middle attacks and compromise mirrored repositories.
CVE-2026-45361	High	2026-05-25	Not applicable	No public exploit	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.
CVE-2026-44467	High	2026-05-13	Not applicable	No public exploit	The Claude Desktop app gives you Claude Code with a graphical interface built for running multiple sessions side by side. From 1.2581.0 to before 1.4304.0, Claude Desktop's SSH remote development feature verified only whether a hostname existed in ~/.ssh/known_hosts without comparing the server's presented host key against the stored key. This allowed a network-positioned attacker to present an arbitrary SSH host key and have the connection silently accepted, enabling a man-in-the-middle attack on remote development sessions. Successful exploitation required the attacker to be in a network position to intercept SSH traffic (e.g., via ARP spoofing, rogue Wi-Fi, or DNS poisoning) and the target hostname to already have an entry in the victim's known_hosts file. This vulnerability is fixed in 1.4304.0.
CVE-2026-1354	Medium	2026-04-21	Not applicable	No public exploit	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.
CVE-2025-13914	High	2026-04-09	Not applicable	No public exploit	A Key Exchange without Entity Authentication vulnerability in the SSH implementation of Juniper Networks Apstra allows a unauthenticated, MITM attacker to impersonate managed devices. Due to insufficient SSH host key validation an attacker can perform a machine-in-the-middle attack on the SSH connections from Apstra to managed devices, enabling an attacker to impersonate a managed device and capture user credentials. This issue affects all versions of Apstra before 6.1.1.
CVE-2026-33697	High	2026-03-27	Not applicable	No public exploit	Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits.
CVE-2026-1709	Critical	2026-02-06	Not applicable	No public exploit	A flaw was found in Keylime. The Keylime registrar, since version 7.12.0, does not enforce client-side Transport Layer Security (TLS) authentication. This authentication bypass vulnerability allows unauthenticated clients with network access to perform administrative operations, including listing agents, retrieving public Trusted Platform Module (TPM) data, and deleting agents, by connecting without presenting a client certificate.
CVE-2025-62501	High	2026-02-03	Not applicable	No public exploit	SSH Hostkey misconfiguration vulnerability in Archer AX53 and Archer BE3600 (tmpserver modules) allows attackers to obtain device credentials through a specially crafted man‑in‑the‑middle (MITM) attack. This could enable unauthorized access if captured credentials are reused.
CVE-2025-10966	Medium	2025-11-07	Not applicable	No public exploit	curl's code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed and missed host verification mechanisms. This prevents curl from detecting MITM attackers and more.
CVE-2025-54422	Medium	2025-07-29	Not applicable	Proof of concept only	Sandboxie is a sandbox-based isolation software for 32-bit and 64-bit Windows NT-based operating systems. In versions 1.16.1 and below, a critical security vulnerability exists in password handling mechanisms. During encrypted sandbox creation, user passwords are transmitted via shared memory, exposing them to potential interception. The vulnerability is particularly severe during password modification operations, where both old and new passwords are passed as plaintext command-line arguments to the Imbox process without any encryption or obfuscation. This implementation flaw allows any process within the user session, including unprivileged processes, to retrieve these sensitive credentials by reading the command-line arguments, thereby bypassing standard privilege requirements and creating a significant security risk. This is fixed in version 1.16.2.
CVE-2025-20163	High	2025-06-04	Outside Waratek scope	No public exploit	A vulnerability in the SSH implementation of Cisco Nexus Dashboard Fabric Controller (NDFC) could allow an unauthenticated, remote attacker to impersonate Cisco NDFC-managed devices. This vulnerability is due to insufficient SSH host key validation. An attacker could exploit this vulnerability by performing a machine-in-the-middle attack on SSH connections to Cisco NDFC-managed devices, which could allow an attacker to intercept this traffic. A successful exploit could allow the attacker to impersonate a managed device and capture user credentials.
CVE-2024-47519	High	2025-01-10	Not applicable	No public exploit	Backup uploads to ETM subject to man-in-the-middle interception
CVE-2024-7516	High	2024-11-12	Not applicable	No public exploit	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.
CVE-2024-6572	Medium	2024-09-09	Not applicable	No public exploit	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
CVE-2024-4871	Medium	2024-05-14	Not applicable	No public exploit	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.
CVE-2022-39254	High	2022-09-29	Not applicable	No public exploit	matrix-nio is a Python Matrix client library, designed according to sans I/O principles. Prior to version 0.20, when a users requests a room key from their devices, the software correctly remember the request. Once they receive a forwarded room key, they accept it without checking who the room key came from. This allows homeservers to try to insert room keys of questionable validity, potentially mounting an impersonation attack. Version 0.20 fixes the issue.
CVE-2022-39252	High	2022-09-29	Not applicable	No public exploit	matrix-rust-sdk is an implementation of a Matrix client-server library in Rust, and matrix-sdk-crypto is the Matrix encryption library. Prior to version 0.6, when a user requests a room key from their devices, the software correctly remembers the request. When the user receives a forwarded room key, the software accepts it without checking who the room key came from. This allows homeservers to try to insert room keys of questionable validity, potentially mounting an impersonation attack. Version 0.6 fixes this issue.
CVE-2022-39250	High	2022-09-29	Not applicable	No public exploit	Matrix JavaScript SDK is the Matrix Client-Server software development kit (SDK) for JavaScript. Prior to version 19.7.0, an attacker cooperating with a malicious homeserver could interfere with the verification flow between two users, injecting its own cross-signing user identity in place of one of the users’ identities. This would lead to the other device trusting/verifying the user identity under the control of the homeserver instead of the intended one. The vulnerability is a bug in the matrix-js-sdk, caused by checking and signing user identities and devices in two separate steps, and inadequately fixing the keys to be signed between those steps. Even though the attack is partly made possible due to the design decision of treating cross-signing user identities as Matrix devices on the server side (with their device ID set to the public part of the user identity key), no other examined implementations were vulnerable. Starting with version 19.7.0, the matrix-js-sdk has been modified to double check that the key signed is the one that was verified instead of just referencing the key by ID. An additional check has been made to report an error when one of the device ID matches a cross-signing key. As this attack requires coordination between a malicious homeserver and an attacker, those who trust their homeservers do not need a particular workaround.
CVE-2022-39257	High	2022-09-28	Not applicable	No public exploit	Matrix iOS SDK allows developers to build iOS apps compatible with Matrix. Prior to version 0.23.19, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-ios-sdk implementing a too permissive key forwarding strategy. The default policy for accepting key forwards has been made more strict in the matrix-ios-sdk version 0.23.19. matrix-ios-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately (for example, by showing a warning for such messages). This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.
CVE-2022-39255	High	2022-09-28	Not applicable	No public exploit	Matrix iOS SDK allows developers to build iOS apps compatible with Matrix. Prior to version 0.23.19, 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. matrix-ios-sdk version 0.23.19 has been modified to only accept Olm-encrypted to-device messages. Out of caution, several other checks have been audited or added. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround. To avoid malicious backup attacks, one should not verify one's new logins using emoji/QR verifications methods until patched.
CVE-2022-39251	High	2022-09-28	Not applicable	No public exploit	Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, 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. Starting with version 19.7.0, 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. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.
CVE-2022-39249	High	2022-09-28	Not applicable	No public exploit	Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-js-sdk implementing a too permissive key forwarding strategy on the receiving end. Starting with version 19.7.0, the default policy for accepting key forwards has been made more strict in the matrix-js-sdk. matrix-js-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately, for example, by showing a warning for such messages. This attack requires coordination between a malicious homeserver and an attacker, and those who trust your homeservers do not need a workaround.
CVE-2022-39248	High	2022-09-28	Outside Waratek scope	No public exploit	matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, 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. matrix-android-sdk2 version 1.5.1 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. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.
CVE-2022-39246	High	2022-09-28	Outside Waratek scope	No public exploit	matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the key forwarding strategy implemented in the matrix-android-sdk2 that is too permissive. Starting with version 1.5.1, the default policy for accepting key forwards has been made more strict in the matrix-android-sdk2. The matrix-android-sdk2 will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately (for example, by showing a warning for such messages). As a workaroubnd, current users of the SDK can disable key forwarding in their forks using `CryptoService#enableKeyGossiping(enable: Boolean)`.
CVE-2022-36881	High	2022-07-27	No exploit published	No public exploit	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.
CVE-2021-34433	High	2021-08-20	Not applicable	No public exploit	In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side's signature on the client side, if that signature is not included in the server's ServerKeyExchange.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2026-126641

Medium

2026-11-12

Not applicable

No public exploit

A host key verification flaw was found in ansible-pylibssh and in the ansible.netcommon libssh connection plugin. When trust-on-first-use is enabled (host_key_auto_add on the libssh connection plugin, or AutoAddPolicy in ansible-pylibssh), a host that is already present in known_hosts but now presents a different key is accepted without warning. The pylibssh Session.verify_knownhost() method passes the SSH_KNOWN_HOSTS_CHANGED and SSH_KNOWN_HOSTS_OTHER states to the same missing_host_key() policy hook used for unknown hosts, and the bundled AutoAddPolicy/RejectPolicy classes (as well as ansible.netcommon's MyAddPolicy, which is modeled on paramiko's AutoAddPolicy) therefore add the changed key and continue the connection rather than aborting as paramiko's BadHostKeyException path would. As a result the controller authenticates to the substitute host, runs the play there, and appends the new key to known_hosts, which can disclose connection credentials to an attacker performing a machine-in-the-middle attack. Default configurations (host_key_checking enabled, host_key_auto_add unset) are not affected; non-interactive runs fail closed.

CVE-2026-94423

Critical

2026-10-21

Not applicable

No public exploit

Net::LibSSH versions before 0.004 for Perl authenticate to an unverified server because connect never checks the host key against known_hosts. connect reports success as soon as ssh_connect returns SSH_OK. libssh leaves the known-hosts check to the application, and this binding never makes it, so the strict_hostkeycheck and knownhosts options are set on the session and then decide nothing. Password, agent and public-key authentication, channel and SFTP operations all run on a session whose peer was never identified, so an attacker who can redirect the connection receives the password when password authentication is used, and commands and data sent over the session.

CVE-2026-94140

Critical

2026-10-21

Not applicable

No public exploit

Rex versions through 1.16.1 for Perl accept an unknown SSH host key for remote rsync transfers because sync hardcodes StrictHostKeyChecking=no. Every remote branch of sync builds its ssh command with that option, for password authentication, for private-key authentication and for the fallback. The ssh options a caller sets through set_openssh_opt reach the OpenSSH transport but not this command, so there is no configuration that restores host key checking for the transfer. An attacker who can redirect the connection before the real host key is known presents their own and the transfer proceeds: under password authentication sync sends the connection password to that server, an upload writes the selected local files to it, and a download writes what it returns to the local destination.

CVE-2026-94135

Medium

2026-10-15

Not applicable

No public exploit

The Apache Airflow SFTP provider's deferrable code paths (`SFTPTrigger`, `SFTPHookAsync`, `SFTPClientPool`) disable SSH host-key verification by default unless the connection explicitly sets `no_host_key_check` to false. Deployments that run SFTP sensors or operators in deferrable mode are affected. An attacker in a machine-in-the-middle position between the triggerer and the SFTP server can impersonate the server and capture the credentials or data exchanged. Users of apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-sftp 7.0.0 or later. This is a separate defect from CVE-2026-94134 (the synchronous SSH hook default, which also affects the SFTP hook); users who applied the fix for one also need this release for the other - apache-airflow-providers-sftp 7.0.0 fixes both.

CVE-2026-94134

Critical

2026-10-15

Not applicable

No public exploit

The Apache Airflow SSH provider hook disables SSH host-key verification by default: unless `host_key` is configured or `no_host_key_check` is explicitly set to false, it accepts any server key. This affects SSH and SFTP connections that rely on the default. An attacker in a machine-in-the-middle position between the worker and the SSH or SFTP server can impersonate the server and capture the credentials or data a task sends. Users of apache-airflow-providers-ssh and apache-airflow-providers-sftp are recommended to upgrade to apache-airflow-providers-ssh 7.0.0 and apache-airflow-providers-sftp 7.0.0 or later. The deferrable SFTP code paths had the same default and are covered separately by CVE-2026-94135; apache-airflow-providers-sftp 7.0.0 fixes both.

CVE-2026-107675

Medium

2026-10-08

Not applicable

No public exploit

FFmpeg through 9.0.2 contains a missing host key verification vulnerability in the libssh-based sftp protocol handler that allows network attackers to impersonate SFTP servers. Attackers performing man-in-the-middle, DNS, or ARP spoofing can capture passwords supplied in sftp URLs, serve forged media, or receive uploaded output.

CVE-2026-77703

Medium

2026-09-24

Not applicable

No public exploit

Key exchange without entity authentication vulnerability in HAVELSAN Inc. Liman Render Engine allows Adversary in the Middle (AiTM). This issue affects Liman Render Engine: from 1.0 before 1.2-75.

CVE-2026-89422

Critical

2026-09-22

Not applicable

No public exploit

Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A pre_shared_key extension in the ServerHello that the client never offered causes the client to complete the handshake without validating the server's certificate, so ssl:connect returns {ok, Socket} against a peer holding no certificate, no private key and no prior session. tls_client_connection_1_3:handle_server_hello/2 passes the received extension to tls_gen_connection_1_3:handle_resumption/2, which sets resumption = true on its mere presence without checking that the client offered a PSK. tls_handshake_1_3:get_pre_shared_key/4 meanwhile falls back to the all-zero "no PSK" value and keys the handshake with the ordinary non-PSK schedule, so the attacker's own ephemeral key suffices. The resumption flag then routes maybe_resumption/1 straight to wait_finished, skipping the certificate-handling states, so certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not. This issue affects OTP from OTP 22.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7.

CVE-2026-18654

Medium

2026-08-03

Not applicable

No public exploit

Key exchange without entity authentication in the EMR SSH helper commands in Amazon AWS CLI before 1.45.28 and AWS CLI v2 before 2.35.3 might allow man-in-the-middle attackers to intercept SSHsessions and file transfers via network positioning between the client and the EMR cluster endpoint. To remediate this issue, users should upgrade to AWS CLI v1 1.45.28 or later, or AWS CLI v2 2.35.3 or later.

CVE-2026-58065

High

2026-07-13

Not applicable

No public exploit

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.

CVE-2026-11745

High

2026-06-22

No exploit published

Proof of concept only

A vulnerability has been identified in centraldogma-server-mirror-git versions prior to 0.84.0, where the Git mirror SSH client does not verify remote host keys for git+ssh:// connections, allowing an on-path attacker to perform man-in-the-middle attacks and compromise mirrored repositories.

CVE-2026-45361

High

2026-05-25

Not applicable

No public exploit

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.

CVE-2026-44467

High

2026-05-13

Not applicable

No public exploit

The Claude Desktop app gives you Claude Code with a graphical interface built for running multiple sessions side by side. From 1.2581.0 to before 1.4304.0, Claude Desktop's SSH remote development feature verified only whether a hostname existed in ~/.ssh/known_hosts without comparing the server's presented host key against the stored key. This allowed a network-positioned attacker to present an arbitrary SSH host key and have the connection silently accepted, enabling a man-in-the-middle attack on remote development sessions. Successful exploitation required the attacker to be in a network position to intercept SSH traffic (e.g., via ARP spoofing, rogue Wi-Fi, or DNS poisoning) and the target hostname to already have an entry in the victim's known_hosts file. This vulnerability is fixed in 1.4304.0.

CVE-2026-1354

Medium

2026-04-21

Not applicable

No public exploit

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.

CVE-2025-13914

High

2026-04-09

Not applicable

No public exploit

A Key Exchange without Entity Authentication vulnerability in the SSH implementation of Juniper Networks Apstra allows a unauthenticated, MITM attacker to impersonate managed devices. Due to insufficient SSH host key validation an attacker can perform a machine-in-the-middle attack on the SSH connections from Apstra to managed devices, enabling an attacker to impersonate a managed device and capture user credentials. This issue affects all versions of Apstra before 6.1.1.

CVE-2026-33697

High

2026-03-27

Not applicable

No public exploit

Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits.

CVE-2026-1709

Critical

2026-02-06

Not applicable

No public exploit

A flaw was found in Keylime. The Keylime registrar, since version 7.12.0, does not enforce client-side Transport Layer Security (TLS) authentication. This authentication bypass vulnerability allows unauthenticated clients with network access to perform administrative operations, including listing agents, retrieving public Trusted Platform Module (TPM) data, and deleting agents, by connecting without presenting a client certificate.

CVE-2025-62501

High

2026-02-03

Not applicable

No public exploit

SSH Hostkey misconfiguration vulnerability in Archer AX53 and Archer BE3600 (tmpserver modules) allows attackers to obtain device credentials through a specially crafted man‑in‑the‑middle (MITM) attack. This could enable unauthorized access if captured credentials are reused.

CVE-2025-10966

Medium

2025-11-07

Not applicable

No public exploit

curl's code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed and missed host verification mechanisms. This prevents curl from detecting MITM attackers and more.

CVE-2025-54422

Medium

2025-07-29

Not applicable

Proof of concept only

Sandboxie is a sandbox-based isolation software for 32-bit and 64-bit Windows NT-based operating systems. In versions 1.16.1 and below, a critical security vulnerability exists in password handling mechanisms. During encrypted sandbox creation, user passwords are transmitted via shared memory, exposing them to potential interception. The vulnerability is particularly severe during password modification operations, where both old and new passwords are passed as plaintext command-line arguments to the Imbox process without any encryption or obfuscation. This implementation flaw allows any process within the user session, including unprivileged processes, to retrieve these sensitive credentials by reading the command-line arguments, thereby bypassing standard privilege requirements and creating a significant security risk. This is fixed in version 1.16.2.

CVE-2025-20163

High

2025-06-04

Outside Waratek scope

No public exploit

A vulnerability in the SSH implementation of Cisco Nexus Dashboard Fabric Controller (NDFC) could allow an unauthenticated, remote attacker to impersonate Cisco NDFC-managed devices. This vulnerability is due to insufficient SSH host key validation. An attacker could exploit this vulnerability by performing a machine-in-the-middle attack on SSH connections to Cisco NDFC-managed devices, which could allow an attacker to intercept this traffic. A successful exploit could allow the attacker to impersonate a managed device and capture user credentials.

CVE-2024-47519

High

2025-01-10

Not applicable

No public exploit

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

CVE-2024-7516

High

2024-11-12

Not applicable

No public exploit

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.

CVE-2024-6572

Medium

2024-09-09

Not applicable

No public exploit

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

CVE-2024-4871

Medium

2024-05-14

Not applicable

No public exploit

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.

CVE-2022-39254

High

2022-09-29

Not applicable

No public exploit

matrix-nio is a Python Matrix client library, designed according to sans I/O principles. Prior to version 0.20, when a users requests a room key from their devices, the software correctly remember the request. Once they receive a forwarded room key, they accept it without checking who the room key came from. This allows homeservers to try to insert room keys of questionable validity, potentially mounting an impersonation attack. Version 0.20 fixes the issue.

CVE-2022-39252

High

2022-09-29

Not applicable

No public exploit

matrix-rust-sdk is an implementation of a Matrix client-server library in Rust, and matrix-sdk-crypto is the Matrix encryption library. Prior to version 0.6, when a user requests a room key from their devices, the software correctly remembers the request. When the user receives a forwarded room key, the software accepts it without checking who the room key came from. This allows homeservers to try to insert room keys of questionable validity, potentially mounting an impersonation attack. Version 0.6 fixes this issue.

CVE-2022-39250

High

2022-09-29

Not applicable

No public exploit

Matrix JavaScript SDK is the Matrix Client-Server software development kit (SDK) for JavaScript. Prior to version 19.7.0, an attacker cooperating with a malicious homeserver could interfere with the verification flow between two users, injecting its own cross-signing user identity in place of one of the users’ identities. This would lead to the other device trusting/verifying the user identity under the control of the homeserver instead of the intended one. The vulnerability is a bug in the matrix-js-sdk, caused by checking and signing user identities and devices in two separate steps, and inadequately fixing the keys to be signed between those steps. Even though the attack is partly made possible due to the design decision of treating cross-signing user identities as Matrix devices on the server side (with their device ID set to the public part of the user identity key), no other examined implementations were vulnerable. Starting with version 19.7.0, the matrix-js-sdk has been modified to double check that the key signed is the one that was verified instead of just referencing the key by ID. An additional check has been made to report an error when one of the device ID matches a cross-signing key. As this attack requires coordination between a malicious homeserver and an attacker, those who trust their homeservers do not need a particular workaround.

CVE-2022-39257

High

2022-09-28

Not applicable

No public exploit

Matrix iOS SDK allows developers to build iOS apps compatible with Matrix. Prior to version 0.23.19, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-ios-sdk implementing a too permissive key forwarding strategy. The default policy for accepting key forwards has been made more strict in the matrix-ios-sdk version 0.23.19. matrix-ios-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately (for example, by showing a warning for such messages). This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.

CVE-2022-39255

High

2022-09-28

Not applicable

No public exploit

Matrix iOS SDK allows developers to build iOS apps compatible with Matrix. Prior to version 0.23.19, 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. matrix-ios-sdk version 0.23.19 has been modified to only accept Olm-encrypted to-device messages. Out of caution, several other checks have been audited or added. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround. To avoid malicious backup attacks, one should not verify one's new logins using emoji/QR verifications methods until patched.

CVE-2022-39251

High

2022-09-28

Not applicable

No public exploit

Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, 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. Starting with version 19.7.0, 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. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.

CVE-2022-39249

High

2022-09-28

Not applicable

No public exploit

Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-js-sdk implementing a too permissive key forwarding strategy on the receiving end. Starting with version 19.7.0, the default policy for accepting key forwards has been made more strict in the matrix-js-sdk. matrix-js-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately, for example, by showing a warning for such messages. This attack requires coordination between a malicious homeserver and an attacker, and those who trust your homeservers do not need a workaround.

CVE-2022-39248

High

2022-09-28

Outside Waratek scope

No public exploit

matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, 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. matrix-android-sdk2 version 1.5.1 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. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround.

CVE-2022-39246

High

2022-09-28

Outside Waratek scope

No public exploit

matrix-android-sdk2 is the Matrix SDK for Android. Prior to version 1.5.1, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the key forwarding strategy implemented in the matrix-android-sdk2 that is too permissive. Starting with version 1.5.1, the default policy for accepting key forwards has been made more strict in the matrix-android-sdk2. The matrix-android-sdk2 will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately (for example, by showing a warning for such messages). As a workaroubnd, current users of the SDK can disable key forwarding in their forks using `CryptoService#enableKeyGossiping(enable: Boolean)`.

CVE-2022-36881

High

2022-07-27

No exploit published

No public exploit

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.

CVE-2021-34433

High

2021-08-20

Not applicable

No public exploit

In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side's signature on the client side, if that signature is not included in the server's ServerKeyExchange.