Release notes

The new setting under "Post Action" section in MetaDefender Core workflow rule (disabled by default) will let authorized users configure the product to scan for the pre-defined final output code returned by your custom post action script (or custom post action webhook server) to determine if the final processing verdict should be overriden as "blocked" by that or not.

This new setting create an opportunity for MetaDefender Core customers to customize even better their security policy with their own action's logic.

The new setting under "General" section in MetaDefender Core workflow rule (disabled by default) will let authorized users configure the product to automatically reuse eligible processed results with the same hash for all other in-progress submitted requests.

A great approach to tremendously boost up the entire processing throughput for certain use-cases such as Email Security, DevSecOps, Cross Domain etc. to avoid repeatedly processing same files within a short time period.

Learn more at Reuse scan results for the same hash

Enrich supported OS porfolio in MetaDefender Core with new support for Red Hat Enterprise 9.

List of all current supported Linux-based OS: [Linux Supported Operating Systems,linux-supported-operating-systems]

Note: For Deep CDR engine, it is required to install all neccessary libraries mentioned in .NET 5 dependencies on RHEL 9

• Prevent potential brute force attack with forgot-password entries by applying cool down period.

• Improve LOCAL scan mode on MetaDefender Core (by using scan request header filepath) to prevent unpredicted behavior when processed files are altered (moved / deleted), but they appear in many other different local locations. Beneficial for File upload or Cross domain use-cases.
• Allow you to track hostname of endpoint machine, and client side's logged-on user information on each MetaDefender Core scan session via using current_logged_on_user and hostnamekey under metadata header respectively, and this information will be displayed under MetaDefender Core processing history UI at "metadata" column (hidden by default).

For example, you can specify the information for client endpoint's host name and current logged-on user by writing those information in your scan request's header metadataas following:

{ "hostname": "<hostname>", "current_logged_on_user": "<whoami>" }

• Set value of 0 (zero) to scan queue threshold under MetaDefender Core health check now means that, MetaDefender Core will disable checking scan queue status as an input for its health check logic (Legacy previous logic: setting 0 means when no current on-going scans, then it will meet the condition for heath check logic).

• Support URL encode for metadata header applied in file or batch processing request.
• Track the last login time for local and SSO user when they login via POST /login request.
• Include host name information via using new header X-Core-Id of the response HTTP 503 (scan queue is full) returned to POST /file request.
• Disable (uncheck) Deep CDR advanced setting Remove conditional comment belongs to HTML under MetaDefender Email Gateway Security workflow rule due to Outlook HTML parser limitations.

• Cache user session information in memory for user validation in every applicable scan request, so MetaDefender Core can skip database reading and improve processing speed.

• Log all SQL statements which took longer time than expecterd in bundled PostgreSQL database log.
• Enhance MetaDefender Core log for the scan-from-download-link feature to write more information for both sucessful (HTTP 200) and unsucessful (non 200 HTTP) circumstances.
• Include details of each engine process (path, process ID, working-set size) running under MetaDefender Core in the product support package.

• UI notification when MetaDefender Core configurations are locked due to being managed by Central Management.
• Some UI cosmetic updates.

• Import configuration with big amount of blocklist rules could freeze up MetaDefender Core.
• Quarantined files could be corrupted and unrecoverable under certain circumstance.
• MetaDefender Core randomly crashed at some points when running under "distributed extraction" mode as a part of Central Hub architecture.
• In K8S deployment, random MetaDefender Core instance restarted when starting all available MetaDefender Core instances at the same time in shared and remote PostgreSQL database mode.
• In docker mode, MetaDefender Core cannot start when making change on environmental variable CORE_DATA _PATH without attached volume.
• Other minor bugs fixes.

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)