Release notes

The OPSWAT Reputation Engine enables instant threat identification by comparing hashes against a growing database cataloging known good and bad files.

The Reputation Engine utilizes hash reputation based on advanced analysis like metadata evaluation, content inspection, and contextual correlation to minimize false positives. This allows accurate threat detection with limited business disruption. Through database updates and hash contributions, the Reputation Engine enhances protection against new and evolving attacks.

In MetaDefender Core, customers need to opt-in to enable the Reputation Engine through the workflow management settings:

Learn more details at Overview

Warning: The Reputation engine will be automatically added into all existing and new customers' license to fulfill our security protection committed to our customers. That means the engine will be downloaded and deployed when applicable, but users must opt-in to enable the engine's processing under MetaDefender Core workflow rule.

Without taking any action to enable it, this engine deployment should not cause any impact to our customers integration and scanning service.

The OPSWAT Country of Origin (COO) engine enables instant detection of a file's geographic source. It analyzes digital fingerprints and metadata to identify restricted locations and vendors automatically. This allows precise filtering that blocks unauthorized data access based on origin while ensuring cross-region regulatory compliance.

The COO engine provides organizations with visibility into file upload origins. With precise data origin insights, organizations can streamline audits, protect sensitive data, and prevent malicious file uploads. This enhances security and compliance at reduced cost.

By combining advanced technologies like Deep Content Disarm and Reconstruction (Deep CDR), Multiscanning, and Proactive Data Loss Prevention with origin-based access controls, organizations can secure intellectual property, maintain compliance, and block illegal or non-compliant foreign data. This mitigates breach risks and avoids substantial fines per regulations like GDPR.

The COO engine supports signed file types like PE files, MSI, and Self-extract.

Customers can now enable it in MetaDefender Core:

Learn more details at Country of Origin

Warning: For those customers who using older version of MetaDefender Core where we provided a feature for allowlisting files based on vendor, then those settings will be migrated to COO engine's settings under MetaDefender Core workflow rule on the latest version.

In that case (applicable to whom already using existing older version of MetaDefender Core's allowlisting file based on vendor), COO engine is not licensed by default for customers, so please reach out to OPSWAT to acquire license for COO engine and use that license before upgrading your MetaDefender Core to ensure settings migration to be made properly.

Once upgraded, exppecting that COO engine will be displayed on MetaDefender Core inventory page, but inactive. It requires users to disable COO engine and re-enable it back. All previous allowlisting file based on vendor's settings will be then found under "Country Of Origin" tab in the corresponding workflow rule.

Windows Server 2012 has been out of support by the vendor (Microsoft) since Oct 2023 - Reference: https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support

MetaDefender Core version 5.9.0 will no longer support this OS version, and recommend our customers migrating their systems to newer supported Windows Server version.

List of current supported Windows OS versions can be found at Supported Windows Operating Systems.

Strengthening MetaDefender Core's security by protecting users' API key (if created) in the database using SHA256 hashing. Then actual API key value could not be retrieved back for good.

By default, this feature is not enabled for backward compatibility. Administrators need to opt-in by enabling that. Expecting to see the following UI notification poped up upon signed in:

Warning: Once enabled, administrators cannot turn back the feature for security enforcement. Before switching on this feature, it's strongly recommended to backup your users' API key in a secured vault / secrets manager.

__

When this feature is enabled, API key will be hashed out in the database, and no one, including administrators, will be able to see actual API key value anywhere in the product.

In case API key is lost or not remembered, then administrators must re-create a new one. The new one will be displayed for only one time on the UI.

Note: Nothing should be changed from client side integration, client should keep using actual API key in plain text for REST API calls.

That also includes PosgreSQL 14.11 bundled with MetaDefender Core for local bundle database deployment.

This upgrade addressed PostgreSQL own vulnerabilities in older versions, and helps protect our customers from supply chain attack.

Supporting a new option to allow users to block all except certain things against file name.

• Distributed archive compression is supported.
• Metadata header is supported for Proactive DLP while running in Central Hub
• Country of Origin and Reputation engines are supported.
• Secure API key is supported.
• Including instance name in status response API.
• Enhanced the organization of files in an archive result and a batch result by sorting based on statuses and verdicts.
• Optimized batch processing in Central Hub.
• Optimized request header processing in Central Hub.
• Upgraded to OpenSSL 3.2.0 for vulnerabilities.
• Upgraded to Hiredis 1.2.0 for vulnerabilities.
• Upgraded to Nghttp2 1.58.0 for vulnerabilities.
• Upgraded to rabbitmq-c 0.13.0 for performance.

• New option to disable user information caching via using designated administrative REST API endpoint (PUT /admin/config/cacheuser). Details at MetaDefender CoreAPI
• Upgraded to PostgreSQL 14.11 bundled with the product for vulnerabilities.
• Upgraded to OpenSSL 3.2.0 bundled with the product for vulnerabilities.
• Handled URL encoded characters.
• Removed Lodash version in product JS file.
• Addressed minor potential security related issues.

• Updated default parallel count setting value (maximum number of threads) for Sandbox engine to 5 (formerly 20).
• Enhanced engine deintialization mechanism to ensure all dependent engine process(es) cleaned up and stopped gradually.
• Prioritized to list and display all blocked nested files inside batch first over allowed items.
• Supported to process scan request with local file path contains double backslash characters.
• Changed the Content-Type header value for POST /file and POST /admin/update/upload (old: application/json; charset=utf-8 - new: application/octet-stream)
• When setting value for global/tempdirectory key for MetaDefender Core temporary folder, if that folder does not exist, now the product no longer automatically create temporary folder. Instead expecting users to have that folder created upfront and set permission (write) on that folder.
• Prevented the product upgrade proceeding when insufficient disk space is detected. Faiure reason will be caught in the product log when encountered.

• Optimized PUT - Modify 'skip by hash' listAPI to process a large volume of hashes data - up to hundreds of thousands of entries, which is not possible before the optimization.

• Added more information into the product log in the event of scan submission was blocked due to out of workflow time window (included filepath, filename, callbackurl, sanitizeurl, downloadfrom)
• Added data ID of root archive level to the log in the event of any child files of that root archive, regardless of any extraction level, is done with processing.
• Optimized to trim down unnecessary data captured in the product audit log when users modified a configuration comes with large content e.g. large list of hashes to be skipped.
• On Linux OS, supported log rotation for NGINX web server by MetaDefender Core built-in mechanism without relying on logrotate service on Linux OS.
• Added deployment ID into the product log in some relevant licensing events.
• Provided data retention setting for PostgreSQL bundled logs, by default: 1 month, and can be adjusted up to 12 months.

• Display processing time details

• Child (nested) checkboxes are no longer automatically checked/unchecked when their parent checkboxes are.

• Failed to process signed file via local file path mode (using filepath header).
• Failed to start MetaDefender Core service when using log overriden with multiple entries separated by semicolon.
• Mismatch values of Percentage column between the executive report PDF and actual product UI.
• Engines failed to re-download back when removing them while downloading definition packages.
• Failed to export Sandbox result JSON report on the UI with 403 error.
• Failed to update Deep CDR settings on Central Management 7.
• Scan could be hung while being processed with batch in Central Hub architecture.
• MetaDefender Core service could be crashed when using distributed load extraction with file size filtration setting in Central Hub architecture.

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)