Release notes

This technology can detect known malicious IP addresses and domains inside document files.

To enable the technology, you need to contact OPSWAT to update your license. Then you can just go to Workflow Rule, turn the switch on and explore its capability.

For more details, please refer to InSights Threat Intelligence.

To focus needed requests and save up resources, it is necessary to introduce a triggering condition for Post Action where Administrators can select and filter what verdicts to trigger the actions only.

Introduced a setting to add an extra layer of security that makes files produced by Deep CDR or Proactive DLP unavailable for download when original file's result is flagged as Blocked for any reasons.

This setting is off by default and can be found under tab General in workflow rule.

When analysis mode is turned on in workflow rule, Deep CDR no longer sanitize file, remove object and generate a new file. Instead, the technology will report objects inside the file for analysis purpose.

Under this mode, you can see a tag flagging the mode on, number of detected objects and a neutral green message.

Precisely calculate "hash time" of nested files to have more relevant "Child files hashing" time.

Users now can granularly customize time period in Data Retention settings.

Moderate UI changes to display hash values in full text as well as make other metadata result shown more clearly.

Enabled verdict searching in Advanced filter of Processing History.

New option to block files whose size is larger than file size threshold of Adaptive Sandbox.

Users now can download list of IoCs detected by Adaptive Sandbox from the web console.

In Linux non-persistent mode and local scan method, webhook callback is enhanced to ensure responses eventually to be sent even if there is permission issue or else with scanned local files.

Upgrade OpenSSL to v3.4.0 for vulnerability fix.

Upgrade protobuf to v3.21.12 for vulnerability fixes.

• Addressed an issue that caused service crash when validating non-existed ID of output files returned by Deep CDR and Proactive DLP.
• Addressed an issue that might cause memory leak when using scan-from-link feature.
• Addressed an issue that caused service unresponsive due to slow data retention process.
• Addressed an issue that made upgrade process and service hang in container while running with remote PostgreSQL v14 Windows.
• Addressed an issue that was "Fallback file type detection to current extension if needed" setting did not apply to Proactive DLP.
• Addressed an issue that caused misleading Proactive DLP result while processing archive file. It displayed "No Specific Configuration" meanwhile it should have been "Unsupported File Type".
• Addressed an issue that misvalidated setting file during Import process and made workflow rules inaccessible.
• Addressed an issue that caused SSL handshake error when downloading file with scan-from-link feature.
• Addressed an issue that caused product in Rocky container did not automatically activate license after HTTPS enabled.
• Addressed an issue that caused misleading Metascan result in PDF result of a batch. It displayed "No Threat Detected" whilst it should have been "Not Scanned".

• On Average File Size chart, title sometimes was not truncated correctly.
• Fixed an issue that caused UI infinite reload on Change Password screen.
• Fixed an issue that caused Accessibility mode not be switched with Tab and Enter keys.
• Fixed an issue that wrongly displayed "No Specific Configuration" at Deep CDR tile despite of the fact that result is "Sanitization Failed".
• Other minor bugs.

This issue has been resolved in version 5.11.1.

This issue does not affect all cases when upgrading to version 5.11.0.

After applying the authentication method scram-sha-256 to enhance security for the bundled PostgreSQL, a database connection issue started occurring after the upgrade, in a specific circumstance.

• If the application was previously upgraded from version 5.5.1 or older to version 5.6.0 or newer, this issue will occur when users upgrade to version 5.11.0.

We prepare a Knowledge Base (KB) for troubleshooting the issue and bringing the system back online: How to Troubleshoot an Error related to Connection to Database Failing after an Upgrade to v5.11.0?

The issue will not occur in the following scenarios:

• Upgrading directly from version 5.5.1 or older to version 5.11.0.
• Upgrading from a fresh installation of version 5.6.0 or newer to version 5.11.0.

This issue has been resolved in version 5.10.1.

Since its introduction in version 5.8.0, this feature has helped improve overall performance and reduce significant load when processing similar files.

However, we have realized this feature might run slowly in high-load scenarios against large database sizes.

This issue occurs only in containerized environments.

If the config zip file includes non-empty required_engines setting, MetaDefender Core will reject the import.

