How to Fix ActiveMQ Default Credentials on the Web Console (Nessus 81375)

Apache ActiveMQ Web Console Default Credentials means a scanner logged in to the broker’s Jetty-hosted console (TCP 8161, /admin) with a shipped account such as admin/admin. Fix it by replacing the default accounts in conf/jetty-realm.properties (ActiveMQ 5.x) or conf/users.properties (6.x), binding the console to 127.0.0.1 or firewalling port 8161, and restarting the broker.

What the scanner is actually detecting

This is a remote check that ends in a real login. Nessus first has to identify an ActiveMQ installation, then it tries default credentials against the console’s HTTP Basic authentication and reports only if one is accepted. It does not read your configuration files.

Tenable’s plugin metadata adds three details that matter later: it needs the ActiveMQ install to be detected (installed_sw/Apache ActiveMQ), and it is skipped when CGI scanning is disabled or when the policy is limited to user-supplied credentials (global_settings/supplied_logins_only). Tenable also notes the history: the console had no authentication before 5.4.0, got optional Basic authentication in 5.4.0, and has had it on by default since 5.8.0. The plugin output in your report shows which account worked.

Where the accounts live depends on the release line. The table below is taken from the default conf directory of each release in the Apache ActiveMQ source tree:

So a hit on a 5.16 or later broker usually means someone widened the bind address, or a reverse proxy publishes the console, and never changed the password.

Real-world risk

The scanner proved the login works, so treat it as a real exposure. With the admin role, anyone can browse message contents (which often carry business data or tokens), send forged messages into queues that applications trust, and purge or delete queues and topics. In 5.x the user role can open the console pages, including queue browsing; only the *.action URLs require admin.

The bigger issue is the Jolokia JMX bridge at /api/jolokia, which sits behind the same login. Apache has published two authenticated code execution flaws in it: CVE-2022-41678 (fixed by a stricter Jolokia policy in 5.16.6, 5.17.4, 5.18.0 and 6.0.0) and CVE-2026-34197 (fixed in 5.19.4 and 6.2.3). CISA added CVE-2026-34197 to its Known Exploited Vulnerabilities catalog on April 16, 2026 (see how the CISA KEV catalog works). On an unpatched broker, a default password is therefore a path to code execution as the broker’s service account.

Exposure decides urgency. A console reachable from the internet belongs at the top of your external attack surface list; a loopback-only console is a much smaller problem, but still worth fixing.

How to confirm it on the host

On Linux, find the configuration directory of the running broker and check what port 8161 is bound to:

ps -ef | grep -o 'activemq.conf=[^ ]*'
sudo ss -ltnp 'sport = :8161'

0.0.0.0:8161 or *:8161 means all interfaces. Then list the active accounts and the relevant Jetty settings (set CONF to the path found above):

CONF=/opt/activemq/conf
grep -vE '^s*(#|$)' "$CONF/jetty-realm.properties"                        # 5.x
grep -vE '^s*(#|$)' "$CONF/users.properties" "$CONF/groups.properties"    # 6.x
grep -n 'name="authenticate"' "$CONF/jetty.xml"
grep -n -A3 'id="jettyPort"' "$CONF/jetty.xml"

On Windows (adjust the installation path):

Get-Service ActiveMQ
Get-NetTCPConnection -LocalPort 8161 -State Listen | Select-Object LocalAddress, OwningProcess
Select-String -Path "C:apache-activemqconfjetty-realm.properties" -Pattern '^s*[^#s]'

Finally, reproduce the login from the scanner’s network with the pair from the plugin output:

curl -s -o /dev/null -w '%{http_code}n' -u admin:admin http://mq01.example.com:8161/admin/

200 confirms the finding and 401 means the credentials were rejected. On Windows use curl.exe and -o NUL.

How to fix it

Back up the configuration first: sudo cp -a "$CONF" "$CONF.bak-$(date +%F)".

ActiveMQ 5.x: edit jetty-realm.properties

The format is username: password [,rolename ...]. Delete the admin: admin, admin and user: user, user lines and add named accounts with long random passwords (for example from openssl rand -hex 24). Keep the role names, because the adminSecurityConstraint in jetty.xml requires admin:

mq-ops-admin: LONG_RANDOM_VALUE_1, admin
mq-viewer: LONG_RANDOM_VALUE_2, user

Then limit who can read the file (use the account the broker runs as):

sudo chown activemq: "$CONF/jetty-realm.properties"
sudo chmod 600 "$CONF/jetty-realm.properties"

ActiveMQ 6.x: edit users.properties and groups.properties

The 6.x console authenticates through JAAS, so the account goes in users.properties and the admin rights come from the admins group:

# users.properties
mq-ops-admin=LONG_RANDOM_VALUE_1

# groups.properties
admins=mq-ops-admin

Check whether the broker also authenticates messaging clients against these files before you rename or remove admin:

grep -n 'jaasAuthenticationPlugin' "$CONF/activemq.xml"

Make sure authentication is on

In jetty.xml (5.x and 6.0 to 6.2), both the securityConstraint and adminSecurityConstraint beans must contain <property name="authenticate" value="true" />. If either says false, the console does not ask for a password at all.

Restrict network exposure

