Port 61616 – Apache ActiveMQ (OpenWire)

Port 61616 is the default port for OpenWire, the native binary transport protocol of Apache ActiveMQ — one of the most widely deployed open-source Java message brokers. OpenWire is the protocol ActiveMQ brokers and their JMS clients speak out of the box to publish and consume messages, so an open port 61616 almost always means a live ActiveMQ broker carrying real application traffic. ActiveMQ also listens on a set of sibling ports for other jobs — 8161 for the Jetty web console and Jolokia JMX-over-HTTP bridge, 61613 for STOMP, and 5672 for AMQP — but 61616 is where the broker’s core message flow lives, and it is the port behind one of the most heavily exploited remote-code-execution bugs of 2023–24.

Why It’s Open

ActiveMQ enables the OpenWire connector on 61616 by default, so the port is open on essentially every stock install. It is the message backbone for a huge range of Java systems — Spring/JMS applications, Apache Camel routes, Karaf and Fuse deployments, and countless in-house microservice queues — where producers and consumers connect over tcp://<broker>:61616. It sits in the same part of the stack as other message brokers you’ll meet on an internal network, such as Apache Kafka on 9093 and RabbitMQ’s AMQP listener on 5672. Because it is “just the queue,” it often ends up bound to 0.0.0.0 and reachable from more of the network than intended: a broker deliberately shared between services is easy to leave open to the whole subnet, or to the internet on a cloud VM. Combine that default-open transport with the fact that many ActiveMQ instances run old, unpatched broker builds, and 61616 becomes one of the highest-value ports on an internal network.

Common Risks

• Unauthenticated remote code execution (CVE-2023-46604). The OpenWire protocol on 61616 lets a remote, unauthenticated client force the broker to instantiate an arbitrary class and run shell commands. This is a 9.8/10.0-severity RCE that was mass-exploited by ransomware and cryptomining crews — the single biggest reason to treat an exposed 61616 as critical.
• Broker with no authentication. Many ActiveMQ deployments run OpenWire without authentication or authorization plugins enabled, so anyone who can reach 61616 can enumerate, publish to, and consume from queues and topics directly.
• Message interception and injection. Plain OpenWire is unencrypted. On the wire, message bodies and headers are readable and forgeable — an attacker on the path can sniff sensitive payloads or inject poisoned messages into a queue.
• Weak or default console credentials on 8161. The co-located web console and Jolokia bridge (separate port 8161) historically ship with admin/admin, and a foothold there leads to broker takeover and, on old builds, its own RCE paths.
• Old, unpatched broker builds. ActiveMQ has a long tail of installs years behind on patches, exposing the OpenWire RCE and older console/Fileserver bugs at the same time.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Confirm it is really an ActiveMQ OpenWire broker, pin the version (that decides which CVEs apply), then decide whether the RCE path is in play.

Detect the service and version

nmap -sV -p 61616 <target>

Nmap’s version probe fingerprints the OpenWire transport and, on many builds, reports the broker product and version straight from the handshake.

Grab the OpenWire handshake

nc -nv <target> 61616

On connect, an ActiveMQ broker sends an OpenWire WireFormatInfo command; the raw bytes typically leak the ActiveMQ magic and broker details, confirming the service even when version detection is inconclusive.

Check the co-located web console (separate port)

curl -sI http://<target>:8161/admin/

The admin console and Jolokia bridge live on 8161, not 61616. A 401/login prompt confirms the console is exposed — try the historical admin/admin default and check the version banner, since old builds carry their own RCE bugs. Some deployments reverse-proxy the console onto a generic web port, so also test any HTTP-alternate 8080 surface you find on the same host.

Test the OpenWire RCE (CVE-2023-46604)

msfconsole -q
use exploit/multi/misc/apache_activemq_rce_cve_2023_46604
set RHOSTS <target>
set RPORT 61616
run

This module abuses the OpenWire unmarshaller to make the broker load a ClassPathXmlApplicationContext from an attacker-hosted XML file and run commands via ProcessBuilder. Public Go and Python proof-of-concept scripts implement the same ClassPathXmlApplicationContext technique if you want to validate it without Metasploit.

Record every open 61616, the exact broker version, and any successful command execution as you go, 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 headline flaw on this port is an unauthenticated RCE in the OpenWire protocol itself; the other two well-known ActiveMQ bugs live on the 8161 web console, not on 61616, and are listed here only so they aren’t confused with the transport.

• CVE-2023-46604 — The Java OpenWire protocol marshaller in Apache ActiveMQ is vulnerable to remote code execution. A remote, unauthenticated attacker with network access to a Java-based OpenWire broker (or client) can run arbitrary shell commands by manipulating serialized class types so the broker instantiates any class on the classpath (CWE-502). CVSS 9.8 (NIST) / 10.0 (Apache) — this is the port-61616 vulnerability. It affects ActiveMQ before 5.15.16, 5.16.0–5.16.6, 5.17.0–5.17.5, and 5.18.0–5.18.2; fixed in 5.15.16, 5.16.7, 5.17.6, and 5.18.3. Weaponised in Metasploit as exploit/multi/misc/apache_activemq_rce_cve_2023_46604 (using the ClassPathXmlApplicationContext / Spring ProcessBuilder technique), with public Go and Python PoCs widely available.
• CVE-2022-41678 — Web console (port 8161), not OpenWire. An authenticated user of the Jolokia JMX bridge can abuse FlightRecorderMXBean to write a JSP webshell and achieve RCE. CVSS 8.8. Affects ActiveMQ below 5.16.6 and 5.17.0–5.17.3. Relevant only if the 8161 console/Jolokia endpoint is exposed and an attacker has console credentials.
• CVE-2016-3088 — Fileserver web app (port 8161), not OpenWire. The ActiveMQ Fileserver web application lets an unauthenticated attacker upload and execute arbitrary files via an HTTP PUT followed by MOVE. CVSS 9.8, and in CISA’s Known Exploited Vulnerabilities catalog. Affects 5.x before 5.14.0 (the Fileserver app was removed in 5.14.0). Only in play on old installs that still expose the console/Fileserver on 8161.

