3 posts tagged with "security"

RabbitMQ is Not Affected by CVE-2025-32433​

RabbitMQ is not affected by CVE-2025-32433, a vulnerability in the Erlang's SSH library. RabbitMQ does not use SSH, neither the server nor the client parts.

Team RabbitMQ's Erlang Packages Do Not Include SSH​

Team RabbitMQ produces a zero dependency Erlang RPM that does not include the SSH library since it is not used. Our Debian packages are split into multiple fine-grained components, and the RabbitMQ installation guide skips SSH library installation.

Patched Versions Are Available​

Team RabbitMQ's RPM repositories and Debian repositories were updated to include Erlang 27.3.3, 26.2.5.11 and 25.3.2.20.

For aarch64 (64-bit ARM) RPM packages, see rabbitmq/erlang-rpm releases.

For aarch64 (64-bit ARM) Debian packages of Erlang 26.2.5.11, see this Launchpad repository.

RabbitMQ community Docker image was also upgraded to Erlang 27.3.3 and 26.2.5.11 last week.

Security Best Practices: epmd​

The Erlang Port Mapper Daemon (epmd) is a built-in component that helps Erlang-based applications (including RabbitMQ) discover each other’s distribution ports. Together with DNS for hostname resolution, epmd is a piece of infrastructure RabbitMQ nodes rely on for clustering, inter-node communication and CLI tools connectivity.

While epm is very limited in scope, its exposure to the public Internet often means that Erlang distribution ports are also exposed. This creates a potential security risk: if attackers find these distribution ports, they'd be one secret value away from being able to run CLI commands against the node (or cluster).

Recent scans have revealed over 85,000 instances of publicly accessible epmd, with roughly half associated with RabbitMQ servers.

Fortunately, all it usually takes to mitigate this risk is limiting network access to a range of ports. epmd and inter-node communication can also be limited to local network interfaces, in particular for single node clusters used for running tests.

Read the full article on the Erlang Ecosystem Foundation blog.

Today when we use the rabbitmq-management with the rabbitmq_auth_backend_oauth2 plugin, the only supported Authorization server is UAA, making it difficult to connect to other OAuth 2.0 servers. Additionally, rabbitmq-management plugin uses the OAuth 2.0 implicit flow which is no longer recommended for security reasons.

RabbitMQ 3.11 will support practically any Authorization server compliant with OpenID Connect and OAuth 2.0 protocols. Furthermore, OAuth 2.0 authorization code grant becomes the default grant and implicit grant is no longer supported.