Workaround:

1. Extract the config zip file.
2. Open the "export_settings.json" and set "required_engines" to an empty array.
3. Recompress the files into a new zip.
4. When executing the docker run command, set the following environment variables: MDCORE_HEALTH_CHECK, MDCORE_REQUIRED_ENGINES. For more details, please refer to Health check settings.

This issue has been resolved in version 5.6.0.

When modifying settings in Workflow Rule, the 'Revert to Default' button may sometimes disappear and become non-functional. This behavior was encountered in version 5.5.0.

We have observed that the Engine Update feature may not work properly in an environment protected by a [Palo Alto firewall](Palo Alto firewall). In the log file, you might find the error message 'SslHandshakeFailedError'.

If upgrading to the latest version of MetaDefender Core does not solve the issue, please consider setting up MetaDefender Update Downloader product. This product is responsible for downloading engines, and MetaDefender Core will retrieve and update its engines from there.

This issue has been resolved in version 5.5.1.

MetaDefender Core version 5.5.0 introduces significant changes to support UI accessibility. However, this leads to an inconvenient issue when displaying Workflow Rule on small or zoomed-in resolution screens. Some tabs at the bottom of the list may not be displayed properly.

Workaround: Try zooming out a little bit on the browser.

This issue has been resolved in MetaDefender Core version 5.5.0 and the Archive Extraction engine version 6.2.1.

• If you're using MetaDefender Core version 5.4.1, you can update the Archive Extraction engine to version 6.2.1 or newer without waiting for MetaDefender Core version 5.5.0 release.
• If you're using MetaDefender Core 5.4.0 or older, you can upgrade it to version 5.4.1 or newer, and update the Archive Extraction engine to version 6.2.1 or newer. If you are not able to upgrade MetaDefender Core, it is recommended to stick with the Archive Extraction engine version 6.0.2 until you are able to upgrade MetaDefender Core.

This issue has been resolved in version 5.4.1.

The FileType engine version 6.0.2 may generate malformed data, which can negatively impact MetaDefender Core version 5.4.0 or older when written to the PostgreSQL database:

• The Executive Report in Dashboard may become frozen and revert to zero.
• CPU usage may increase excessively.
• A significant decrease in file processing performance may occur.

If you experience similar issues, follow these troubleshooting steps to resolve the problem: Rectify malformed FileType data in PostgreSQL database

MetaDefender Core version 5.2.1 or later may not function correctly with Red Hat or CentOS operating systems that use kernel 372.13.

Red Hat is addressing the kernel issues. Please try upgrading to kernel version 372.26.

This issue was addressed in MetaDefender Core v5.11.1

In a containerized environment, MetaDefender Core version 5.2.0 or newer may work properly when:

• The Linux kernel version of the host machine is newer than 4.18.0 including 5.x.y and 6.x.y.
• The Docker base image is CentOS 7.
• The bundled PostgreSQL database is used (DB_TYPE=local).

Workarounds for older versions:

1. Switch to using a Docker base image RHEL 8 or Debian.
2. Switch to using a remote PostgreSQL database.

On MetaDefender Core version 5.2.0 and later, OpenSSL 1.x has been replaced by OpenSSL 3.x within the product and its dependencies, including PostgreSQL and NGINX, to enhance security and address known vulnerabilities in OpenSSL 1.x.

However, NGINX's implementation of OpenSSL 3.x in MetaDefender Core enforces strong encryption by rejecting all weak cipher suites. It only accepts "HIGH" encryption cipher suites as defined by OpenSSL https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. This means ciphers based on MD5 and SHA1 hashing are no longer supported.

Consequently, if you previously configured MetaDefender Core for HTTPS connections using a weak SSL cipher with your certificate, the service will not start due to NGINX's OpenSSL 3.x security enforcement.

To prevent and remediate the issue before upgrading MetaDefender Core, please refer to the following resources: HTTPS Failure on MetaDefender Core 5.2.0 (or newer)

MetaDefender Core has a limitation when compressing very large archive files that contain a high number of subfiles. In our test scenario, it failed when processing an archive with 300,000 or more subfiles.

This matter is being researched actively.