A Mirth Connect Login Could Turn Its Own Database Into a Public Download
The most alarming thing about a healthcare integration engine is not necessarily that it holds a database. It is that it knows how to reach so many other systems. In a controlled test of Mirth Connect 4.5.2, a security researcher used an authenticated administration API flaw to export the engine’s configuration database into a public web folder. Anyone who knew the resulting file path could then download it without logging in. The configuration included password hashes and, in a separate test, plaintext connector credentials for downstream systems.
That is one of three findings disclosed on 10 September 2026 by Abhinav Agarwal. The other two are XML external entity, or XXE, flaws in configured message-processing channels. Those do not need a Mirth account once an operator deploys a vulnerable channel and exposes its listener. The important distinction for defenders is architectural: protecting the administrator interface does not automatically protect the message routes that other systems use to send data through Mirth.
The Mirth Connect login that reached the configuration database
CVE-2026-82583 is an SQL injection in a Database Connector API operation. It requires an authenticated API session. In the publicly tested 4.5.2 build, the researcher found that a logged-in account could influence a query intended to retrieve database table information. His proof of concept pointed the query back at Mirth’s own bundled Derby configuration database. The database then wrote content to the application’s unauthenticated web directory.
That turns an admin-side input flaw into a wider disclosure problem. The researcher demonstrated export of administrator password hashes and channel configuration, including a connector password that his test setup stored in clear text. Such configuration can describe routes into databases, file services, mail systems and clinical endpoints. He also demonstrated that the same flaw could freeze the bundled Derby database until an operator restarted the process. He did not demonstrate Java code execution or access to a real downstream hospital system. The published research does not establish that any patient record or production credential was stolen.
There is an important version limit on that demonstration. The reproducible public test used the official open-source 4.5.2 container. NextGen’s 4.6 upgrade notes say later versions moved to a commercial, closed-source licensing model. The researcher could not inspect every commercial authorisation extension in the same way. CISA nevertheless lists versions through 4.7.1 as affected and recommends 4.7.2 or later. Organisations should follow that remediation guidance without treating every detail of the 4.5.2 proof of concept as a verified description of their particular commercial configuration.
Two more routes through Mirth Connect message channels
The other findings live on the data plane, where deployed channels accept messages. CVE-2026-78224 affects an XSLT processing step when operators configure an exposed channel to parse incoming XML through that feature. In the researcher’s controlled setup, a crafted message caused a server-local test file to be read and sent back through an out-of-band callback. A separate slow-entity test stopped the affected channel. That is not evidence of a whole-server outage. Nor is every Mirth channel configured this way by default.
CVE-2026-82578 is another XXE path, this time in the XML Batch Adaptor when operators enable batch processing and the relevant XPath-backed split mode. The researcher again recovered a test file from a vulnerable channel he deliberately configured. The Mirth service could read that file. He did not show that XML batching is on by default. Nor did he read a file beyond the Mirth service account’s permissions.
Attackers can reach the two channel flaws without Mirth authentication only when an operator exposes the corresponding listener to a sender and configures the particular processing feature. A firewall rule on the administrative API may reduce exposure to the SQL injection while doing nothing for a clinical message listener that has to accept traffic from another organisation. Conversely, an exposed listener does not by itself prove it has a vulnerable transformation step. Teams need the actual channel inventory, not a single yes-or-no answer about whether Mirth is internet-facing.
What an operator should do now
Establish which Mirth Connect versions are running and plan the update to 4.7.2 or later, as CISA’s medical advisory recommends. The researcher says NextGen fixed the XSLT issue in 4.7.1 and the SQL injection and XML Batch issue in 4.7.2. Applying the later version avoids relying on a partial fix. Test the upgrade against representative channels and connector dependencies before switching a clinical integration service in production.
Inventory both sides of the service. Restrict the administrative API to trusted management paths and review who has authenticated access. Separately, list every listener that accepts externally supplied messages, the organisations allowed to send to it, and whether it uses an XSLT step or XML Batch processing in the affected mode. If operators cannot upgrade a channel immediately, they should restrict its senders and remove the vulnerable processing feature where the workflow permits. Those are interim controls, not a replacement for the vendor fix.
Finally, examine what the Mirth service account can read and where its configuration database and web-served directories sit. Look for unexpected files in public web paths and unusual access to the Database Connector API or affected channel listeners. A normal-looking API response alone may not rule out the demonstrated SQL injection. If there is evidence of unauthorised configuration access, assess connector credentials and rotate those genuinely at risk. Do not treat the mere existence of a vulnerability as evidence that a particular hospital has been breached.
Mirth Connect’s role is to move information across boundaries. An earlier BlackTree analysis of a healthcare archive breach examined the concentration of patient records. A routing engine can concentrate credentials and network paths instead. These Mirth findings show that the management boundary and the message-processing boundary fail in different ways. The practical fix starts with 4.7.2, but the lasting lesson is to know both paths through the engine and the privileges of every credential it carries.
Sources
- Abhinav Agarwal, Exporting Mirth’s Database and Reading Server Files: Three Flaws in NextGen Connect, posted 10 September 2026, no time stated on the page.
- CISA, ICSMA-26-253-01, NextGen Healthcare Mirth Connect, released 10 September 2026; CISA’s bulletin records 12:00 EDT.
- NextGen Healthcare, Mirth Connect 4.6.0 upgrade notes, on the later licensing and distribution model.
Combining traditional fishing knowledge with digital technology offers an interesting way to improve both safety and the overall angling experience. I particularly like the focus on community engagement and data-driven decisions, as these tools can also encourage more responsible and sustainable fishing practices.