Trueskrillor

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions prior to OTP-27.3.4 Erlang/OTP versions prior to OTP-26.2.5.12 Erlang/OTP versions prior to OTP-25.3.2.21 **Description** The issue concerns Erlang/OTP SSH failing to enforce strict KEX handshake hardening measures by allowing optional messages to be exchanged. This allows a Man-in-the-Middle attacker to inject these messages in a connection during the handshake. **Recommendations** For versions prior to OTP-27.3.4, update to OTP-27.3.4 or later. For versions prior to OTP-26.2.5.12, update to OTP-26.2.5.12 or later. For versions prior to OTP-25.3.2.21, update to OTP-25.3.2.21 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions prior to OTP-27.3.3 Erlang/OTP versions prior to OTP-26.2.5.11 Erlang/OTP versions prior to OTP-25.3.2.20 **Description** A critical flaw in the SSH protocol implementation of the Erlang/OTP library allows unauthenticated remote code execution (RCE). The issue stems from incorrect handling of SSH protocol messages, where the server may fail to verify the authentication stage and prematurely process `CHANNEL OPEN` and `exec` requests. This enables a remote attacker to send specially crafted SSH packets to execute arbitrary commands without valid credentials. If the SSH daemon runs with root privileges, an attacker can gain full control of the host system. Approximately 600,000 IP addresses are estimated to be running Erlang/OTP, with significant risks to telecom infrastructures, databases, and high-availability systems. Real-world exploitation has been observed, particularly targeting operational technology (OT) networks, with some attacks focusing on healthcare, agriculture, media, and high-tech sectors in the US, Canada, Brazil, India, and Australia. Attackers have been seen deploying reverse shells to maintain unauthorized remote access. **Recommendations** Update to version OTP-27.3.3 or newer. Update to version OTP-26.2.5.11 or newer. Update to version OTP-25.3.2.20 or newer. As a temporary workaround, disable the SSH server or restrict access using firewall rules.

**Name of the Vulnerable Software and Affected Versions** AsyncSSH versions prior to 2.14.1 **Description** The issue in AsyncSSH allows attackers to control the extension info message via a man-in-the-middle attack, enabling them to conduct algorithm downgrade attacks during user authentication. This can be achieved by exploiting the implementation flaw in AsyncSSH to inject an extension info message chosen by the attacker and delete the original extension info message. The attacker can meddle with the value of `server-sig-algs` to use a weaker algorithm, such as SHA-1 instead of SHA-2. **Recommendations** For versions prior to 2.14.1, update to version 2.14.1 or later to resolve the issue. As a temporary workaround, consider restricting access to the vulnerable `server-sig-algs` extension until a patch is available. Avoid using the `server-sig-algs` extension in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** AsyncSSH versions 2.14.0 and earlier **Description** The issue in AsyncSSH allows attackers to control the remote end of an SSH client session via packet injection/removal and shell emulation, also known as a "Rogue Session Attack." This can lead to a complete break of the confidentiality and integrity of the secure channel, providing a strong vector for a targeted phishing campaign against the user. The attacker can inject a chosen authentication request before the client's NewKeys, allowing them to log the client into the attacker's account without the client being able to detect this. The attacker receives all keyboard input by the user, completely controls the terminal output of the user's session, can send and receive data to/from forwarded network ports, and is able to create signatures with a forwarded SSH Agent, if any. **Recommendations** For AsyncSSH versions 2.14.0 and earlier, update to version 2.14.1 or later to resolve the issue. As a temporary workaround, consider restricting access to the SSH server or implementing additional authentication mechanisms to minimize the risk of exploitation.