Release notes

Version5.17.1
Release date26 January 2026
ScopeThis version introduces new technologies, Threat Intelligence engine, and MetaDefender Aether, new threshold to defend archive bomb, Proactive DLP regex management, more syslog format compliances, multi-SSO-URL support and several enhancements.

Making sure to check out the Known Limitations

New Features, Improvements and Enhancements

Next-Gen Threat Intelligence Engine and MetaDefender Aether

MetaDefender Core introduces a branch new technology called MetaDefender Aether, a next-generation technology that brings Adaptive Sandbox and Threat Intelligence together into one powerful, unified pipeline. With Aether, security teams can detect, analyze, and respond to advanced threats with unprecedented speed and precision. This upgrade streamlines your threat detection workflow, reduces complexity, and delivers deeper insights, empowering you to stay ahead of even the most sophisticated cyber threats.

For more details about the all-new Threat Intelligence engine, please refer to this documentation: Threat Intelligence.

For details on the Threat Intelligence response JSON format, as exposed in the new threatintelligence_info field, see: GET - Fetch Analysis ResultAPI

Workflow Option for Running Deep CDR Only on Certain Metascan Verdict

Added the ability to configure Deep CDR in the workflow to trigger only for files that are reported as infected by any of the scanning engines in Metascan. Clean files will not be sent for Deep CDR, and the workflow will stop after the initial Metascan stage with the corresponding scan status.

Default behavior/value: Disabled.

When enabled, only infected files will be processed by Deep CDR, while clean files bypass the sanitization stage.

Enhanced Regex Management for Proactive DLP

MetaDefender Core made it easier for admins to manage and select regex patterns for Data Loss Prevention (DLP) workflows. With this update, you can now upload multiple TSV files containing regex definitions, view their contents in a slick pop-up modal, and pick exactly which regexes you want to enable from the Workflow console.

Please note the following as of now:

  1. The “Pick regexes” pop-up model is not yet supported in My OPSWAT Central Management. Instead, you can provide the path to the TSV file in the MetaDefender Core workflow configuration on the My OPSWAT Central Management console. By default, all regexes in the TSV file are selected, and you can edit the TSV to remove existing regexes or add new ones.
  2. The DLP engine currently supports only the pop-up model for Detection configuration, but this may be expanded with additional options in the future.

Here is a sample TSV format:

New Threshold to Strengthen Protection Against Archive Bomb

MetaDefender Core introduced a new archive configuration that lets you control the maximum allowed compression expansion factor for extracted archives. This helps prevent “zip bomb” attacks, where a tiny archive expands into a massive file and can overwhelm your system.

By default, the system uses a high threshold (1000:1), so existing customers won’t be affected unless they choose to tighten the setting. If an archive exceeds the configured value, it’s now blocked with a new verdict: Exceeded Archive Expansion Factor.

Support to Configure RFC 5424 and RFC 3164 for Syslog

The application now allows selecting the syslog message format used for CEF output to integrate with different SIEM systems without breaking existing deployments. Supported formats include: Default, CEF, RFC 3164, and RFC 5424.

Support Multiple Login URLs for SSO Directories

MetaDefender Core now supports multiple login/redirect URLs as part of the SSO authentication flow. This enhancement allows deployments spanning multiple domains or client applications to dynamically route users to the correct redirect endpoint during login.

IPv6 Support for MD Core - My OPSWAT Central Management Integration

MetaDefender Core can now communicate seamlessly with My OPSWAT Central Management in IPv6 environments. This ensures that organizations transitioning to IPv6 can confidently deploy and operate My OPSWAT Central Management in modern network domains.

Further Enhancements

1) Data Retention Term Change for "Off" Option

Changed the Data Retention "Off" option label to a clearer term to avoid confusion. The previous "Off" label under the "Data retention" section was misleading; it now displays as "Retain: Forever" to better indicate the actual behavior.

2) Add Synchronous File Scan Timeout to Config Export and Import

The synchronous file scan timeout setting (/admin/config/file/sync) is now included in the configuration export and import package.

By default, the file_sync_timeout_setting is included in the exported package.

3) UI Streamlining: Option Relocated for Better Usability

To make configuration more intuitive, the “Include sanitized version of blocked child files” option has been moved from the Deep CDR tab to the Compression tab. This update helps users find and manage this setting where it makes the most sense, without changing any underlying functionality.

