Port 5672 – AMQP (RabbitMQ)

Port 5672 is the default port for AMQP — the Advanced Message Queuing Protocol — the wire protocol that applications use to hand work to a message broker and pull it back off again. The overwhelmingly dominant implementation is RabbitMQ, so an open port 5672 in practice almost always means a RabbitMQ broker (or a compatible broker such as Apache Qpid) sitting between an application’s producers and consumers, shuttling jobs, events, and data through queues and exchanges. That makes it a high-value target: the broker is a central pipe that the whole application depends on, and the messages flowing through it routinely carry job payloads, internal API calls, credentials, and personal data. Get onto the broker and you can read that traffic, inject your own messages, drain queues, or simply break the application by tearing the pipe down.

Why It’s Open

Port 5672 is open because something needs a message broker. Modern applications decouple their components with a queue — a web tier drops a “send this email” or “process this upload” job onto a queue, and a pool of workers picks it up asynchronously. RabbitMQ is the default choice for that pattern across huge swathes of the Django/Celery, Node, Spring, and .NET ecosystems, and it listens on 5672 for AMQP 0-9-1 out of the box. It sits in the same architectural role as an event-streaming platform like Apache Kafka on 9093 or another JMS broker like Apache ActiveMQ on 61616, and it’s often deployed right alongside a datastore such as PostgreSQL on 5432 that the same workers read from and write to.

It helps to understand the RabbitMQ port trio, because they show up together and each is a different attack surface:

• 5672/TCP – AMQP (plaintext). The main broker protocol. Producers and consumers connect here.
• 5671/TCP – AMQPS (AMQP over TLS). The encrypted equivalent of 5672; you’ll see it where someone has bothered to wrap the broker in TLS.
• 15672/TCP – Management plugin (HTTP UI + REST API). An optional-but-extremely-common web console and HTTP API for browsing and managing the broker. This is frequently the easiest way in.

An open 5672 usually means the broker was meant to be reached only by the app’s own workers on a trusted network — but security groups, container port mappings, and 0.0.0.0 binds routinely expose it far wider than intended.

Common Risks

• Default guest/guest credentials. RabbitMQ ships with a built-in guest account whose password is guest. Modern versions restrict that account to loopback (localhost) connections by default, but operators very frequently loosen loopback_users to get things working — or run an older build — leaving guest/guest usable over the network. Authenticate with it and the broker is yours.
• Cleartext protocol on 5672. Plain AMQP has no encryption. Credentials and every message body travel in the clear, so anyone on the path can sniff logins and payloads unless the deployment uses AMQPS on 5671 instead.
• Sensitive data inside messages. Queues and exchanges routinely carry job data, internal tokens, session identifiers, and PII. Read access alone can be a serious breach.
• Message injection and queue draining. With broker access you can publish forged messages (triggering whatever the workers do with them), consume/basic_get messages other consumers were supposed to process, or purge queues — corrupting or halting the application logic that depends on the broker.
• Exposed management plugin on 15672. The management UI/API defaults to the same guest/guest account. Over HTTP it lets you browse vhosts, queues, exchanges, connections, and even publish and get messages from a browser — an easy win that needs no AMQP client at all.
• Availability is the whole point. The broker is a single dependency for asynchronous work. A DoS against it (see CVEs below) or a purged queue can stall an entire application.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The two surfaces worth probing are the AMQP broker on 5672 and the management HTTP API on 15672. Start by fingerprinting the broker, then try the default account against both.

Detect the service and version

Nmap ships a real AMQP script, amqp-info, that negotiates a connection and reports the product, version, and server capabilities:

nmap -sV -p 5672 --script amqp-info <target>

The output names the broker (RabbitMQ), its version, and the advertised auth mechanisms — enough to line up the version-specific CVEs below.

Version and login scanners in Metasploit

Metasploit has dedicated AMQP modules (both real, in the rapid7/metasploit-framework tree):

msfconsole -q
use auxiliary/scanner/amqp/amqp_version
set RHOSTS <target>
run

use auxiliary/scanner/amqp/amqp_login
set RHOSTS <target>
set USERPASS_FILE /usr/share/wordlists/...
set STOP_ON_SUCCESS true
run

