Release notes

When enabling a new setting Nested Group Login, the product allows users who are indirect members of an AD group to log in and take on the corresponding roles and rights.

MetaDefender Core now supports CIS Level 1 for RHEL 9.

For more details, refer to CIS Level 1 Guidelines.

Introduces filtration options for the display of processing results, enabling users to quickly filter which file types violate the blocklist policy.

• Boosts hash lookup performance.
• Refines new REST API parameters for better functionality and usability.
• Users can now download a CSV template for easy content input, simplifying data entry processes.

• Ability to export history based on status Allowed or Blocked.

• New column: File size.

• New filtration option: by Duration.

Giving users more flexibility to analyze their own files with Adaptive Sandbox.

With this setting, only files containing specific Active Content(s) will be analyzed by Adaptive Sandbox engine.

Please note that this setting is only available when Core is used with Adaptive Sandbox version 2.1.0.

Total size is sanitized and processed by Deep CDR.

• Support new operator 'smaller than' for file size condition in Blocklist& Allowlist.
• REST API Fetch a list of blocked leaf files inside archiveAPI now includes AV engine name and detected threat name.
• Addressed a case where Firefox browser sometimes incorrectly detects CSV file type, causing CSV uploading to fail with message 'File format is invalid. Please upload a CSV file.'
• Added more options for Data Retention of sanitized files and the Proactive DLP engine processed files.
• Based on the override classification in Workflow Rule making blocking decision for the SBOM engine results.
• Begin including engine state in export and import progress.
• Support AD domain controller.
• Removed PLPython from bundled PostgreSQL in Linux.
• Improved validation for file scanning.
• No longer deploy and initialize unsupported engine types.
• Distribute SHA256 and file size data to the SBOM engine for analysis.
• Move 'File download' timeout setting from MetaScan tab to General tab.
• Group settings 'Enabled file hash for only selected types' and 'Skip Hash Calculation'.

Support a REST API to download digitally signed status reports for the entire batch. The specification is the same as Download Signed Batch ResultAPI.

Support a REST API to fetch the product version. The specification is the same as Get Product VersionAPI.

• Updated the UI to reflect engine state in case of inactivity.
• Ensured color consistency for table titles across UI modes.
• Implemented minor user interface refinements.

• Fixed an issue that caused the filename of the sanitized file to be assigned a different text than the workflow rule setting 'Output filename format', when the 'Reuse processing result' feature was enabled.
• Fixed an issue that caused a JSON attribute to be set incorrectly for encrypted archive files.
• Addressed a bug that caused newly supported file types to not be automatically checked after Deep CDR was updated.
• Improved an inconvenience with Allowlist/Blocklistsettings where users were unable to save changes, and instead received an error message 'No modification detected'.
• Fixed an issue that caused the Revertbutton to disappear sometimes.
• Fixed a problem that led to incorrect sanitization results due to a miscalculation of the tombstone files quantity.
• Fixed an issue that displayed an empty first page of Module Update history when no search criteria were specified.
• Fixed a potential data race in sending webhook result by multiple workers.
• Fixed an issue that caused activation to not be cleaned up properly in a Docker container.
• Fixed an issue that generated wrong database name when running in standalone mode with the parameter IGNITION_JSON in Docker container.
• Fixed an issue with Non-persistent mode that prevented the service from starting in Docker container.

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)