Release notes

This feature enhances upload efficiency and reliability for large data transfer.

• Seamless handling of large files: Clients can now upload files seamlessly by breaking them into smaller parts
• Simultaneous part uploads: Clients can upload multiple parts of a file simultaneously, further boosting speed and efficiency of the upload process.
• Resumable part uploads: In case of network interruption or even after a restart of MetaDefender Core service, clients can now resume part uploading from where it left off.

Multipart uploading support can work with Standalone mode and Shared mode. For Shared mode, client needs to ensure that parts of a file must be sent to 1 MetaDefender Core instance.

This mechanism is only compatible with Asynchronous scan, Batch scan and Webhook functionality.

REST APIs:

• Initiate multipart upload session: POST /file/multipartAPI
• Upload individual part of file to the conducted session: POST /file/multipart/{dataID}API
• Check uploading status: GET /file/multipart/{dataID}API
• Abort multipart uploading: DELETE /file/multipart/{dataID}API

Users can enable this mechanism in Workflow Rule and set a time-to-live for received parts.

Module Update settings and Data Retention settings are now managed in My OPSWAT product inventory.

After enrolled, these settings will be locked on MetaDefender Core management console, and users can only make changes on My OPSWAT console.

Now Central Hub offers the ability for client to cancel their scan requests submitted to MetaDefender Core instances behind it.

• Single file and Archive file
• Distributed archive file
• Batch

Size of the product queue (processing slots) now can be adjusted and defined on management console.

Note: setting this size too high could end up a potential risk of overloading MetaDefender Core and affecting the entire scanning service.

Introducing support for SHA-512 hash type for enhanced security.

You can toggle a new option in Workflow Rule to enable this new hash calculation.

This release introduces new settings for Metascan thresholds.

MetaDefender Core will reject file submission when there are too many outdated AV engines.

Error message in this case: "Failed to request scan. Insufficient number of up-to-date anti-malware engines"

You can find the settings in Workflow Rule > Metascan, and configure definition age (days) and number of outdated engines.

Ability to display a custom notice during login process.

You can find and customize the notice in Settings > General.

• Non-persistent and Central Hub modes will not sync scan reports with My OPSWAT.
• Optimize database partition creation for smoother performance.
• Enhanced startup process to ensure service reliability, even with prolonged or failed temporary directory cleanup.
• Added support for handling "General unextractable error" from Archive Extraction engine.
• Expanded reuse of processing results by hash to include metadata header.
• Corrected sanitization result for nested files in archives when reusing processing results by hash.
• Improved backup method for database configuration files.
• Accelerated Data Retention for Processing History.
• Prevent engine initialization during paused update time when downloaded packages exist.
• Added filter for batch scans in Processing History.
• Introduced "Skipped assessment" verdict for File-based Vulnerability engine when "Skip hash calculation" is enabled in workflow rule.
• Restructure workflow settings for Filetype engine.

• Optimized ID generation process.
• Enhanced report synchronization for improved performance impact when enrolled in My OPSWAT.
• Improved dedicated slots allocation for efficient archive file scanning.
• Standardized user and license validation for reduced costs and processing time.

• Implemented additional validations for administrative configurations.
• Upgraded bundled PostgreSQL authentication method scram-sha-256 for enhanced security.

MetaDefender Core starts supporting remote PostgreSQL database v15, and now can work with PostgreSQL either v14 or v15.

Product does not perform any version upgrade on customer's remote PostgreSQL.

Note: The bundled PostgreSQL version remains at v14.11 in this release.

• Expanded logging for "Pause scheduled updates" feature.
• Incorporated rootDataId into Hub log messages.
• Implemented Workflow deletion tracking in logs.
• Increased logging for the cleaning process during service startup.
• Optimized log writing to reduce redundancy.

• Enhanced UI accessibility across multiple areas.
• Implemented minor UI refinements.

• Corrected discrepancy between actual and file submission counts on the Dashboard.
• Resolved a service crash issue occurring during its restart after My OPSWAT enrollment.
• Fixed missing "=== END ===" long marker on Debian when stopping the service.
• Addressed inaccurate processed objects counts in Executive Report and Processing.
• Correct pagination errors when adjusting the items per page.
• Resolved reuse processing result by hash history incompatibility with URL encoding metadata headers.
• Eliminated leftover files after import failures.
• Resolved performance degradation in shared DB mode that occurred when more than 4 instances were running concurrently, particularly affecting handling of high traffic loads.

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 will be resolved in version 5.11.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.

This issue is addressed in version 5.10.1.

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.

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