As I understand it, this is talking about an SSH server built into Erlang/OTP, not e.g. OpenSSH on a server with Erlang installed.
>Any service using Erlang/OTP's SSH library for remote access such as those used in OT/IoT devices, edge computing devices are susceptible to exploitation.
This is why I generally do not rely on SSH servers other than OpenSSH. It's (by far) the most widely deployed implementation, thoroughly battle-tested, etc. It's also hard to actually get pwned; the OpenBSD[1] guys believe in security as the default.
There's some value in avoiding a monoculture, or choosing different trade-offs (e.g. binary size, memory usage). But as exemplified by this incident, any incentives must be carefully weighted against the risks. SSH is your final line of defence.
If I interpret the patch correctly the issue seems to be that you could just ask for a channel and do a request_exec before authenticating. The regression test is:
I'm vaguely surprised that https://www.runzero.com/sshamble/ didn't find this. They did a scan over the entire internet trying invalid SSH state machine transitions, which I guess didn't cover this sequence.
CWE-306, Missing Authentication for Critical Function, linked in the report seems to suggest the same. The score of 10.0 is damn spicy, too - you just ask the server to execute something for you, and it does so, no questions asked.
> 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.
I'm assuming the most likely affected Elixir projects would be those using Nerves with SSH enabled and exposed to the public internet, as nerves_ssh wraps the OTP SSH daemon.
Don't think that's a very common thing to do, even in my hobby projects I would only access a Nerves device through a VPN.
This is also true of erlang right? This module is part of the stdlib but if you haven't implemented access using it it's "turned off" in the same way any other libraries you aren't using are.
For folks interested in the Security aspects of Erlang/BEAM languages the guidelines from Security Working Group of the Erlang Ecosystem Foundation are a good resource - https://security.erlef.org/ and https://erlef.org/wg/security
How does this affect servers like ejabberd? I just noticed that they upgraded their server yesterday [0] and am wondering if it could contain some kind of fix for this, or would this be unrelated?
ejabberd doesn't start the Erlang SSH daemon; or at least codesearch on their github doesn't have any reference to ssh other than something unrelated trying to figure out if a url is a git repo.
I didn't think anyone actually ran the Erlang SSH daemon (although there's evidence that some people do!). It makes for a fun demo, but a regular OS shell is more useful, and you can attach a debug shell to an existing BEAM process from there.
Oops..... we are currently trying to sell an elixir-based greenfield project internally. This doesn't affect elixir by default as other commenters pointed out, but still might make our project a bit harder to pitch to management...
If your organization is looking for "the language ecosystem that never has any security vulnerabilities", pack it in and close up shop because you're not going to find one. How many, how often, and how they are handled is far more important.
While the Erlang/Elixir ecosystem won't stop you from writing a network server that takes in a string and just blithely passes it along to a shell without analysis, overall the Erlang/Elixir ecosystem is very strong and lacks most of the footguns like an "eval" statement that get people. Though I will ding it a point for the most obvious way to run a shell command [1] taking just a string that goes to a shell rather than an array of parameters to a shell command.
It is on the higher end of secure languages to write a network server in.
That is quite the wrong way of looking at it. The vulnerability is in a implementation of SSH and not with the language/runtime itself; And it has already been patched. Erlang is a "managed" language and is quite secure compared to others.
You should definitely "sell" Elixir/Erlang/BEAM based languages to your management for a greenfield project; The opportunity is too good to pass up.
Nevertheless, if you would like to learn how to "harden" your Elixir/Erlang system, see the guidelines from the "Security Working Group" of EEF which i have linked to here - https://news.ycombinator.com/item?id=43717633
aftbit|10 months ago
>Any service using Erlang/OTP's SSH library for remote access such as those used in OT/IoT devices, edge computing devices are susceptible to exploitation.
https://thehackernews.com/2025/04/critical-erlangotp-ssh-vul...
kimi|10 months ago
See for example https://blog.differentpla.net/blog/2022/11/01/erlang-ssh/
rollcat|10 months ago
There's some value in avoiding a monoculture, or choosing different trade-offs (e.g. binary size, memory usage). But as exemplified by this incident, any incentives must be carefully weighted against the risks. SSH is your final line of defence.
[1]: https://www.openbsd.org/donations.html
formerly_proven|10 months ago
edit: Ah, found by the people at RUB, they do a lot of research in verifying protocol implementations iirc.
ziddoap|10 months ago
For those not in-the-know, this is "Ruhr University Bochum".
https://www.ruhr-uni-bochum.de/en
They have quite a good reputation in the security research space.
chc4|10 months ago
phoe-krk|10 months ago
password4321|10 months ago
per https://www.openwall.com/lists/oss-security/2025/04/16/2
throwawaymaths|10 months ago
https://paraxial.io/blog/erlang-ssh
__jonas|10 months ago
Don't think that's a very common thing to do, even in my hobby projects I would only access a Nerves device through a VPN.
giraffe_lady|10 months ago
rramadass|10 months ago
marioflach|10 months ago
https://git-scm.com/docs/protocol-v2
https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protoco...
Adding support for Git over SSH was very easy using Erlang built-in SSH libs.
https://github.com/redrabbit/git.limo
https://github.com/redrabbit/git.limo/blob/master/apps/gitgu...
qwertox|10 months ago
[0] https://github.com/processone/ejabberd/releases
toast0|10 months ago
I didn't think anyone actually ran the Erlang SSH daemon (although there's evidence that some people do!). It makes for a fun demo, but a regular OS shell is more useful, and you can attach a debug shell to an existing BEAM process from there.
aposm|10 months ago
jerf|10 months ago
While the Erlang/Elixir ecosystem won't stop you from writing a network server that takes in a string and just blithely passes it along to a shell without analysis, overall the Erlang/Elixir ecosystem is very strong and lacks most of the footguns like an "eval" statement that get people. Though I will ding it a point for the most obvious way to run a shell command [1] taking just a string that goes to a shell rather than an array of parameters to a shell command.
It is on the higher end of secure languages to write a network server in.
rramadass|10 months ago
You should definitely "sell" Elixir/Erlang/BEAM based languages to your management for a greenfield project; The opportunity is too good to pass up.
Nevertheless, if you would like to learn how to "harden" your Elixir/Erlang system, see the guidelines from the "Security Working Group" of EEF which i have linked to here - https://news.ycombinator.com/item?id=43717633
victorbjorklund|10 months ago
bilekas|10 months ago
WillPostForFood|10 months ago
r3tr0|10 months ago
https://yeet.cx
you can try our sandbox at https://yeet.cx/play
unknown|10 months ago
[deleted]
curtisszmania|10 months ago
[deleted]