⚠ Reference material — not professional advice. Test in staging, back up first, verify against your specific version. Use your own judgment for your environment.
● Critical · CVSS 10.0 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2023-46604: Apache ActiveMQ OpenWire Deserialization RCE

*By Sai Kiran Pandrala*

⚡ At a glance
SeverityCVSS 10.0 — Critical
Actively exploited?Yes, listed in CISA KEV (added 2023-11-02). Kinsing miners and HelloKitty ransomware both observed using it.
AffectedApache ActiveMQ and ActiveMQ Legacy OpenWire Module versions before 5.18.3, 5.17.6, 5.16.7, 5.15.16 (and any 5.18.x below 5.18.3)
Fixed inApache ActiveMQ 5.18.3, 5.17.6, 5.16.7, 5.15.16, or later
Type (CWE)CWE-502: Deserialization of Untrusted Data

⚠️ Patch now. Cryptominers and ransomware crews started mass-exploiting this within days of disclosure in October 2023. CISA's KEV listing is active.

What is CVE-2023-46604?

The OpenWire protocol marshaller in Apache ActiveMQ unsafely deserializes untrusted data sent by a client. A remote attacker who can reach the OpenWire port (TCP 61616 by default) can send a crafted message that causes ActiveMQ to instantiate an arbitrary Java class. The standard exploitation path uses org.springframework.context.support.ClassPathXmlApplicationContext to fetch a remote XML file and execute its directives, giving the attacker full remote code execution as the ActiveMQ service account.

The default ActiveMQ install ships the OpenWire transport on :61616, listening on all interfaces. Many production deployments expose this port to internal networks and a worrying number expose it directly to the internet.

Am I affected?

You are affected if you run any Apache ActiveMQ version below the fix line for your train:

The same fix applies to the Apache ActiveMQ Legacy OpenWire Module at the same version cutoffs.

To check your version:


# From the ActiveMQ install directory
./bin/activemq --version

# Or via JMX
curl -u admin:admin http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/BrokerVersion

Or look at the Web Console at http://<your-broker>:8161/admin/ — version is in the page header.

How to fix CVE-2023-46604

  1. Download the patched ActiveMQ release for your train from https://activemq.apache.org/download.html. Pick the smallest version jump that includes the fix (5.18.3 if you're on 5.18.x, etc.).
  1. Stop ActiveMQ cleanly so it drains in-flight messages:

   ./bin/activemq stop

For systemd-managed installs:


   sudo systemctl stop activemq
  1. Back up your data/ directory (KahaDB or LevelDB store) and your conf/ directory. These contain your persisted messages and broker configuration.
  1. Replace the install:

- Extract the new ActiveMQ tarball next to the old one (apache-activemq-5.18.3-bin/).

- Copy your existing conf/activemq.xml, conf/credentials.properties, and any custom configuration files into the new install's conf/.

- Copy your existing data/ directory in.

- Update your service unit file or wrapper script to point at the new install path.

  1. Start ActiveMQ and verify:

   ./bin/activemq start

Watch data/activemq.log for clean startup. Re-verify message store integrity by examining queue depths in the Web Console.

  1. For broker networks (cluster of brokers), upgrade one broker at a time. Drain a broker by stopping its listeners, let producers/consumers fail over to peers, upgrade, restart, return to the network.
  1. In containerized deployments (Docker/Kubernetes), pull the new image tag (e.g. apache/activemq-classic:5.18.3), update your manifest, roll the deployment.

If you can't patch immediately

Apache's advisory does not list a configuration-only workaround. The vulnerable deserialization is part of the core OpenWire transport handler. Compensating controls:

None of these remediate. Patch is the only fix.

How to verify the fix worked

  1. Confirm the version:

   ./bin/activemq --version

Should show 5.18.3 / 5.17.6 / 5.16.7 / 5.15.16 or later.

  1. Hunt for indicators of compromise from the exploitation window (October 27, 2023 to your patch date):

- Check the OS process tree under the ActiveMQ user for unexpected child processes. Kinsing drops a binary at /tmp/kinsing and similar paths.

- Search /tmp/, /var/tmp/, and the ActiveMQ install directory for unexpected executables, ELF binaries, or shell scripts dated after October 27, 2023.

- Review crontabs for the ActiveMQ user and root, Kinsing installs persistence via cron.

- Check outbound network connections from the ActiveMQ host. C2 traffic to known Kinsing/HelloKitty infrastructure is documented in vendor IoC feeds.

  1. If anything looks wrong, do not just remove the binary. Take a forensic image, then rebuild the host from scratch. RCE-as-service-account on a message broker that holds production credentials is an organization-wide incident.

Frequently asked questions

Other vulnerabilities in the same area that are worth patching alongside this one:

Is CVE-2023-46604 still being exploited?

Yes. Kinsing cryptojacking and HelloKitty ransomware both maintain ActiveMQ targeting in their toolkits. Public exploit code (Metasploit module, standalone Python scripts) is widely available. Any unpatched, network-reachable ActiveMQ broker should be assumed at high risk.

My broker is internal-only, is it safe?

You are less exposed but not safe. An attacker who has any foothold on an internal host that can talk to the broker can chain to RCE. Internal-only systems still get patched.

Does this affect ActiveMQ Artemis?

No. The vulnerable code is in ActiveMQ Classic (formerly known as just ActiveMQ). ActiveMQ Artemis uses a different OpenWire implementation and is not affected by CVE-2023-46604. Confirm by checking which product you actually run.

References

*This guide was assembled from the official Apache ActiveMQ advisory, NVD record, and CISA KEV listing on 2026-05-25. Always confirm against the Apache advisory before applying changes in production.*