4) Rename OPSWAT Alin Engine

OPSWAT Alin engine is now renamed to OPSWAT Predictive Alin AI.

5) Enhance Archive Extraction Issues Filtering Performance

In MetaDefender Core v5.17.0, you can filter Extraction Issues in the Processing History. However, the performance of this filtering needed improvement, and it has been optimized in MetaDefender Core v5.17.1.

6) Improved Error Categorization for Archive Extraction Issues

MetaDefender Core made it easier to understand and troubleshoot archive extraction errors.

Previously, when an archive exceeded certain extraction limits (like file count, size, or depth), the error was shown as “Unknown.” Now, these are clearly categorized as either Extraction Limit Exceeded or Extraction Timeout Exceeded.

7) Update Adaptive Sandbox Displayed Verdicts on Web Console

Starting from MetaDefender Core version 5.17.1, verdicts from the Adaptive Sandbox will be changed in the product web console and other related reports. Note that only the UI and reports are updated; the JSON response remains unchanged to ensure compatibility with existing integrations. The detailed changes are as follows:

Previously displayed verdictNewly displayed verdict
BenignTrusted
No Threat / No Threat DetectedNo Threat Detected
UnknownUndetermined
Suspicious / Suspicious Verdict by Adaptive SandboxLow Risk / Low Risk Verdict by Adaptive Sandbox
Likely Malicious / Likely Malicious Verdict by Adaptive SandboxHigh Risk / High Risk Verdict by Adaptive Sandbox
Malicious / Malicious Verdict by Adaptive SandboxConfirmed Threat / Confirmed Threat Verdict by Adaptive Sandbox

Security Enhancements

Upgraded libraries for vulnerability fixes:

  • NGINX v1.29.4
  • c-ares v1.27.0

Bug Fixes

  • Addressed the crash issue that could occur when clients push files during MetaDefender Core service startup.
  • Addressed an issue where API requests failed due to RAMDISK Temp Directory setup and using the downloadfrom header - causing incorrect disk space comparison.
  • Other cosmetic fixes.

Known Limitations

Slow or Inaccessible Management Console

This issue has been resolved in version 5.13.2

In version 5.12.0, an issue was identified that caused some APIs to load more slowly than expected. As a result, the Web Management Console might experience slower performance or become unresponsive

Please read more details on this page: Slow or Inaccessible Management Console.

The 'Proxy server requires password' setting cannot be disabled once it has been enabled

This issue has been resolved in version 5.14.2.

In version 5.14.1, there was an issue that prevented disabling the Proxy server requires password setting once it has been enabled. As a workaround, you can export the current settings, locate and remove the username and password fields under the relevant proxy configuration, and then import the modified configuration.

Database connection failure occurred in a specific circumstance after upgrading to version 5.11.0

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.
Archive compression may fail with very large archive files that contain a large number of subfiles

This issue has been addressed in version 5.14.0.

MetaDefender Core has a limitation when compressing very large archive files that contain a high number of subfiles. In our test scenario, it failed when processing an archive with 300,000 or more subfiles.

Reuse processing result by hash might be slow in high-load situations

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.

Temporary files in the resource folder may not be properly cleaned up if the Archive Extraction engine crashesStarting from MetaDefender Core version 5.10.1, if the Archive Extraction engine crashes, temporary files from specific extraction transactions may not be properly cleaned up. However, this issue is relatively rare.
Reject importing non-empty required_engines setting in containerized environments

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 on docker
The Engine Update feature may not work as expected in certain environments

We have observed that the Engine Update feature may not work properly in an environment protected by a 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.

Stability issues on Red Hat / CentOS systems with kernel version 372.13

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.

PostgreSQL and MetaDefender Core services cannot initialize in certain containerized environments

This issue was addressed in version 5.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.
MetaDefender Core's NGINX web server will not start if weak cipher suites are used for HTTPS

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

TCP socket port exhaustion may cause the service trouble, preventing from restarting, and Workflow configuration corrupted

This issue affected MetaDefender Core (MD Core) version 5.15.0 and earlier and is enhanced starting from version 5.15.1.

TCP socket port exhaustion might be triggered by other applications; for example, MetaDefender KIOSK v4.7.6.3514 (fixed in later releases).

Consequently, MD Core may behave abnormally, corrupt its Workflow Configuration, and fail to restart.

Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard