A critical vulnerability in the Erlang/OTP SSH, tracked as CVE-2025-32433, has been disclosed that allows for unauthenticated remote code execution on vulnerable devices.
The flaw was discovered by Fabian Bäumer, Marcus Brinkmann, Marcel Maehren, and Jörg Schwenk of the Ruhr University Bochum in Germany and given a maximum severity score of 10.0.
All devices running the Erlang/OTP SSH daemon are impacted by the vulnerability and are advised to upgrade to versions 25.3.2.10 and 26.2.4 to fix the flaw.
Erlang is a programming language known for its fault-tolerance and concurrency, making it commonly used in telecom infrastructure and high -availability systems. Erlang/OTP is a set of libraries, design principles, and tools built on top of Erlang that provides components like the SSH application for remote access.
The CVE-2025-32433 vulnerability is caused by the improper handling of certain pre-authentication protocol messages within the SSH daemon provided by Erlang/OTP’s SSH application.
« The issue is caused by a flaw in the SSH protocol message handling which allows an attacker to send connection protocol messages prior to authentication, » reads a disclosure on the OpenWall vulnerability mailing list.
Any commands executed through the vulnerability will be run with the same privileges as the SSH daemon. In many cases, the daemon runs as root, which would allow attackers to fully compromise the system.
Horizon3’s Attack Team, known for their exploit research, warned on X that they had reproduced the flaw and found it « surprisingly easy, » demonstrating a PoC that writes a file as root on affected systems.
« Just finished reproducing CVE-2025-32433 and putting together a quick PoC exploit — surprisingly easy. Wouldn’t be shocked if public PoCs start dropping soon. If you’re tracking this, now’s the time to take action, » Horizon3 posted to X.
Organizations are strongly advised to upgrade to the fixed versions immediately before a PoC becomes public and the flaw is mass-exploited.
For systems, such as industrial or mission-critical devices that can’t be easily updated, it is advised that access to SSH be restricted to trusted IPs, or the SSH daemon should be turned off if not needed.
Plus de détails sur l’article original.