inet_gethost execution with spaces in path fails on Windows - perhaps related to OTP-17958

According to the release notes for 23.3.3, OTP-17958 addressed the following:

erlang:open_port({spawn, },) has been fixed on Windows to handle whitespace characters in the path correctly.

This could, for example, cause execution of the resolver helper program inet_gethost to fail and instead possibly execute a different program.

I noticed a similar issue with RabbitMq - and not knowing the source of the issue, reported it there, where it was closed. The response seems to indicate this is likely an issue with Erlang similar to the above mentioned resolved bug. I have reposted a summary of the contents of said issue below:

I first noticed this in RabbitMq 3.9.7 and it persists in 3.9.16, when running against Erlang 24.3.2 and 24.3.3, on Windows, where there are spaces in the path to ERLANG_HOME. I do not know if this is related to RabbitMq or Erlang, however, Erlang 24.3.3 mentions a bugfix for OTP-17958 which addressed the following:

erlang:open_port({spawn, },) has been fixed on Windows to handle whitespace characters in the path correctly.

To see the error I am referring to, if you execute the following (with spaces to your erlang installation):
rabbitmqctl.bat 2>c:\error_output.txt await_startup
and view the file created (c:\error_output.txt), you will see the following:

C:\Program: Unknown option "Files\Redacted\Erlang\erts-12.3.1\bin\inet_gethost.exe"
Usage: C:\Program [-d [-d ...]] [-g <greedy threshold>] [<number of workers>]

The command appears to work as intended if you are just looking at the standard output stream if you used the command on the console without error output redirection. Similar output can be seen with the list_users argument. The other batch files I typically use: rabbitmq-plugins.bat and rabbitmq-service.bat, do not have such error stream output.

Something in the workflow of the batch file is attempting to execute inet_gethost. The only mention to ‘inet_gethost’ that I can find in the RabbitMq source code is in rabbit_networking.erl as a comment before calling inet_parse:address.

Obviously, this is an issue with not quoting the path properly, like as specified in the OTP issue quoted above. Likewise, this is a relatively mild or moderate security issue as if someone used the default Erlang path and was already able to have permissions to add a file “C:\program.exe”, it could be executed with the callers permissions (requiring the actor to previously been on the other side of the ‘airtight hatchway’).

If this is an issue with Erlang - I don’t know the appropriate way to report an issue other than perhaps this forum post.


Running Erlang from a directory with space should not be a problem. I can’t speak for if RabbitMQ can.

We did some other fixes in this area that are part of the next major release of Erlang. I’m not sure if RabbitMQ works with Erlang/OTP 25 yet, but it would be great if you could try Erlang/OTP 25.0-rc3 and see if that solved the problem.

If the problem remains and you want to keep digging, the next step would be to remove RabbitMQ out of the equation and see if you can reproduce the error.

When Erlang starts it always prepends the path to where inet_gethost.exe is to the path of the VM. So there is no way an attacker could place something in the path that we would pick up instead of inet_gethost.


Thank you for your reply, @garazdawi. I confirmed that adding a C:\Program.exe does not get called here as you said. Unfortunately, the RabbitMq command line tools don’t work with Erlang/OTP 25 yet, so I can’t confirm if this behavior is resolved. It is a relief to know that this is not an issue, however.


It still reproduces with latest 3.9.x RabbitMQ (3.9.22) and 24.x Erlang (

@StevenBone did you opened an issue for RabbitMQ?

1 Like