No fabricated or wrong-service CVEs were carried into this page: CVE-2022-41678 and CVE-2016-3088 are included but explicitly scoped to the 8161 console rather than mislabelled as OpenWire (61616) bugs.

Mitigation

• Patch to a fixed ActiveMQ build immediately. Upgrade to 5.15.16, 5.16.7, 5.17.6, 5.18.3, or later to close CVE-2023-46604 — this is the priority action for any exposed 61616.
• Firewall 61616 to the application hosts that actually connect. OpenWire should never be reachable from the internet or a broad internal subnet; restrict it to the specific producers and consumers.
• Enable authentication and authorization. Turn on ActiveMQ’s authentication (e.g. the JAAS/simple authentication plugin) and per-destination authorization so an open socket isn’t an open queue.
• Enable TLS on the transport. Use ssl:// OpenWire (or mutual TLS) so message bodies and headers can’t be sniffed or forged on the wire.
• Lock down the 8161 console separately. Change the default admin/admin credentials, bind the console to localhost or a management network, and patch it — remember its RCE bugs are independent of the OpenWire transport.
• Rescan to confirm. After firewalling or disabling connectors, re-run nmap -sV -p 61616,8161 <target> to verify only the intended surface is exposed.

Real-World Example

CVE-2023-46604 became one of the most aggressively exploited server bugs of late 2023. Within days of the October 2023 disclosure, internet-wide scanning for port 61616 turned into mass exploitation: HelloKitty ransomware operators used the OpenWire RCE to breach exposed brokers, while the Kinsing and TellYouThePass crews dropped cryptominers and ransomware through the same flaw, and researchers later tied Andariel (a Lazarus-linked North Korean group) to attacks abusing it. Because the exploit is a single crafted OpenWire packet that makes the broker fetch and instantiate an attacker-controlled Spring ClassPathXmlApplicationContext, and because a Metasploit module and public PoCs appeared almost immediately, any unpatched ActiveMQ with 61616 reachable was a point-and-click compromise. It is the cleanest recent illustration of why an exposed message-broker port is not “just infrastructure plumbing” — it can be a direct, unauthenticated path to code execution on the host.

FAQ

What is port 61616 used for?

Port 61616 is the default port for OpenWire, the native binary transport protocol of Apache ActiveMQ. Brokers and their JMS clients connect over tcp://<broker>:61616 to publish and consume messages, making it the core traffic port of an ActiveMQ deployment. Other ActiveMQ functions use different ports — 8161 for the web console and Jolokia, 61613 for STOMP, and 5672 for AMQP.

Why is port 61616 open on my server?

Because ActiveMQ enables the OpenWire connector on 61616 by default. If a Java application, Spring/JMS service, or Apache Camel route relies on ActiveMQ for messaging, the broker will be listening here. An unexpected open 61616 means an ActiveMQ broker is running — identify it and check whether it should be reachable from where you found it.

Is port 61616 dangerous?

The port is only as safe as the broker behind it. An ActiveMQ build patched against CVE-2023-46604, firewalled to its application hosts, and running with authentication and TLS is fine. An exposed, unpatched broker is critical: the OpenWire RCE gives an unauthenticated attacker code execution, and it was mass-exploited by ransomware and cryptomining groups in 2023–24.

How do I check whether my ActiveMQ is vulnerable to CVE-2023-46604?

Fingerprint the broker version with nmap -sV -p 61616 <target> or from the OpenWire handshake, then compare it against the fixed builds. Versions before 5.15.16, and 5.16/5.17/5.18 below 5.16.7 / 5.17.6 / 5.18.3 respectively, are vulnerable. To confirm exploitability safely, the Metasploit module exploit/multi/misc/apache_activemq_rce_cve_2023_46604 reproduces the attack in a controlled test.

What is the difference between port 61616 and port 8161?

61616 carries the OpenWire message transport — the actual queue and topic traffic. 8161 hosts ActiveMQ’s Jetty web administration console and the Jolokia JMX-over-HTTP bridge. They have distinct vulnerabilities: the OpenWire RCE (CVE-2023-46604) is a 61616 bug, whereas the Jolokia RCE (CVE-2022-41678) and the old Fileserver upload RCE (CVE-2016-3088) are 8161 console bugs.

How do I secure port 61616?

Patch ActiveMQ to a fixed release, firewall 61616 to only the hosts that connect, enable authentication and per-destination authorization, and switch the transport to TLS (ssl://). Secure the 8161 console separately by changing the default admin/admin credentials and keeping it off untrusted networks. Rescan afterwards to confirm only the intended surface is exposed.

TL;DR

• Service: Apache ActiveMQ OpenWire transport (native JMS message-broker protocol)
• Default port: 61616/TCP (console/Jolokia on 8161, STOMP on 61613, AMQP on 5672)
• Biggest risk: CVE-2023-46604 — unauthenticated OpenWire remote code execution (CVSS 9.8/10.0), mass-exploited by HelloKitty, Kinsing, TellYouThePass, and Andariel
• Mitigation: patch to 5.15.16 / 5.16.7 / 5.17.6 / 5.18.3+, firewall 61616 to app hosts, enable authentication and TLS, and lock down the 8161 console — capture findings in the pentest report