On September 10, 2026, CISA published ICSMA-26-253-01, covering three high-severity vulnerabilities in NextGen Healthcare’s Mirth Connect, version 4.7.1 and earlier. The same day, the researcher who reported them to CISA published a technical write-up with working proof-of-concept code.
NextGen’s fix is Mirth Connect 4.7.2, and it is available only to NextGen’s commercial customers. If you run the last open-source release, 4.5.2, or anything older, no patch is coming for your build: NextGen’s own security policy says it does not patch open-source releases under any circumstances. That line ended when the license changed in March 2025.
That is not the same as being stuck. The open-source code carried on as the Eclipse Open Integration Engine (OIE), and a patched open-source build of it exists today. What has to go is the old build, not open source.
The Three Mirth Connect Vulnerabilities CISA Disclosed
All three are rated high, and all three sit in standard features: the XSLT transformer step, XML batch processing, and the Database Connector’s table browser.
| CVE | Flaw | Where it lives | Login needed | CVSS v3.1 / v4.0 |
|---|---|---|---|---|
| CVE-2026-78224 | XXE (CWE-611) | XSLT transformer step | None | 8.2 / 8.8 |
| CVE-2026-82578 | XXE (CWE-611) | XML batch processing, any split except JavaScript | None | 7.5 / 8.7 |
| CVE-2026-82583 | SQL injection (CWE-89) | Database Connector API | Any account | 8.3 / 7.2 |
CISA’s summary of the impact is data exfiltration or denial of service. The CVE records are more specific. Both XXE flaws come from XML parsers set up without entity restrictions: the XSLT step builds “a bare TransformerFactory without the proper security options set,” and XML batch processing with the XPath option sends raw input through “a default XPath/JAXP setup with no entity restrictions.” The third flaw lets an authenticated user “execute arbitrary SQL through a Database Connector API,” which CISA says can disclose stored credentials for connected systems, write arbitrary files, and cause a denial of service.
Two of the three need no login. That is easy to miss, because the advisory’s headline score, 8.3, belongs to the one flaw that does need a login. The split follows from where each flaw lives. A Mirth Connect server has two network surfaces. The administration API on port 8443 is what the Administrator client talks to, and it requires a login. Channel listeners, the HTTP, TCP and MLLP ports that exist so other systems can push messages in, are not behind the Mirth login at all. Both XXE flaws are reached through message content arriving at a listener. The SQL injection is in the administration API.
So restricting who can reach port 8443 protects against one of the three and not the other two. Anyone who can send XML to a channel with an XSLT step, or with XML batch processing turned on, can reach an XXE flaw without a Mirth account. CISA’s description names the XPath split, but in the 4.5.2 code the Element Name and Level splits take the same path; only the JavaScript split does not. The SQL injection does need an account, and that is a lower bar than it sounds. The open-source build has no role-based permissions, so every account is effectively an administrator. Treat any exposed login as full compromise.
The researcher also showed what is at stake. Mirth Connect 4.5.2 keeps its channel definitions in its own database, and the connector passwords inside them are stored in clear text: credentials for the databases, file servers and mail relays its channels talk to. A copy of that database hands over working logins for the systems around the engine, which is why rotating them is on the list below.
No Known Exploitation Yet, and the Exploit Is Public
CISA reported no known public exploitation when it published the advisory. That is less reassuring than it sounds, because working proof-of-concept code went public with the advisory, on the same day.
Mirth Connect has been here before. CVE-2023-43208, an unauthenticated remote code execution flaw fixed in version 4.4.1, was exploited in the wild. CISA added it to the Known Exploited Vulnerabilities catalog in May 2024 and marks it as used in ransomware campaigns. The new flaws are not remote code execution, and none of them is in that catalog. What they share with it is public exploit code.
The other reason to move quickly is position. An interface engine is not an edge application. It holds credentials for the systems it connects, sees message content from most of them, and often has broader network reach than the systems around it. A flaw in the engine sits next to everything the engine touches.
Why the 4.7.2 Fix Doesn’t Reach the Free Build
Most advisories end with “upgrade to the fixed version.” This one does too, and for a large group of users that instruction leads nowhere.
NextGen moved Mirth Connect to a commercial license on March 19, 2025, starting with version 4.6. Releases since then are available only from NextGen and its authorized resellers, and source code for new releases is no longer published. The last free, open-source Mirth Connect download is 4.5.2. CISA’s advisory points to NextGen’s customer portal for 4.7.2, which needs a current commercial agreement.
The advisory therefore splits its readers:
- If you hold a current NextGen agreement, this is an ordinary patch cycle. Get 4.7.2 from the portal and move on.
- If you run the open-source build, 4.7.2 is not a download you are entitled to, and nothing else is coming for 4.5.2. Getting a fix means changing what you run.
The second group is large, and it is not careless. Hospitals, labs and health information exchanges standardized on Mirth Connect back when it was open source, and built whole channel estates on it. Interface engines are also the servers nobody wants to restart. Most systems in the building depend on them, so they run for years between upgrades. The license change made that habit expensive, and this advisory is the clearest bill yet.
The timing makes the split sharper. According to the researcher’s disclosure timeline, he reported the flaws to NextGen on July 10, and by August 5 NextGen had confirmed fixes for all three in its commercial releases, at least five weeks before the advisory. One was older still: the XSLT flaw was described in a public issue on NextGen’s own repository in March 2026, and NextGen told the researcher it was already fixed in the commercial 4.7.1.
Is OIE Affected? Where the Patch Stands
The community continuation of the open-source line is the Eclipse Open Integration Engine. It forked from Mirth Connect’s last open-source release and has since become an Eclipse Foundation project. It is where the open-source lineage lives now, and it is where this post points.
OIE continues the same code, so it carries the same three flaws. Its contributors moved quickly. Within four days of the advisory a pull request fixing all three was open, and by day nine a second contributor had opened five more, some fixing each flaw and others hardening XML parsing across the server. On September 22 the project merged the fix for the XSLT flaw. The SQL injection and XML batch fixes are in review, and a patch release is expected shortly. OIE’s first release, in July 2025, was a rebuild of 4.5.2. Its latest, v4.6.0 from July 9, 2026, predates the advisory, so upstream OIE stays exposed until the patch release ships.
You do not have to wait for it. OpenShare Engine 4.6.0-7, Saga IT’s open-source build of OIE 4.6.0, has shipped all three fixes since September 14, along with a fourth fix, from OIE, for SQL injection in message search. It is the same engine with the same channel format. It comes as EV-signed installers from the OpenShare console or as the Docker image sagait/openshare-engine:4.6.0-7-ubuntu. Its source, fixes and regression tests included, is public under the MPL 2.0 at the openshare-v4.6.0-7 tag.
| Line | Build with the fixes | How you get it |
|---|---|---|
| The old open-source build | None. 4.5.2 was the last release | Not available |
| NextGen Mirth Connect | 4.7.2 | Commercial license, customer portal |
| OpenShare Engine (Saga IT, built on OIE 4.6.0) | 4.6.0-7, released September 14 | Free: installers, Docker image, or source |
| Eclipse OIE | Next release. 1 of 3 fixes merged | Patch release expected shortly |
Check the project’s releases for current status rather than relying on any date in a blog post, including this one.
How to Tell Whether You Are Exposed
Three questions, in the order that tells you the most.
1. What version are you running? In the Administrator, open About Mirth Connect in the Other task pane. From a script, the version endpoint answers without a login, which is one more reason to keep port 8443 fenced:
curl -s -H 'X-Requested-With: OpenAPI' \ https://mirth.example.com:8443/api/server/versionOn Mirth Connect, anything at or below 4.7.1 is affected, which is every open-source release. If it reports 4.5.2 or lower you are on the open-source build, and unless you hold a NextGen agreement, the vendor fix is not available to you. If it is a 3.x release, you are further behind than this advisory alone suggests. OIE-based builds need one more step, because the number will not tell you: OIE 4.6.0 and OpenShare Engine 4.6.0-7 both report 4.6.0, and only the second has the fixes. Check which release you installed.
2. Where does XML come in? The two unauthenticated flaws need a channel that parses XML from someone else. Search your channels for XSLT transformer steps, and for inbound XML with batch processing turned on. Start with any channel whose listener accepts XML from outside your own network.
3. Who can log in, and from where? The SQL injection needs any authenticated account. List every Administrator and API user, retire shared and default accounts, and confirm port 8443 is not reachable from outside a management network. Then list the credentials stored in your channels and what each one can reach, because that is what the flaw exposes.
What You Can Do Now
Four options, each with a cost in money or engineering time, and one choice that is not an option.
Move to a patched open-source build. For most organizations on the old build, this is the answer. OIE continues the same codebase, so channels and code templates carry over rather than being rebuilt. Check any commercial or custom extensions before you move. OpenShare Engine 4.6.0-7 has the fixes today, and upstream OIE will have them in its next release. If you would rather not run the move yourself, we do OIE migration and support.
License NextGen’s 4.7.2. This is the direct route to the vendor fix, and the right answer if you want vendor support anyway. It is a commercial decision with a commercial cost. Our Mirth Connect page covers what that path involves.
Patch the build you run. The fixes are public, each with regression tests: the three commits in our build for the SQL injection, the XSLT step and XML batch processing, and the pull requests on OIE. If you have Java capability in house and a build pipeline for your engine, applying them is tractable. Many teams running an interface engine have neither, and that is worth admitting before you choose this route.
Reduce exposure while you decide. CISA’s guidance is network-level: keep the engine off the public internet, segment it away from the business network, and use a VPN for remote access. The researcher adds measures that fit these flaws more closely:
- Keep the administration API on a management network.
- Restrict outbound connections from the engine to the destinations your channels actually use. That breaks the exfiltration path the XXE flaws depend on, though it does not fix the parsers.
- Remove XSLT steps and XML batch processing you do not need.
- Rotate every credential stored in a connector on an affected server, even after you patch. If the admin API was ever reachable from outside a management network, assume those channel configurations are compromised.
None of this is remediation, but it is the fastest thing on the list. If port 8443 is exposed because people administer the engine remotely, there are better ways to reach an engine than opening it to the network.
The choice that is not on the list is staying where you are. The advisory is public, the exploit is public, and the open-source build will not be patched.
Saga IT builds OpenShare Engine and supports Mirth Connect and OIE estates for hospitals, labs and HIEs. If you want a second opinion on your exposure, or help moving off an unsupported version, get in touch.