Bind the console to loopback in the jettyPort bean of jetty.xml (the 5.16 and later default) and reach it through an SSH tunnel such as ssh -L 8161:127.0.0.1:8161 admin@mq01:

<bean id="jettyPort" class="org.apache.activemq.web.WebConsolePort" init-method="start">
    <property name="host" value="127.0.0.1"/>
    <property name="port" value="8161"/>
</bean>

Very old releases without a jettyPort bean are long out of support and should be upgraded. If remote access is required, allow only an admin subnet at the host firewall:

# firewalld
sudo firewall-cmd --permanent --remove-port=8161/tcp
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.20.30.0/24" port port="8161" protocol="tcp" accept'
sudo firewall-cmd --reload

# ufw
sudo ufw allow from 10.20.30.0/24 to any port 8161 proto tcp
sudo ufw deny 8161/tcp

On Windows, look for broad inbound rules that allow the Java runtime, which are often created when Java first listens on a port, and replace them with a scoped rule:

Get-NetFirewallRule -Direction Inbound -Enabled True | Where-Object DisplayName -like '*Java*'
New-NetFirewallRule -DisplayName "ActiveMQ console (admin subnet)" -Direction Inbound -Protocol TCP -LocalPort 8161 -RemoteAddress 10.20.30.0/24 -Action Allow

Or disable the console

If nobody uses the console, REST API or Jolokia, comment out <import resource="jetty.xml"/> in conf/activemq.xml (jetty-spring.xml on 6.3 and later). This removes port 8161 entirely.

Restart and patch

xmllint --noout "$CONF/jetty.xml" "$CONF/activemq.xml"
sudo "$ACTIVEMQ_HOME/bin/activemq" restart     # tarball install; use your systemd unit if you created one
Restart-Service ActiveMQ                        # Windows service installed by binwin64InstallService.bat

A strong password does not fix CVE-2026-34197 for people who legitimately log in, so also move to at least 5.19.4 or 6.2.3, preferably the current release on your branch.

How to verify the fix and rescan

1. Repeat the curl test with admin:admin (and user:user on 5.x): expect 401, or a refused connection if the console is no longer reachable.
2. Run ss -ltn 'sport = :8161' and confirm the listener shows 127.0.0.1:8161 if you rebound it.
3. Log in with the new account through the tunnel or from the admin subnet to confirm legitimate access works.
4. Rescan with the same policy, not limited to user-supplied credentials. If the scanner can no longer reach 8161, plugin 81375 will not run at all; that is expected, but test the old password locally against http://127.0.0.1:8161/admin/ so the clean scan is not the only proof.

What can break and how to roll back

• Monitoring and scripts. Anything calling /api/jolokia or the REST API with admin/admin (health checks, dashboards, queue depth scripts) starts getting 401 until you update its stored credentials.
• Messaging clients on 6.x. If jaasAuthenticationPlugin is enabled, users.properties also controls broker logins, so renaming admin can break producers and consumers.
• Remote administrators. Binding to 127.0.0.1 or disabling the console removes browser access from other machines.
• Startup failures. jetty.xml is imported into the broker’s Spring context, so a malformed edit can stop the broker from starting.

To roll back, restore the backed-up conf directory and restart the broker.

Common false positive reasons

True false positives are rare because the plugin reports a successful login. Most disputes are about attribution (see our list of vulnerability scanner false positive causes):

• Wrong instance. Several brokers run on the host with separate activemq.base directories, and you edited the wrong one.
• Change not loaded. The file was edited but the broker was not restarted.
• Something in front. A reverse proxy or load balancer forwards the port to another broker that still has the default account.
• Authentication switched off. With authenticate set to false, the console accepts requests without checking the password, so any credential test succeeds. The finding is real: turn authentication back on.
• Bundled broker. A vendor product embeds ActiveMQ with its own console defaults; the fix belongs in the vendor’s configuration and may be overwritten by upgrades.

FAQ

What are the default ActiveMQ web console credentials?

admin/admin in every release since authentication was enabled by default. Many 5.x releases also ship user/user in jetty-realm.properties.

Is binding the console to 127.0.0.1 enough?

No. It removes remote exposure, but local users, SSH tunnels and a proxy on the same host can still reach it. Change the password as well.

Does changing the console password affect client applications?

On 5.x, no: jetty-realm.properties is only used by the web server. On 6.x it can, if the broker’s JAAS plugin reads the same users.properties.

Do I still need to upgrade after changing the password?

Yes. CVE-2026-34197 lets any authenticated user run code through Jolokia on releases before 5.19.4 and 6.2.3.

Tracking this finding across many hosts

Default console accounts tend to come back when brokers are rebuilt from old images or copied configuration. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results by uploading a .nessus export) and merges duplicates within each scanner, so plugin 81375 can be followed host by host. Nessus findings can be retested individually, and AI-written, host-specific remediation scripts run through human approval before its agents deploy them on Windows or Linux, followed by a re-test to confirm closure.

Sources

• Tenable: Apache ActiveMQ Web Console Default Credentials (plugin 81375)
• Apache ActiveMQ Classic: Web Console (securing the console)
• Apache ActiveMQ 5.19.11 default conf/jetty.xml and 6.2.10 default conf/jetty.xml
• Apache ActiveMQ security advisory: CVE-2026-34197 (Jolokia code injection)
• CISA Known Exploited Vulnerabilities Catalog