Release notes

Improved security by upgrading the at-rest encryption algorithm to AES (Advanced Encryption Standard).

Sensitive data stored in the system will now be protected using AES encryption algorithm, enhancing the confidentiality and integrity.

SBOM technology introduces enhanced capabilities for analyzing and detecting license issues to gain deeper insights into the licensing status of the software components they use, ensuring compliance and minimizing legal risks.

It offers an improved interface describing the license analyzing and detailed reports.

• Splitting the waiting time for the Adaptive Sandbox engine from the "Others" time to provides better visibility into the Adaptive Sandbox analysis process, enabling users to identify and address any scan time effectively.
• Users can now perform a look-up of quarantined files using hash values.
• Extended the support for the API download quarantine functionality by accepting input SHA256 hash values as uppercase.
• Displaying a "No License" message when enrolling MD Core to My OPSAWT without license.

• Enhanced a case that dedicated slots of scan queue might not be applied when scanning archive files.
• Standardized user validation and license validation to reduce the cost and time.

Introduced the capability to make External Scanners a mandatory engine for scanning processes.

Users can now tailor their scanning process by designating External Scanner as a required engine.

Users will not encounter difficulty when attempting to upgrade MD Core on Docker even if their database password contained specific characters: */-+?<>:{}[]()*&^%$#@~`;.,

" (double quotation) and ' (quotation) are not supported.

Previously, MD Core performed an upgrade process that required verifying the available disk space before proceeding. However, in Azure PostgreSQL and RDS environments, lacking super-user permissions prevented MD Core from performing this upgrade process, causing unnecessary delays and complications.

Since disk space can be automatically scaled when necessary in these cloud environments, it is no longer necessary to verify available disk space beforehand.

Since its introduction in v5.8.0, the "Reuse processing result by hash" feature has provided performance improvement and reduced the processing load for similar files.

However, we have identified that this feature may experience slow performance when operating under high load with large database size.

This issue is now fixed, and the feature is more stable in v5.10.1.

• Addressed an issue that in certain circumstances, when MD Core sent a stop task, but Archive engine had not finished opening the corresponding file, temporary files in the Archive Extraction temp folder were not cleaned up by the engine.
• Fixed an issue by ensuring that even if MD Core has realized a timeout and removed the stop extraction task, the response from Archive engine will still be processed correctly, and the associated temporary file will be removed accordingly.
• Resolved a corner case where task_id of next and stop tasks were duplicated, leading to the retention of the temporary file.
• In high-load situations, when Archive engine received a next task and proceeded to extract a file, but MD Core experienced a timeout while waiting for a response, later responses from Archive engine regarding successfully extracted files will still be processed and acknowledged to ensure proper cleanup of extracted files.

• Addressed an issue where upgrading from older versions to version 5.7.1 or newer was not possible when using non-persistent mode in Linux environments.
• Fixed an issue with the rotation of engine log files. It will now rotate correctly according to the configured rotation settings.
• Resolved an issue where scan results were not updating correctly when canceling scans that involved External Scanners.
• When using the Accessibility mode, there was a UI issue where only one AV engine appeared on the Modules screen, instead of displaying all available AV engines.
• Fixed an issue where Webhook Authentication would fail after upgrading the system.

Identified a memory leak issue where abandoned resources were not cleaned up when a request timed out in the queue.

This issue has been addressed, ensuring that resources are appropriately cleaned up and preventing memory leaks.

• Could not save configuration on My OPSWAT UI when session lifetime almost pasts.
• Logs were flood with numerous "Config was changed on OCM" message when license is changed.

• Failure to logging in with SSO.
• Could not import configuration with v2 method.
• Failed to add Webhook Certificate, External Scanner and Post Action.
• Several redundant error logs appear when using this mode.

Since introduced in v5.8.0, this feature helps improve overall performance and reduce considerable load when processing similar files.

However, we have realized this feature might run slowly in high load against large DB size.

This issue is addressed in version 5.10.1.

Only happen to containerized environments.

If config zip file include non-empty required_enginessetting, MetaDefender Core will reject importing the file.

Workaround:

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

When modifying settings in Workflow Rule, sometimes button "Revert to Default" disappears and cannot work properly. This behavior might be encountered in version 5.5.0.

This issue is addressed and resolved in version 5.6.0.

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

In case that upgrading to the latest version of MetaDefender Core does not help, please consider setting up MetaDefender Update Downloader product. This product is responsible for downloading engines, and MetaDefender Core will pick and update its engines from there.

MetaDefender Core 5.5.0 introduces a lot of changes for supporting UI accessibility. Unfortunately, this leads to an inconvenience issue when displaying Workflow Rule on small/zoomed-in resolution screen. Some tabs at the bottom of the list will not be displayed properly. Workaround: zooming out a little bit on the browser.

This issue is addressed and resolved in version 5.5.1.

This issue is addressed and resolved in MD Core v5.5.0 and Archive v6.2.1.

• If using MetaDefender Core 5.4.1, then you can update Archive Extraction engine version to 6.2.1 or newer without waiting for MetaDefender Core 5.5.0 release.
• If using MetaDefender Core 5.4.0 or older, then you can upgrade it to version 5.4.1 or newer, and update Archive Extraction engine to 6.2.1 or newer. If you are not able to upgrade MetaDefender Core, then you should stick around on Archive engine 6.0.2, until you are able to upgrade Core.

FileType version 6.0.2 sometimes created malformed data. After being written into PostgreSQL database, those malformed data cause negative impacts to MetaDefender Core v5.4.0 or older:

• Executive Report in Dashboard gets frozen and changed back to zero.
• CPU usage will go too high.
• A dramatical decrease in file processing performance.

If you encounter similar symptoms, please find the following troubleshooting to resolve the issue: Rectify malformed FileType data in PostgreSQL database

This issue is addressed and resolved in version 5.4.1.

MetaDefender Core 5.2.1 or above might not be able to work properly with Red Hat /Cent OS with its kernel 372.13.

The vendor Red Hat seems to be fixing the issues with the kernel. Please try upgrading to kernel version 372.26.

In containerized environment, MetaDefender Core 5.2.0 or newer cannot work properly when:

• Linux kernel version of host machine is newer than 4.18.0. This also includes 5.x.y and 6.x.y.
• And Docker base image is CentOS 7.
• And using bundled PostgreSQL (DB_TYPE=local).

Workarounds:

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

On MetaDefender Core 5.2.0 or newer, OpenSSL 1.x is replaced by OpenSSL 3.x within the product and other dependencies (PostgreSQL, NGINX) as a security improvement, and prevent known vulnerabilities found on OpenSSL 1.x

NGINX's OpenSSL 3.x on MetaDefender Core has the enforcement in place to reject all weak cipher suites. It only accepts "HIGH" encryption cipher suites https://www.openssl.org/docs/man1.1.1/man1/ciphers.html (MD5 and SHA1 hashing based will not be accepted as well).

As a result, if you already configured MetaDefender Core for HTTPS connection, but using a weak SSL cipher with your certificate, then MetaDefender Core will not be able to start due to NGINX's OpenSSL 3.x enforcement.

For prevention and remediation before upgrading MetaDefender Core, learn more at HTTPS Failure on MetaDefender Core 5.2.0 (or newer)