Title
Create new category
Edit page index title
Edit category
Edit link
Release notes
| Version | 5.17.1 |
|---|---|
| Release date | 26 January 2026 |
| Scope | This 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:
- 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.
- 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 verdict | Newly displayed verdict |
|---|---|
| Benign | Trusted |
| No Threat / No Threat Detected | No Threat Detected |
| Unknown | Undetermined |
| Suspicious / Suspicious Verdict by Adaptive Sandbox | Low Risk / Low Risk Verdict by Adaptive Sandbox |
| Likely Malicious / Likely Malicious Verdict by Adaptive Sandbox | High Risk / High Risk Verdict by Adaptive Sandbox |
| Malicious / Malicious Verdict by Adaptive Sandbox | Confirmed 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
downloadfromheader - 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 |
| 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
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:
|
| 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 crashes | Starting 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:
|
| 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 ' 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:
Workarounds for older versions:
|
| 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. |
