Three High-Severity Flaws Expose NextGen Mirth Connect Data and Credentials

CISA has disclosed three high-severity vulnerabilities in NextGen Healthcare Mirth Connect, a healthcare integration platform deployed worldwide. All releases through version 4.7.1 are affected.

The flaws include an authenticated SQL injection vulnerability and two XML External Entity, or XXE, weaknesses. Depending on the attack path, exploitation could expose healthcare data, reveal credentials for connected systems, create arbitrary files, or disrupt Mirth Connect services.

The ICS Medical Advisory published by CISA received its initial release on September 10, 2026. Abhinav Agarwal reported the vulnerabilities to the agency.

CISA said no known public exploitation specifically targeting these vulnerabilities had been reported when the advisory was published. However, no fixed version or vendor-provided upgrade path has been identified.

Every Mirth Connect Release Through 4.7.1 Is Affected

The affected product is NextGen Healthcare Mirth Connect v4.7.1 and earlier, with deployments across the Healthcare and Public Health critical-infrastructure sector. NextGen Healthcare is headquartered in the United States, but the product’s deployment scope is global.

Mirth Connect transfers and transforms information between healthcare systems. That position can give the platform access to sensitive data and credentials needed to communicate with external applications.

The three vulnerabilities are:

• CVE-2026-82583: SQL injection through the Database Connector API.
• CVE-2026-78224: XXE injection in the XSLT Transformer Step.
• CVE-2026-82578: XXE injection during XML batch processing when XPath is enabled.

All three are rated High under both CVSS 3.1 and CVSS 4.0. The product-level entry in CISA’s summary carries a CVSS 3 base score of 8.3.

No remediation release has been disclosed. Consequently, organizations cannot assume that moving from one affected release to another within the 4.7.1-and-earlier range will address the weaknesses.

Database Connector API Permits Arbitrary SQL

The most functionally broad issue is CVE-2026-82583, an SQL injection vulnerability in the Mirth Connect Database Connector API.

An attacker must first possess an authenticated account, but only low-level privileges are required. The vulnerable API can then be abused to execute arbitrary SQL statements against the associated database environment.

Successful exploitation could expose credentials stored for systems connected to Mirth Connect. It may also permit arbitrary file writes and denial-of-service attacks, depending on the affected environment and the capabilities available through the database connection.

The vulnerability has a CVSS 3.1 score of 8.3, with the vector:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H

This assessment reflects a network-based attack with low complexity, low privileges, and no required user interaction. Confidentiality and availability impacts are high, while the integrity impact is rated low.

Its CVSS 4.0 score is 7.2, using the vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N

The authentication requirement limits who can initiate the attack, but it does not make the flaw minor. A stolen account, improperly assigned role, or malicious insider could provide the initial access required to reach the vulnerable API.

Two XML Processing Paths Allow XXE Injection

The remaining vulnerabilities arise from unsafe processing of external entities in XML. XXE attacks abuse XML parser features that can resolve attacker-controlled entity references, potentially retrieving information accessible to the application or consuming resources until a service becomes unavailable.

CVE-2026-78224 affects the XSLT Transformer Step. Mirth Connect creates a TransformerFactory without enabling the security controls needed to restrict external entity behavior.

An attacker can exploit that configuration to retrieve data or cause denial of service. No privileges or user interaction are required under the published scoring assessment.

The vulnerability has a CVSS 3.1 score of 8.2:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L

Its CVSS 4.0 score is 8.8:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N

CVE-2026-82578 affects a separate XML workflow. When XML batch processing is enabled and the XPath option is selected, raw batch input passes through a default XPath/JAXP configuration without the necessary entity restrictions.

That behavior allows malicious XML to trigger external entity processing. The documented consequences include data exfiltration and, according to the vulnerability description, potential denial-of-service behavior.

CVE-2026-82578 has a CVSS 3.1 score of 7.5:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Its CVSS 4.0 score is 8.7:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Both XXE flaws are remotely reachable, low-complexity attack paths requiring neither authentication nor user interaction under the published vectors. Their main security consequence is loss of confidentiality.

Healthcare Integrations Expand the Potential Impact

Mirth Connect can sit between clinical applications, databases, and other connected services. A compromise may therefore affect more than the integration server itself.

The SQL injection issue could disclose credentials that Mirth Connect uses to access external systems. Those credentials may become a route toward additional resources, although the actual reach depends on local privileges and network architecture.

The XXE vulnerabilities could expose data available to the affected process. They may also interfere with message transformation or batch-processing functions, disrupting the exchange of information between healthcare applications.

The practical consequences vary by deployment. Relevant factors include whether vulnerable interfaces are reachable, which Mirth Connect features are enabled, what permissions the service and database possess, and whether the platform is separated from clinical and business networks.

No public exploit, evidence of active attacks, or indicators of compromise were identified at publication. No CISA Known Exploited Vulnerabilities inclusion date or remediation deadline has been provided for these CVEs.

Defenders Must Reduce Exposure While Awaiting a Fix

Because no fixed release or specific upgrade route has been disclosed, operators should begin by locating every Mirth Connect instance and confirming its version. Any deployment running 4.7.1 or earlier should be treated as affected.

CISA recommends keeping Mirth Connect and comparable control-system services off the public internet. Firewalls and network segmentation should separate healthcare integration infrastructure from business networks and limit connections to approved systems.

Remote administrative access should use a maintained VPN or another secured access mechanism. A VPN alone is insufficient if its software is vulnerable or the connecting endpoint has already been compromised.

Organizations should also review:

• Accounts able to reach the Database Connector API, particularly low-privilege users with unnecessary access.
• Authentication failures, unusual sessions, and unexpected Database Connector activity.
• SQL operations that do not match established integration workflows.
• Unexpected files or filesystem changes associated with the Mirth Connect service.
• XSLT Transformer Steps receiving unusual or untrusted XML.
• Channels using XML batch processing with XPath enabled.
• Service failures or resource exhaustion associated with XML processing.
• Network paths allowing the Mirth Connect host to reach unnecessary internal or external resources.

These are behavioral investigation points, not vendor-issued indicators of compromise. No specific malicious domains, IP addresses, file hashes, or exploit signatures have been published.

Before changing production architecture or disabling integration features, healthcare operators should assess the potential operational effect. Controls that interrupt clinical data flows can introduce their own safety and availability risks.

Suspected exploitation should be handled through established incident-response procedures and reported to CISA for correlation with other cases. Until a validated remediation becomes available, access restriction, segmentation, least privilege, and close monitoring remain the primary protections.