We've changed XStream to use an allowlist instead of a denylist. This means that only a strict list of types are allowed to be serialized or deserialized in Mirth Connect. This will likely have no effect on your Mirth Connect installation. However, if you have custom channel implementations that happen to serialize or deserialize types that are not allowed by default, you may encounter ForbiddenClassException errors or something similar. To fix this problem, you'll need to allow those specific types by adding one or both of the following properties to your mirth.properties file:

• xstream.allowtypes - A comma-separated list of fully-qualified classes to allow. These classes can include wildcards. Example values are com.my.package.MyClass, com.my.package.MyClass$MyInnerClass, and com.my.package.*.
• xstream.allowtypehierarchies - A comma-separated list of fully-qualified type hierarchies to allow. This means that these classes and their subclasses will be allowed. An example value is com.my.package.MyParentClass.

Please note that you can still use the property, xstream.denytypes, that allows you to explicitly deny types from being serialized or deserialized using XStream. It takes a comma-separated list of fully-qualified classes and can include wildcards. This denylist takes precedence over the allowlist.

This update was made in response to an Unauthenticated Remote Command Execution vulnerability that was identified within Mirth Connect Core version 4.4.0 and lower. Please refer to CVE-2023-43208 for more details on the vulnerability. https://nvd.nist.gov/vuln/detail/CVE-2023-43208