amqp_version fingerprints the broker; amqp_login brute-forces credentials (start with guest/guest).

Hit the management API on 15672

If the management plugin is enabled, its REST API answers over HTTP with basic auth — try the default account first:

# Broker overview: version, node, listeners
curl -s -u guest:guest http://<target>:15672/api/overview | jq

# Every queue, with message counts
curl -s -u guest:guest http://<target>:15672/api/queues | jq

# Virtual hosts you can reach
curl -s -u guest:guest http://<target>:15672/api/vhosts | jq

A 200 with real JSON confirms both that the plugin is exposed and that the credentials work.

Browse and drain queues with rabbitmqadmin

rabbitmqadmin is the CLI shipped with the management plugin (downloadable straight from the console at http://<target>:15672/cli/):

rabbitmqadmin -H <target> -u guest -p guest list queues name messages
rabbitmqadmin -H <target> -u guest -p guest get queue=<queue> count=5

Read a message over raw AMQP with Python pika

To prove broker access at the protocol level rather than through the plugin, connect with pika (the standard Python AMQP client) and pull a message:

import pika

creds = pika.PlainCredentials("guest", "guest")
conn = pika.BlockingConnection(pika.ConnectionParameters("<target>", 5672, "/", creds))
ch = conn.channel()

method, props, body = ch.basic_get(queue="<queue>", auto_ack=False)
print(body)          # message payload — often job data, tokens, or PII

Record every open 5672/15672, the broker version, the accounts that authenticated, and any sensitive queue contents you confirm, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The honest headline on port 5672 is that the dominant risk is misconfiguration — default guest/guest credentials and an over-exposed broker or management plugin — not a single dramatic remote-code-execution CVE. RabbitMQ has a solid security record; the named CVEs that exist are mostly authenticated denial-of-service and management-UI cross-site-scripting bugs, and they only matter once you already know the version. Verify each against its NVD record and scope it to the version you fingerprinted before you rely on it:

• CVE-2021-22116 — RabbitMQ before 3.8.16 is prone to a denial of service caused by improper input validation in the AMQP 1.0 client connection endpoint; a crafted message can crash the broker where the AMQP 1.0 plugin is enabled. CVSS 7.5 (High). This is the most directly AMQP-relevant of the set.
• CVE-2015-8786 — The management plugin in RabbitMQ before 3.6.1 lets a remote authenticated user cause a denial of service (resource consumption) via the lengths_age or lengths_incr parameter. CVSS 6.5 (Medium). It affects the 15672 surface, not the AMQP wire protocol.
• CVE-2019-11281 — A stored cross-site scripting flaw in the RabbitMQ (Pivotal) management UI before 3.7.18: an authenticated administrator can plant script through the virtual-host limits and federation-management pages. CVSS 4.8 (Medium). Again a management-console bug, requiring admin access.

Note that none of these is an unauthenticated RCE — the realistic kill chain on 5672/15672 is “reach the broker, log in with guest/guest or brute-forced creds, then read, inject, or drain,” not “fire a public exploit.” Treat exposure and weak credentials as the primary finding and the CVEs as version-dependent add-ons.

Mitigation

• Delete or lock down the guest account. Remove it, or set a strong unique password, and keep loopback_users at its default so guest can never connect over the network. Provision per-application accounts with least-privilege permissions on specific vhosts.
• Never expose 5672 or 15672 to untrusted networks. Bind the broker to internal interfaces, and firewall both ports to the workers and operators that actually need them. Audit cloud security groups and container port maps for an accidental 0.0.0.0:5672 / :15672.
• Use TLS. Move traffic to AMQPS on 5671 so credentials and message bodies aren’t sniffable, and require client certificates for high-value brokers.
• Restrict the management plugin. If you don’t need the UI, disable it; if you do, put it behind authentication with real accounts, TLS, and an IP allowlist — not guest/guest over plain HTTP.
• Keep RabbitMQ current. Patch to a supported release to clear the DoS/XSS CVEs above and disable AMQP protocol plugins (AMQP 1.0, MQTT, STOMP) you aren’t using to shrink the attack surface.
• Segment and monitor. Put the broker on an internal tier, alert on unexpected connections and authentication failures, and treat any external connection to 5672/15672 as an incident.

Real-World Example

The canonical way RabbitMQ gets popped needs no CVE at all: a broker reachable from the internet (or from an attacker who has already landed a foothold in the network) with the guest/guest account still usable. The default account is only meant to be restricted to localhost, but the loopback_users = none configuration that operators paste in to “make it work” — or an older/embedded build that never had the restriction — puts guest/guest back in play over the network. From there the management API on 15672 is the quiet way in: curl -u guest:guest http://target:15672/api/queues enumerates every queue and its message count in one request, and the same console lets an attacker get messages other consumers were meant to process — job payloads, password-reset tokens, PII — and publish forged messages that the application’s workers then act on. It is the same lesson that recurs across exposed data-plane services like Redis on 6379 and MongoDB on 27017: the software is fine, but a central store reachable with a default credential hands over everything flowing through it. Capturing that exposure, the working credential, and a sample of the sensitive queue contents in a structured pentest report is what turns it into a fix.

FAQ

What is port 5672 used for?

Port 5672 is the default port for AMQP (Advanced Message Queuing Protocol) 0-9-1, the protocol applications use to talk to a message broker. In practice it is almost always RabbitMQ: a web tier or service publishes jobs and events to queues and exchanges on 5672, and worker processes consume them asynchronously. It’s the plumbing that lets components hand work to each other without calling one another directly.

What is the difference between ports 5672, 5671, and 15672?

They’re the RabbitMQ trio. 5672 is plaintext AMQP — the main broker protocol. 5671 is AMQPS, the same protocol wrapped in TLS for encryption. 15672 is the optional management plugin’s HTTP web UI and REST API, used to browse and administer the broker. Each is a separate service and a separate thing to secure; 15672 in particular is often the easiest target because it defaults to the same guest account.

Is it dangerous to leave port 5672 open?

To an untrusted network, yes. Plain AMQP is unencrypted, so credentials and message bodies can be sniffed, and the built-in guest/guest account is frequently reachable through misconfiguration. An exposed broker lets an attacker read the job data and secrets flowing through your queues, inject forged messages, or drain queues to break the application. The broker should be reachable only by the workers and operators that need it.

What are the default RabbitMQ credentials?

guest / guest. Recent RabbitMQ versions only allow that account to connect from localhost by default, but operators often relax the loopback_users setting to make remote clients work — and older or embedded builds never had the restriction — so guest/guest over the network is a very common finding. Delete the account or give it a strong password and keep it loopback-only.

How do I check what’s running on port 5672?

Fingerprint it with Nmap’s AMQP script — nmap -sV -p 5672 --script amqp-info <host> — which reports the broker product, version, and auth mechanisms. Metasploit’s auxiliary/scanner/amqp/amqp_version does the same, and if the management plugin is up you can confirm access with curl -u guest:guest http://<host>:15672/api/overview. A RabbitMQ banner plus a working guest login is your cue to keep digging.

Does port 5672 have a critical RCE vulnerability?

Not really — that’s the honest answer. RabbitMQ’s named CVEs are mostly authenticated denial-of-service and management-UI cross-site-scripting issues (for example CVE-2021-22116, CVE-2015-8786, CVE-2019-11281), and they depend on the exact version. The realistic risk on 5672 is misconfiguration: default credentials, no TLS, and a broker or management plugin exposed to networks it shouldn’t be.

TL;DR

• Service: AMQP 0-9-1 message broker — almost always RabbitMQ (5672 AMQP, 5671 AMQPS/TLS, 15672 management UI + REST API)
• Default port: 5672/TCP (plus 5671/TCP for AMQPS and 15672/TCP for the management plugin)
• Biggest risk: default guest/guest credentials on an over-exposed broker or management plugin — read, inject, or drain messages (job data, tokens, PII) and disrupt the app; the risk is misconfiguration, not a single RCE CVE
• Mitigation: remove/secure the guest account and keep it loopback-only, firewall 5672/15672 to internal clients, use AMQPS on 5671, restrict or disable the management plugin, and patch to a supported release