Security researchers have disclosed three high-severity vulnerabilities in NextGen Healthcare's Mirth Connect, the open-source, cross-platform integration engine that quietly sits at the center of an enormous amount of U.S. healthcare data exchange. If you run a hospital network, an HIE, a lab, or a billing operation, there is a very good chance Mirth Connect is moving HL7, FHIR, DICOM, or flat-file data between your EHR and downstream systems right now — which makes these findings anything but academic.
The core issue is that the most severe of the three flaws can be reached without authentication against the Mirth Connect administrative REST API. An attacker with network access to the Mirth management interface can achieve remote code execution in the context of the Mirth service — and from there, pivot into the clinical network, tamper with message flows, or stage a data exfiltration operation that blends into normal integration traffic.
I've responded to intrusions where integration middleware was the initial foothold precisely because organizations treat it as "plumbing" rather than as a critical, internet-adjacent server. Treat this advisory accordingly.
Technical Analysis
Affected Products and Exposure
- Product: NextGen Healthcare Mirth Connect (cross-platform Java-based integration engine; Windows, Linux, and container deployments)
- Affected versions: Mirth Connect releases prior to the patched release (upgrade to the latest 4.5.x line, which addresses all three issues)
- Exposed surface: The Mirth Connect Administrator REST API, typically listening on TCP 8443 (HTTPS) and 8080 (HTTP), bound to 0.0.0.0 by default in many deployments
Mirth Connect is a Java application. It runs under a service account that — far too often in real-world deployments — has been granted local administrator or root privileges "to make channel file I/O work." That compounds the impact of any code-execution flaw: compromise of the Mirth process frequently means compromise of the host, with full read/write access to every directory the channels touch — including SMB shares holding ePHI extracts, SFTP drop directories, and database credentials stored in channel configurations.
How the Vulnerabilities Work (Defender's View)
The disclosure describes three distinct high-severity issues. The attack chain that should keep you up at night looks like this:
-
Pre-authentication code execution via unsafe deserialization. Mirth Connect's REST API processes attacker-supplied serialized/XML content in a way that allows unsafe object instantiation. A remote, unauthenticated attacker can send a crafted request to the API listener and trigger execution of arbitrary commands in the Mirth JVM's process context. Exploitation requires only network reachability to the management port — no credentials, no user interaction. This class of flaw (Java deserialization to RCE) has a long, ugly history of reliable public exploit code appearing within weeks of disclosure.
-
XML External Entity (XXE) processing. Mirth's XML parsing components handle external entities unsafely in affected versions. XXE in an integration engine is particularly dangerous because XML is its native tongue — the attacker can coerce the server into reading local files (SSH keys,
mirth.propertieswith embedded database passwords, cloud credentials) and exfiltrating them out-of-band, or use it for SSRF to reach internal services that trust the Mirth host. -
Insecure configuration / credential exposure issue. The third issue lowers the bar further, exposing sensitive configuration data that accelerates post-exploitation — database connection strings, channel credentials, and internal network topology.
Exploitation Status
At the time of disclosure, the vulnerabilities were reported through coordinated channels and patches were made available by NextGen Healthcare. The technical details are now public, and the affected component (a widely deployed, default-listening management API) is trivially discoverable via internet scanning. Organizations should assume that exploitation attempts against internet-exposed or flat-network Mirth instances will follow — healthcare middleware with pre-auth RCE is exactly the profile ransomware affiliates hunt for. CISA has previously flagged Mirth Connect vulnerabilities in its medical device advisories, so monitor the CISA KEV catalog and ICS medical advisories for additions.
Why Healthcare Should Care Disproportionately
Mirth Connect is a central trust node. It holds credentials for EHR databases, lab systems, pharmacies, and clearinghouses. It sees ePHI in transit, often decrypted. A successful intrusion here is not a single-host incident — it's a potential HIPAA breach affecting every upstream and downstream system, with the attacker positioned to manipulate clinical messages (lab results, orders) in transit. The integrity risk is arguably worse than the confidentiality risk.
Detection & Response
The highest-fidelity detection strategy focuses on the behavioral consequence of exploitation: the Mirth Java process doing things a message broker never should — spawning shells, writing executables, making outbound connections to unfamiliar hosts, or reading credential files outside its normal path.
SIGMA Rules
---
title: Mirth Connect Process Spawning Shell or Command Interpreter
id: 4f2a9c1e-7b3d-4e85-9a12-6c8d5f0e2b71
status: experimental
description: Detects the Mirth Connect Java/service process spawning command interpreters or script engines, consistent with post-exploitation of a deserialization RCE against the Mirth management API.
references:
- https://www.hipaajournal.com/high-severity-vulnerabilities-nextgen-healthcare-mirth-connect/
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.execution
- attack.t1059
- attack.initial_access
- attack.t1190
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\java.exe'
- '\javaw.exe'
- '\mcservice.exe'
- '\mirthconnectservice.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\wget.exe'
filter_known:
CommandLine|contains:
- 'mccommand'
condition: selection_parent and selection_child and not filter_known
falsepositives:
- Rare administrative channel scripts invoked through Mirth's JavaScript filter/transformer steps - baseline per host
level: high
---
title: Mirth Connect API Listener Receiving Suspicious Serialized or XXE Payloads
id: 8b1e5d42-3c7a-4f69-b284-1d9e6a3c5f08
status: experimental
description: Detects HTTP requests to the Mirth Connect management API ports containing Java serialization markers, XMLDecoder gadget indicators, or XXE DOCTYPE declarations, consistent with exploitation attempts against the disclosed deserialization and XXE flaws.
references:
- https://www.hipaajournal.com/high-severity-vulnerabilities-nextgen-healthcare-mirth-connect/
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_port:
c_dst_port:
- 8443
- 8080
selection_payload:
cs-uri|contains:
- '/api/'
cs-body|contains:
- '<!DOCTYPE'
- '<!ENTITY'
- 'SYSTEM "file:'
- 'java.beans.XMLDecoder'
- 'ProcessBuilder'
- 'java.lang.Runtime'
- '\xac\xed\x00\x05'
- 'rO0AB'
condition: selection_port and selection_payload
falsepositives:
- Legitimate XML interfaces using DOCTYPE declarations internally - rare in Mirth API traffic
level: critical
---
title: Mirth Connect Host Initiating Outbound Connection to Rare External Destination
id: 2d7c4f19-5a8b-4e23-9c61-3f0a8b7d4e15
status: experimental
description: Detects the Mirth Connect service process establishing outbound network connections to ports uncommon for integration traffic, indicating possible command-and-control or exfiltration following exploitation.
references:
- https://www.hipaajournal.com/high-severity-vulnerabilities-nextgen-healthcare-mirth-connect/
- https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.command_and_control
- attack.t1071
logsource:
category: network_connection
product: windows
detection:
selection:
Image|endswith:
- '\java.exe'
- '\javaw.exe'
- '\mcservice.exe'
Initiated: 'true'
filter_local:
DestinationIp|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
filter_known_ports:
DestinationPort:
- 443
- 53
- 25
- 389
- 636
- 1433
- 1521
- 3306
- 5432
- 2575
- 6661
condition: selection and not filter_local and not filter_known_ports
falsepositives:
- Legitimate outbound channels to external trading partners on unusual ports - maintain an allowlist per interface agreement
level: medium
These rules are tuned around the Mirth process identity. Before deploying, baseline which Mirth channels legitimately invoke external scripts (some interfaces shell out for file processing) and allowlist those exact command lines — do not blanket-exclude the parent process.
KQL Hunt (Microsoft Sentinel / Defender)
This query hunts across process, network, and Syslog telemetry for the post-exploitation pattern: the Mirth JVM or service spawning unexpected children or reaching unfamiliar destinations. It works whether Mirth runs on Windows (MDE telemetry) or Linux (Syslog/CEF ingestion).
// Hunt for post-exploitation behavior originating from Mirth Connect processes
let lookback = 14d;
let mirthProcesses = dynamic(["java.exe", "javaw.exe", "mcservice.exe", "MirthConnectService.exe", "java"]);
let suspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "rundll32.exe",
"certutil.exe", "bitsadmin.exe", "curl.exe", "wget.exe", "nc.exe", "netcat.exe",
"sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python", "python3", "perl"]);
// Windows endpoint telemetry: Mirth process spawning interpreters/tools
let procHits = DeviceProcessEvents
| where TimeGenerated > ago(lookback)
| where InitiatingProcessFileName in~ (mirthProcesses)
| where FileName in~ (suspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, AccountName, InitiatingProcessRemoteIPAddress, ReportId
| extend Source = "MDE-Process";
// Outbound network connections from Mirth process to non-RFC1918, non-standard integration ports
let netHits = DeviceNetworkEvents
| where TimeGenerated > ago(lookback)
| where InitiatingProcessFileName in~ (mirthProcesses)
| where RemoteIPType == "Public"
| where RemotePort !in (80, 443, 53, 25, 587, 389, 636, 993, 995, 1433, 1521, 3306, 5432, 8443)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Connections=count(),
Ports=make_set(RemotePort), URLs=make_set(RemoteUrl)
by DeviceName, InitiatingProcessFileName, RemoteIP
| extend Source = "MDE-Network";
// Linux: Syslog evidence of shells or download tools executing near Mirth service context
let syslogHits = Syslog
| where TimeGenerated > ago(lookback)
| where Computer has_any ("mirth", "interface", "integration") // tune to your Mirth host naming
| where SyslogMessage has_any ("XMLDecoder", "ProcessBuilder", "java.lang.Runtime",
"DOCTYPE", "ENTITY", "mirth.properties")
| project TimeGenerated, Computer, Facility, SeverityLevel, SyslogMessage, Source = "Syslog";
union isfuzzy=true procHits, netHits, syslogHits
| order by TimeGenerated desc
Run this against at least 14 days of history immediately — if your Mirth instance was internet-reachable or on a flat segment, you're doing retro-hunting, not just forward detection. Any hit on a shell child process under the Mirth JVM should be treated as a confirmed incident until proven otherwise.
Velociraptor VQL Hunt
For DFIR triage of a suspected Mirth host, this artifact enumerates the Mirth process tree, its children, listening sockets, and outbound connections — the three things that tell you whether the box is talking or spawning anything it shouldn't.
-- Mirth Connect compromise triage: process tree, children, and network sockets
-- Deploy as a hunt scoped to hosts tagged as Mirth/interface-engine servers
LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)java|mcservice|mirth'
OR Exe =~ '(?i)mirth'
LET conns = SELECT Pid, Name, Family, Type, Laddr, Lport, Raddr, Rport, Status
FROM netstat()
WHERE Name =~ '(?i)java|mcservice|mirth'
SELECT 'PROCESS' AS Artifact,
Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
NULL AS Laddr, NULL AS Lport, NULL AS Raddr, NULL AS Rport, NULL AS Status
FROM procs
UNION ALL
SELECT 'CONNECTION' AS Artifact,
Pid, NULL AS Ppid, Name, NULL AS Exe, NULL AS CommandLine, NULL AS Username, NULL AS CreateTime,
Laddr, Lport, Raddr, Rport, Status
FROM conns
WHERE Rport != 0 -- established outbound sessions
Follow up any suspicious PID with a targeted collection of the Mirth installation directory (Mirth Connect/logs/, appdata/, and conf/mirth.properties) — the access logs under logs/ will show API request history and are the single best source for confirming when the malicious request hit the listener.
Remediation Verification Script
This Bash script (Mirth predominantly runs on Linux in production) verifies the installed version, confirms the management interface is not bound to all interfaces, checks for unexpected listeners, and snapshots the Mirth process tree for anomalies.
#!/usr/bin/env bash
# Mirth Connect post-advisory verification and hardening check
# Run as root or via sudo on the Mirth Connect host
set -euo pipefail
MIRTH_HOME="${MIRTH_HOME:-/opt/mirthconnect}"
REPORT="/tmp/mirth_hardening_$(date +%Y%m%d_%H%M%S).txt"
echo "=== Mirth Connect Hardening Verification - $(date) ===" | tee "$REPORT"
# 1. Identify installed version (must be on the patched 4.5.x line or later)
echo -e "\n[1] Installed version:" | tee -a "$REPORT"
if [ -f "$MIRTH_HOME/docs/mirthconnectadministrator.launch" ] || [ -d "$MIRTH_HOME" ]; then
grep -r "mirth.version" "$MIRTH_HOME/conf/" 2>/dev/null | tee -a "$REPORT" || true
ls "$MIRTH_HOME" 2>/dev/null | tee -a "$REPORT"
else
echo "Mirth Connect not found at $MIRTH_HOME - set MIRTH_HOME" | tee -a "$REPORT"
fi
# 2. Check management listener binding - must NOT be 0.0.0.0 in production
echo -e "\n[2] Listener bindings (8443/8080 should be loopback or management VLAN only):" | tee -a "$REPORT"
grep -E "http.port|https.port|http.host|https.host" "$MIRTH_HOME/conf/mirth.properties" 2>/dev/null | tee -a "$REPORT" || true
ss -tlnp 2>/dev/null | grep -E ':8443|:8080' | tee -a "$REPORT" || echo "No 8443/8080 listeners found" | tee -a "$REPORT"
# 3. Service account privileges - Mirth must NOT run as root
echo -e "\n[3] Mirth process owner (should be a dedicated non-root account):" | tee -a "$REPORT"
ps -eo user,pid,ppid,cmd | grep -iE "java.*mirth|mcservice" | grep -v grep | tee -a "$REPORT" || echo "Mirth process not running" | tee -a "$REPORT"
# 4. Anomaly check: child processes of the Mirth JVM
echo -e "\n[4] Child processes of Mirth JVM (investigate anything that is a shell/interpreter):" | tee -a "$REPORT"
MIRTH_PID=$(pgrep -f "mirth" | head -1 || true)
if [ -n "${MIRTH_PID:-}" ]; then
ps --ppid "$MIRTH_PID" -o user,pid,cmd 2>/dev/null | tee -a "$REPORT" || echo "No child processes" | tee -a "$REPORT"
fi
# 5. Outbound connections from the Mirth process to non-private space
echo -e "\n[5] External connections from Mirth process:" | tee -a "$REPORT"
ss -tnp 2>/dev/null | grep -iE "java|mirth" | grep -vE "10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\." | tee -a "$REPORT" || echo "None" | tee -a "$REPORT"
# 6. Firewall lockdown: restrict 8443 to the admin/management subnet (adjust CIDR!)
echo -e "\n[6] Applying iptables restriction on management ports (edit MGMT_SUBNET first):" | tee -a "$REPORT"
MGMT_SUBNET="10.10.50.0/24" # <-- CHANGE to your admin/management VLAN
# iptables -A INPUT -p tcp --dport 8443 -s "$MGMT_SUBNET" -j ACCEPT
# iptables -A INPUT -p tcp --dport 8443 -j DROP
# iptables -A INPUT -p tcp --dport 8080 -s "$MGMT_SUBNET" -j ACCEPT
# iptables -A INPUT -p tcp --dport 8080 -j DROP
echo "(Rules commented out - review and uncomment with correct MGMT_SUBNET)" | tee -a "$REPORT"
echo -e "\nReport saved to $REPORT"
On Windows-hosted Mirth instances, the equivalent checks are Get-Process java | Select-Object Id, Path, Get-NetTCPConnection -LocalPort 8443 -State Listen, and reviewing the service account assigned to the Mirth Connect service — which should be a least-privilege gMSA or dedicated account, never LocalSystem or a domain admin.
Remediation
- Patch immediately. Upgrade Mirth Connect to the latest 4.5.x release, which remediates all three disclosed vulnerabilities. Obtain the update only from the official NextGen Healthcare download portal, and validate the installer hash before deployment. The vendor advisory and release notes are published via the NextGen Healthcare / Mirth community portal and were summarized by The HIPAA Journal.
- Audit exposure before you patch. Query your CMDB, external attack surface management tooling, and Shodan/Censys for any Mirth management interface (8443/8080) reachable from the internet or from general user VLANs. There is no legitimate reason for the Mirth Administrator API to be broadly reachable.
- Segment the management plane. Restrict TCP 8443/8080 to a dedicated management VLAN or jump host via host firewall and network ACLs. Channel traffic (HL7 MLLP on 2575/6661, SFTP, database ports) should be the only broadly permitted flows, and those only between documented interface partners.
- Downgrade the service account. If Mirth runs as root, LocalSystem, or any admin-tier account, re-scope it to a dedicated service account with write access only to the directories its channels require. This single change converts a catastrophic RCE into a contained one.
- Rotate credentials stored in Mirth. Assume
mirth.propertiesand channel configurations are exposed if the instance was unpatched and reachable: rotate database passwords, SFTP keys/accounts, API tokens, and any AD service account referenced in connectors. - Retro-hunt before declaring clean. Run the KQL and VQL hunts above across at least 14 days of telemetry. Review
Mirth Connect/logs/for anomalous API requests (unauthenticated POST bodies, requests from unfamiliar source IPs, requests outside maintenance windows). - Assess HIPAA breach obligations. If you confirm exploitation on an instance that processed ePHI, engage counsel immediately — the four-factor risk assessment and 60-day notification clock apply. Preserve Mirth logs, the
appdatadirectory, and memory/disk images before rebuilding. - Add Mirth to your vulnerability management scope as Tier-1. Integration engines belong on the same patch cadence as VPN concentrators and email gateways: internet-adjacent, credential-rich, and high-impact. If your scanner doesn't know what Mirth Connect is, add an authenticated check or application inventory rule for it.
The pattern here is one I've seen repeat across every healthcare IR engagement involving middleware: the integration engine is invisible to asset management, exempt from patching windows because "interfaces will break," and running with god-mode credentials. These three vulnerabilities are the bill coming due on that operating model. Patch the software this week — but fix the operating model this quarter.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.