Protect the RabbitMQ Erlang cookie

The fix

# A strong cookie, identical on every node, readable only by rabbitmq
openssl rand -base64 42 | tr -d '\n' | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
sudo systemctl restart rabbitmq-server

Why it matters

Erlang nodes authenticate to each other with a shared secret called the cookie — a string in ~/.erlang.cookie for the account running the node (/var/lib/rabbitmq/.erlang.cookie for RabbitMQ). Two nodes with the same cookie trust each other; two with different cookies can’t cluster.

The critical part: Erlang node-to-node trust is total. Once a node authenticates with the right cookie, the distribution protocol lets it evaluate arbitrary code on the other node. That’s not a vulnerability — it’s how Erlang clustering is designed to work, and it’s extremely powerful.

Which means the cookie is not a clustering detail. It is the credential that grants code execution as the rabbitmq user to anyone who has it and can reach the distribution port (25672).

Two failures make that catastrophic:

• A weak or default cookie. Some packages and container images generate a predictable cookie, or people set a memorable one like SECRET_COOKIE. An attacker who can reach 25672 and guess or know the cookie connects an Erlang node and runs commands.
• A world-readable cookie file. If any local user can read /var/lib/rabbitmq/.erlang.cookie, a compromise of any account on the host escalates to the RabbitMQ node — and, on a cluster, to every node sharing it.

Generate a strong one, lock the file

The cookie should be long and random:

openssl rand -base64 42 | tr -d '\n'

And the file must be readable only by the RabbitMQ user:

sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie

400 matters. A 644 cookie file is the same class of problem as a world-readable private key: the secret is present but unprotected.

Every node, identical; between clusters, different

On a cluster, every node must have the exact same cookie — that’s what lets them trust each other. Distribute it over a secure channel (configuration management with an encrypted secret, not a copy-paste in Slack), and never commit it to a repository.

Separate clusters should have different cookies. A shared cookie across unrelated brokers means compromising one gives code execution on all of them — turning a blast radius you thought was one broker into your whole messaging estate.

Containers are the common trap: a RABBITMQ_ERLANG_COOKIE environment variable is visible in docker inspect, in the process environment, and often in the image’s build history. Prefer a mounted file with correct permissions over the env var.

Verify it worked

Check the file’s permissions and ownership — this is the local half:

sudo ls -l /var/lib/rabbitmq/.erlang.cookie

Expect -r-------- (400) owned by rabbitmq. Anything world- or group-readable is a finding.

Check it isn’t the default or a weak value — length is a quick proxy:

sudo wc -c /var/lib/rabbitmq/.erlang.cookie

A short cookie (a dozen characters, or a recognisable word) is guessable. A strong one is 40+ random characters.

Confirm it isn’t leaking through the environment:

sudo strings /proc/$(pgrep -f rabbitmq | head -1)/environ 2>/dev/null | grep -i cookie
docker inspect <container> --format '{{json .Config.Env}}' 2>/dev/null | grep -i cookie

Any output means the cookie is readable from the process environment — move it to a mounted file.

Then confirm the distribution port isn’t the thing that makes this exploitable — from another host it must be unreachable:

nc -zv -w5 your.broker 25672 2>&1 | tail -1

A refusal or timeout is the goal. A reachable 25672 plus a weak cookie is the RCE; closing either closes the attack.

Before you apply this

Changing the cookie breaks clustering until every node has the new one, and a node with the wrong cookie cannot rejoin — it starts but stays isolated, and the symptom is a node that’s “up” but not in the cluster.

On a single node, changing the cookie is low risk: stop the broker, write the new cookie, start it. Nothing else uses it.

On a cluster, it’s a coordinated operation:

1. Stop all nodes. The cluster cannot run half-migrated — mismatched cookies partition it.
2. Write the identical new cookie to every node, chmod 400, chown rabbitmq.
3. Start the nodes.

Doing it rolling — one node at a time — does not work, because a node with the new cookie can’t talk to nodes still on the old one. This is one of the few changes on the whole site that genuinely requires full downtime, so schedule it.

Don’t leave the default cookie in place because rotating it is inconvenient. If the broker was ever exposed on 25672 with a default or weak cookie, treat it as compromised: an attacker with the cookie had code execution as rabbitmq, which can read every message, every credential in the broker, and pivot to the host. Rotate the cookie, and check the host for persistence the way you would after any RCE.

Related

• Restrict network listeners — close 25672 so the cookie can’t be used remotely.
• RabbitMQ exposed to the internet — the full chain.