Release notes

Now supports two standard formats for SBOM generation:

• SPDX (Software Package Data Exchange): Developed by the Linux Foundation, SPDX is an open-source, machine-readable format designed to promote transparency and compliance in open-source and proprietary software management.
• CycloneDX (CDX): Created by the OWASP community, CycloneDX is another open-source, machine-readable format that prioritizes ease of use and automation in SBOM generation throughout the software development lifecycle.

Introduces new settings to filter data by workflow, by user, by source in Executive Report.

There is an ability to switch statistics display on file or object.

Introduces an updated system health dashboard that offers a new way to visualize scan queue and allocation.

Introduces Max download queue setting which you can modify number of file downloads at a time for your use case and network.

Also introduces pattern validation setting which users define blocklist and allowlist based on link pattern.

You can find these in Settings\Security tab. For more details: Scan from link settings

• Supports proxy for On-Premises License Management Server (OLMS).
• Provides improved visibility for SAML SSO user directory settings.
• Supports Windows 11, version 23H2.
• Changes the display name for decrypted documents.
• Allows users to export and import queue size settings.
• Enhances the support package generation script to enable users to collect a variety of log files from newest to oldest. For more information, see How to Create Support Package?
• Enables users to search for file types in Blocklist and Allowlist settings.
• Exposes sanitized file sizes in the REST API, even when they are 0 bytes.
• Allows users to switch between hours and days for setting the "Definition age threshold" under Workflow Rule \ Metascan.
• Optimizes processing report synchronization for My OPSWAT.
• Mode switching (from Standalone to Shared) during upgrade is no longer supported. Users are recommended to setup a Shared DB instance through a fresh installation instead.

The Adaptive Sandbox engine now scans only supported archive file types that are selected by users in Workflow Rules.

Nested files within supported archive file types will no longer be scanned by the Adaptive Sandbox engine.

This enhancement helps ensure that the Adaptive Sandbox engine focuses on processing relevant files, improving performance and overall system efficiency.

Implemented additional validations for administrative configurations and the scan-from-link feature.

Addressed vulnerabilities:

• Upgraded the bundled PostgreSQL database to version 14.13 for CVE-2024-7348.
• Upgraded Qt to version 6.5.3.
• Upgraded nghttp2 to version 1.61.0.
• Upgraded curl to version 8.9.1 in the Docker image.

Allows users to add license comments during activation.

• Introduces a new optional parameter, MDCORE_LICENSE_COMMENT, type string.

Provides new settings for the On-Premises License Management Server (OLMS) proxy.

• For more details: Docker run parameters

• Optimized logging for unlicensing events.
• Added more logs for synchronous operations.

• Changed the YARA engine name.
• Froze the header in the engine detail table.
• Implemented minor user interface refinements.

Resolved a database connection issue that occurred after users upgraded to version 5.11.0.

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

If the application was previously upgraded from version 5.5.1 (or older) to version 5.6.0 (or newer), this issue would occur when users upgraded to version 5.11.0.

• Addressed an issue where the ometascan process consumed excessive memory when serving scan-from-link requests.
• Resolved an issue that prevented users from searching Processing History for AD users.
• Fixed an issue that prevented header metadata from working with Hub.

This issue is resolved in version 5.11.1.

This issue does not affect all cases when upgrading to v5.11.0.

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

• If 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 KB for troubleshooting the issue and bring the system back to work: How to Troubleshoot an Error related to Connection to Database Failing after an Upgrade to v5.11.0?

In the following cases, users will not experience the issue:

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

This issue is resolved in version 5.10.1.

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.

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 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. For more details, refer to Health check settings.

This issue is resolved in version 5.6.0.

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.

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.

This issue is resolved in version 5.5.1.

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 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.

This issue is resolved in version 5.4.1.

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

MetaDefender Core 5.2.1 or later versions might not function correctly with Red Hat or CentOS operating systems using kernel 372.13.

Red Hat appears to be addressing the kernel issues. 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 and later versions, OpenSSL 1.x has been replaced by OpenSSL 3.x within the product and its dependencies (PostgreSQL, 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.

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