v26.6.1

BridgeLink 26.6.1 is a security patch for the 26.6 line. It fixes four published security flaws (CVEs) and changes nothing else about how channels behave, apart from the few cases listed below. If you run 26.6.0, apply it. 26.9.0 remains the current forward release.

☕ The Move to Java 21

Java 21 is now recommended for every BridgeLink server, and it is the Java version the installers set up by default. Java 17 remains supported for now, with one exception covered in the next section.

Item	26.6.0	26.6.1
Java runtime the installers set up	Eclipse Temurin 17.0.15	Eclipse Temurin 21.0.12.1
Java versions BridgeLink accepts	17 to 21	17 to 21
Java 17 on an external database	Supported	Supported
Java 17 on the built-in Derby database	Supported	Not supported, stops at startup

• Windows installers (.exe and .msi): set up Java 21 for the BridgeLink install.
• Linux RPM: accepts either the java-17-openjdk-headless or the java-21-openjdk-headless package. If your server uses the built-in Derby database, install the Java 21 package and make sure it is the Java that BridgeLink runs on.
• Windows .zip and macOS .tgz archives: these include no Java at all. Install Java 21 yourself before you start BridgeLink from one of them.
• BridgeLink itself is still built to run on Java 17, which is why external-database installs can stay there for now.

If you use custom Java libraries

If you have added your own JAR files to BridgeLink, through custom code templates, a custom connector, a JDBC driver for a database we do not ship, or anything in the custom-lib folder, check that each one runs on Java 21 before you move a server to it. Older libraries may need an upgrade, and a few very old ones may not have a Java 21 build at all.

• Test on a non-production server first, and watch logs/mirth.log on the first start for UnsupportedClassVersionError or NoClassDefFoundError, which are the usual signs of a library that cannot run on the newer Java.
• This applies whether or not you use the built-in Derby database. It is the main reason to plan the Java 21 move as its own piece of work rather than do it in the same window as the patch.

Windows servers moving from Java 17 to Java 21: check your text encoding

Java 18 changed the default text encoding on Windows from windows-1252 to UTF-8. So a Windows server that moves from Java 17 to Java 21 during this upgrade may read and write text differently, even though BridgeLink itself did not change.

• Who it affects: Windows servers moving from Java 17 to Java 21, with any connector whose Encoding setting is left at "Default". That includes TCP/MLLP, HTTP, File (text mode), Database and SMTP connectors. Messages with accented letters or other characters outside plain English are where you will see it.
• Linux and macOS servers almost always use UTF-8 already, so they rarely notice.
• How to check: the startup line in logs/mirth.log ends with with charset .... On Java 17 on Windows it usually says windows-1252; on Java 21 it says UTF-8.
• Fix, pick one:
  1. Set the Encoding field on each affected connector to the encoding your partners actually send.
  2. Keep the old Windows default for the whole server by adding this line to blservice.vmoptions in the BridgeLink install folder, then restarting the service:

     -Dfile.encoding=COMPAT
     

• The server.defaultencoding setting described in the 26.9.0 notes is not part of 26.6.1.

⚠️ Built-in Derby servers must move to Java 21

If your BridgeLink server uses the built-in Derby database, it needs Java 21 to start. This is the one exception to Java 17 still being supported, and there is no setting that turns it off.

To see which one you have, open conf/mirth.properties and look at the database line. database = derby means the built-in Derby database. It is the default for a new install.

Your server's database	On Java 17	On Java 21
Built-in Derby (database = derby)	Stops at startup	Runs
External database (PostgreSQL, MySQL, SQL Server, Oracle)	Runs, unaffected	Runs, recommended

BridgeLink 26.6.1 checks the Java version when it starts, before it does anything else.

• What it checks: whether database = derby and the Java version is lower than 21. If both are true, the server logs this line at the ERROR level and exits:

  embedded Derby requires Java 21+ as of 26.6.1; upgrade Java or switch to an external database
  

  It exits cleanly, before it opens the database, so nothing is changed on disk.
• Why: the Derby security fix below is only available in a Derby release that requires Java 21. Apache has not released a fixed Derby for Java 17.
• What to do, pick one:
  1. Install Java 21 and make sure BridgeLink uses it.
  2. Move BridgeLink to an external database and stay on Java 17.
• How to confirm after the upgrade: every BridgeLink start writes one line to logs/mirth.log naming the Java version, the database type and the default character set, for example:
  Running OpenJDK 64-Bit Server VM 21.0.12 on Windows Server 2022 (...), derby, with charset UTF-8.
  If that line says 17 and derby, the server will not come up.

