When a CVSS 10.0 vulnerability is published, the expectation is that affected software gets patched within days. When it involves an open-source broker that processes business-critical transactions in enterprise environments, the expectation is that the security teams responsible for those brokers treat it as an emergency.
“The attacks exploit a maximum-severity security flaw in Apache ActiveMQ (CVE-2023-46604, CVSS score: 10.0), a remote code execution vulnerability that could be exploited to run arbitrary shell commands.” [Source]
The reality, documented by Red Canary in August 2025, is different. Nearly two years after the patch was published, threat actors are still finding unpatched Apache ActiveMQ® brokers on cloud Linux systems and exploiting CVE-2023-46604 to gain initial access.
They then establish multiple layers of persistence. Finally, in a tactic that makes this campaign particularly notable, they apply the official Apache patch to the compromised broker to lock out competing threat actors and make the intrusion harder to detect.
“Red Canary researchers observed attackers exploit a 2-year-old Apache ActiveMQ vulnerability, tracked as CVE-2023-46604 (CVSS score of 10.0), to gain persistence on cloud Linux systems and deploy DripDropper malware. Uniquely, they patch the flaw post-exploit to block rivals and evade detection.” [Source]
This post covers what this Apache ActiveMQ® CVE is, exactly how the DripDropper attack chain works, why the post-exploitation patching tactic matters, how to verify your broker’s patch status, and which controls you need beyond patching alone.
What the Apache ActiveMQ® security advisory for CVE-2023-46604 says
| Field | Detail |
| CVE ID | CVE-2023-46604 |
| CVSS score | 10.0 Critical (maximum possible) |
| Published | October 25, 2023 |
| Affected versions | Apache ActiveMQ® Classic 5.x ≤ 5.18.2; Apache Artemis™ ≤ 2.31.1 |
| Fix versions | Apache ActiveMQ® Classic 5.15.16 / 5.16.7 / 5.17.6 / 5.18.3; Apache Artemis™ 2.31.2 |
| Exploited in the wild | Yes, actively, including the August 2025 DripDropper campaign |
What the vulnerability does
CVE-2023-46604 exploits a flaw in the Apache ActiveMQ® OpenWire protocol implementation. OpenWire is the native binary protocol of Apache ActiveMQ®, running on TCP port 61616 by default. It is the same port that JMS producers and consumers use to connect.
The vulnerability lets an unauthenticated attacker who can reach port 61616 send a specially crafted ExceptionResponse ClassInfo command. This command makes the broker deserialize the attacker-supplied class descriptor and fetch a remote ClassPathXmlApplicationContext, loading a Spring XML configuration file from an attacker-controlled server.
When the Spring context initializes, every Spring bean defined in that XML is instantiated, allowing arbitrary OS command execution with the privileges of the broker process.
No authentication is required. Any network path to port 61616 is enough for exploitation, including direct internet exposure, a compromised VPN, or a compromised system in the same network segment. The attack succeeds in milliseconds.
The severity is 10.0 not as a conservative worst-case estimate but because every element of the attack is maximally severe: unauthenticated, remote, and complete system compromise without any user interaction.
EPSS score: 94.44%
“Despite being nearly three years old, this vulnerability maintains a 94.44 percent likelihood of exploitation according to its EPSS score, making it an attractive target for cybercriminals.” [Source]
The EPSS (Exploit Prediction Scoring System) score reflects the empirically observed exploitation frequency of this CVE relative to all other known vulnerabilities. A score of 94.44% means CVE-2023-46604 is currently being exploited more actively than 94.44% of all known vulnerabilities. For context, the average CVSS 10.0 vulnerability is not automatically exploited at high frequency, and many sit dormant. CVE-2023-46604 is at the opposite end of that distribution.
This score, combined with two years of available patch time, makes the continued presence of unpatched Apache ActiveMQ® brokers on enterprise networks a deliberate business risk rather than an oversight.
The DripDropper campaign: August 2025
Red Canary’s threat intelligence team documented the DripDropper campaign and published their findings in August 2025. The following is based on their report, corroborated across multiple security publications.
Stage 1: Initial access via CVE-2023-46604
“The DripDropper malware attack chain involves the following steps: Initial Access: attackers scan for and identify publicly exposed, unpatched Apache ActiveMQ instances. Exploitation: the attackers exploit the CVE-2023-46604 vulnerability to gain initial access.” [Source]
Exploitation begins with automated scanning for publicly exposed Apache ActiveMQ® instances running port 61616. Once an unpatched broker is found, the CVE-2023-46604 exploit is delivered, the remote ClassPathXmlApplicationContext is fetched, and code execution is achieved under the broker’s process identity.
Stage 2: Persistence and privilege escalation
“Persistence and Privilege Escalation: the attackers modify the SSH configuration to allow root login, gaining elevated privileges and ensuring persistent access.” [Source]
After initial code execution, the attackers modify the host’s SSH daemon configuration to permit root login. This provides a persistent administrative backdoor that survives broker restarts, OS patches, and most incident response procedures that focus on the application layer.
Stage 3: DripDropper deployment
“The second file dropped by DripDropper is also designed to contact Dropbox for receiving commands, while also altering existing configuration files related to SSH, likely as a backup mechanism for persistent access.” [Source]
“The campaign introduced a previously unknown malware strain dubbed “DripDropper,” an encrypted PyInstaller executable that requires a password to run. DripDropper creates two malicious files on compromised systems. The first performs various functions including process monitoring and establishing persistence through cron job modifications. The second file, with a randomly generated eight-character name, modifies SSH configurations and prepares systems for additional persistent access mechanisms.” [Source]
DripDropper’s use of Dropbox for command and control is operationally significant. Outbound HTTPS traffic to dropbox.com is present in virtually every enterprise environment and is rarely blocked or deeply inspected. Malicious C2 traffic blended into normal Dropbox API calls is hard to distinguish from legitimate business use at the network layer.
Stage 4: Long-term covert access infrastructure
“Follow-on adversary command-and-control (C2) tools varied by endpoint and included Sliver, and Cloudflare Tunnels to maintain covert command and control over the long term.” [Source]
Sliver is an open-source adversary simulation framework (similar to Cobalt Strike) used for post-exploitation command and control. Cloudflare Tunnels provide an encrypted, authenticated tunnel from the compromised host to attacker infrastructure through Cloudflare’s network. That is legitimate Cloudflare traffic, which is extremely difficult to block without disrupting business operations.
The combination of SSH root access, Dropbox C2, Sliver implants and Cloudflare Tunnels provides four independent persistence mechanisms. Removing any one of them does not evict the attacker.
Stage 5: Post-exploitation patching, the novel tactic
This is what sets the DripDropper campaign apart from most CVE exploitation activity.
“In a striking tactical move, attackers downloaded legitimate ActiveMQ JAR files from Apache Maven repositories to patch the CVE-2023-46604 vulnerability on already compromised systems. This unusual behavior serves dual purposes: reducing detection by vulnerability scanners and preventing competing threat actors from exploiting the same flaw to gain access.” [Source]
“These two JAR files constitute a legitimate patch for CVE-2023-46604. By deleting the existing JAR files and replacing them, the adversary effectively patched the already compromised system.” [Source]
Red Canary noted: “It may seem counterintuitive for an adversary to ‘fix’ a compromised system after gaining remote access but in many scenarios the motivation can be twofold. It’s a great way to potentially lock out other adversaries, ensuring their foothold remains exclusive.” [Source]
The forensic implication for defenders is significant. If your compromise assessment treats broker version as evidence of patch status, a self-patched broker passes that check. The attacker has already established persistence through mechanisms a version check cannot detect. An Apache ActiveMQ® broker running the fix version is not evidence the system was clean before patching.
Was your Apache ActiveMQ® broker exposed before patching?
Patch status verification for CVE-2023-46604
The fix versions for CVE-2023-46604:
| Series | Vulnerable ≤ | Fix version |
| Apache ActiveMQ® Classic 5.15.x | 5.15.15 | 5.15.16 |
| Apache ActiveMQ® Classic 5.16.x | 5.16.6 | 5.16.7 |
| Apache ActiveMQ® Classic 5.17.x | 5.17.5 | 5.17.6 |
| Apache ActiveMQ® Classic 5.18.x | 5.18.2 | 5.18.3 |
| Apache Artemis™ | 2.31.1 | 2.31.2 |
To verify your broker version:
| # Check version from broker startup log grep “Apache ActiveMQ” /opt/activemq/data/activemq.log | grep “started” | head -1 # Expected (patched): INFO | Apache ActiveMQ 5.18.3 (localhost, …) started # Artemis version grep “AMQ221001” /opt/artemis/log/artemis.log | tail -1 # Expected (patched): AMQ221001: Apache ActiveMQ Artemis Message Broker version 2.31.2 # Via JMX (Jolokia HTTP API if enabled) curl -s “http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=*/BrokerVersion” |
Critical caveat from the DripDropper campaign: if your broker ran a vulnerable version and had port 61616 internet-accessible before patching, confirm the patch was applied by your operations team and not by someone else.
Compare the modification timestamp of the Apache ActiveMQ® JAR files against your change management records. If JAR files were modified at a time that does not match an authorized change, treat the system as potentially compromised regardless of its current version.
Remediation: more than patching
The Apache ActiveMQ® security advisory for CVE-2023-46604 is clear: patch to the fix version. But the DripDropper campaign shows why patching alone is not enough for organizations that had an exposure window.
Immediate: patch
If you are running any affected version, apply the patch immediately. Our Upgrade & Patching Strategy → post covers the complete Apache ActiveMQ® Classic and Apache Artemis™ upgrade procedure, including the pre-upgrade backup and post-upgrade validation steps that apply here.
Network level: restrict OpenWire port access
Port 61616 should never be directly accessible from the public internet. This is not a compensating control for a missing patch. It is a baseline security control that belongs in place regardless of patch status.
| # Firewall rule: restrict port 61616 to authorized client IP ranges only # Replace 10.0.0.0/8 with your actual authorized client network ranges iptables -A INPUT -p tcp –dport 61616 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp –dport 61616 -j DROP |
If your broker runs on a cloud provider, use security groups, network ACLs, or equivalent cloud-native controls to restrict the OpenWire port to authorized source IP ranges.
If you had an exposure window: compromise assessment
An exposure window exists if your broker ran a vulnerable version AND port 61616 was reachable from a path that included internet-exposed systems, compromised network segments, or VPN endpoints.
Signs of DripDropper-style compromise to look for:
- SSH configuration modified to allow PermitRootLogin yes (check /etc/ssh/sshd_config)
- Cron jobs your operations team did not create (check crontab -l for all users)
- Processes running Sliver, unexpected Python executables (DripDropper is a PyInstaller binary), or outbound connections to dropbox.com from the broker host
- Apache ActiveMQ® JAR modification timestamps that do not match authorized change events
- Unexpected outbound Cloudflare Tunnel connections from the broker host
Hardening beyond patching
Patching removes the vulnerability. Hardening shrinks the broker’s attack surface so the next Apache ActiveMQ® CVE has less impact:
- Disable the Jolokia HTTP API if it is not in use. It is a separate attack surface; see CVE-2022-41678 in our Apache ActiveMQ® CVE Guide →.
- Enable TLS on all transport connectors. An encrypted OpenWire connection is not materially harder to exploit via CVE-2023-46604, but TLS enables client certificate verification that can restrict which clients connect.
- Enable JAAS authentication so broker access requires valid credentials. CVE-2023-46604 bypasses authentication for the exploit itself, but hardening the surrounding attack surface still matters.
- Segment the network so the broker is isolated from internet-facing systems.
Our Security Hardening Guide → covers all of these controls in detail with production-ready configuration.
The persistence problem: four independent mechanisms
The DripDropper campaign’s layered persistence is what makes incident response harder than it first appears:
| Persistence mechanism | Removal requirement |
| SSH root login (PermitRootLogin yes) | Revert sshd_config, rotate all root SSH keys, restart sshd |
| Cron job persistence | Remove unauthorized cron entries for all users |
| Sliver implant | Kill the process, remove the binary, rotate any credentials accessible from the compromised host |
| Cloudflare Tunnel | Kill the process, remove the tunnel configuration, revoke the tunnel credential in the Cloudflare dashboard |
Each mechanism is independent, so removing one does not remove the others. An incident response that finds and removes the SSH change but misses the Sliver implant leaves the attacker with continued access. Full remediation means finding and removing all four layers, plus auditing any data or credentials that may have been accessed during the compromise window.
Detect anomalous behavior on your Apache ActiveMQ® brokers
Frequently asked questions
Is CVE-2023-46604 still being exploited in 2025?
Yes. Red Canary documented active exploitation in August 2025 via the DripDropper campaign. The vulnerability’s EPSS score of 94.44% confirms it remains among the most actively exploited known vulnerabilities. Organizations running unpatched Apache ActiveMQ® Classic ≤ 5.18.2 or Apache Artemis™ ≤ 2.31.1 remain fully exposed.
What is CVE-2023-46604?
CVE-2023-46604 is a CVSS 10.0 unauthenticated remote code execution vulnerability in the Apache ActiveMQ® Classic OpenWire protocol. An attacker with network access to port 61616 can make the broker load attacker-controlled Spring XML via ClassPathXmlApplicationContext, executing arbitrary OS commands without authentication.
What is DripDropper malware?
DripDropper is an encrypted PyInstaller ELF downloader deployed in the August 2025 exploitation campaign. It communicates via Dropbox for command and control, modifies SSH for root login persistence, establishes cron job persistence, and deploys Sliver implants and Cloudflare Tunnels for long-term covert access.
Why did attackers patch CVE-2023-46604 after exploiting it?
To lock rival threat actors out of the same entry point and to hide the original intrusion vector from defenders. As Red Canary confirmed, patching does not disrupt their operations because several other persistence mechanisms are already in place.
How do I verify my Apache ActiveMQ® broker is patched for CVE-2023-46604?
The Apache ActiveMQ® security advisory for CVE-2023-46604 lists these fix versions: Apache ActiveMQ® Classic 5.15.16, 5.16.7, 5.17.6 and 5.18.3; Apache Artemis™ 2.31.2. Check the broker startup log for the version string. If your broker ran a vulnerable version before patching and port 61616 was network-accessible, confirm the JAR modification timestamps match your authorized change records, because attackers may have applied the patch after compromising the system.