🔐 Security fixes

Apache Derby upgrade (CVE-2022-46337)

The built-in Derby database library is upgraded to close CVE-2022-46337, a flaw in Derby's LDAP login check that could let someone get past authentication. LDAP is a directory service that some systems use to check user names and passwords.

Library	Before	After
Apache Derby (derby, derbyshared, derbytools)	10.16.1.1	10.17.1.0

• Your existing Derby database keeps its current file format. The shipped setting in conf/mirth.properties ends the database.url line with upgrade=false. With that setting, 26.6.1 opens your existing database without rewriting it, so you can still roll back to 26.6.0 if you need to.
• Do not change it to upgrade=true. That tells Derby to rewrite the database files into the 10.17 format. The rewrite is one-way: after it, 26.6.0 can no longer open the database.
• Servers on an external database do not use Derby as their database. For them this change replaces the flagged library and has no other effect.

XML external entity and SQL injection fixes (CVE-2026-78224, CVE-2026-82578, CVE-2026-82583)

These three fixes answer CISA advisory ICSMA-26-253-01. Two are XML external entity (XXE) flaws, where a crafted XML document makes the server read a file or call a web address it should not. The third is a SQL injection flaw, where crafted input gets run as a database command. They are the same fixes that ship in 26.9.0.

• CVE-2026-78224: the XSLT Transformer Step no longer loads outside DTDs or stylesheets.

  • A source document or XSLT template that points to an external DTD or external entity (a <!DOCTYPE ... SYSTEM "..."> line) now fails the step, with the error logged at the ERROR level. Some older CDA and HL7 v3 feeds carry such a line. Expect those messages to error, and look into them.
  • A stylesheet that pulls in another file or web address, through xsl:import, xsl:include or document(), also fails the step now. If a stylesheet loads a lookup table that way, supply that data another way.
  • Self-contained transforms with no outside references are unaffected, and Java extension functions in stylesheets keep working.
  • If the step uses a custom TransformerFactory (for example Saxon) that does not accept these protections, the step still runs, but it is not protected, and the server logs a WARN line starting with XSLT Step: custom TransformerFactory ... rejected. Watch for that line after upgrading.

• CVE-2026-82578: XML batch processing with the XPath split option no longer loads outside entities or DTDs. Batch XML is now read with a locked-down parser before the XPath split runs. A batch that used to pull in an external entity or DTD is split without it. A batch with only an internal DTD still parses and splits normally, and XPath queries that rely on namespaces match the same nodes as before.

• CVE-2026-82583: the Database connector's Get Tables call is closed to SQL injection. This is the POST /connectors/jdbc/_getTables API, used when you browse tables while setting up a Database Reader or Writer.

  • The selectLimit query is run only when it matches one of the shipped safe shapes (SELECT * FROM ? with an optional LIMIT, TOP, WHERE ROWNUM or FETCH FIRST clause). It now runs with a five second timeout and returns at most one row.
  • A custom selectLimit that does not match, or a table or schema name that contains anything other than letters, digits, _, . or $, is not run. BridgeLink reads the columns through the standard database lookup instead. That lookup gives the same column list but can be slower on very large databases.
  • Get Tables calls now appear in the audit log. The connection URL and the password are left out of the record.

Upgrading from 26.6.0

• No database schema changes. 26.6.1 upgrades a 26.6.0 server in place.
• Plugins shipped with the product: the OIDC Authentication, Version History, Message Trends and Dynamic Lookup Gateway plugins are marked compatible with 26.6.1.
• WebAdmin version mismatch warning. To get these security fixes out quickly, WebAdmin was not rebuilt for 26.6.1. A WebAdmin from 26.6.0 connected to a 26.6.1 server reports a version mismatch. This can be safely ignored. It does not block login and it does not affect anything the two do together. A matching WebAdmin build will follow.
• Before you upgrade a built-in Derby server, confirm Java 21 is in place (see above). The upgrade itself will not stop you, but the server will not start afterward on Java 17.

Downloads

OS	Arch	Download Link
Windows	x64	Installer
Windows	x64	Zip
Linux	x64	RPM
Linux	x64	Tar.gz
Linux	x64	Installer
macOS	ARM	Installer
macOS	ARM	Tar.gz

Getting Help

If you would like a hand planning the Java 21 move, testing the upgrade, or getting through the maintenance window, Innovar Healthcare's team can help with as much or as little as you want. Contact support@innovarhealthcare.com.