Release notes
| Version | 5.15.0 |
|---|---|
| Release date | 03 July 2025 |
| Scope | This major version offers CIS level 2 support, processing efficiency improvements, continued My OPSWAT Central Management integrations, and several feature enhancements. |
Making sure to check out the Known Limitations
New Features, Improvements and Enhancements
Supports CIS Level 2 for Ubuntu 22.04
MetaDefender Core now supports CIS Level 2 system hardening benchmarks on Ubuntu 22.04. This enables organizations to meet more rigorous compliance requirements in regulated or high-assurance environments.
For more details, refer to CIS Level 2 Guidelines. Support for additional systems is planned for future releases.
Export & Import Engine Advanced Settings
A new feature has been added to support exporting and importing engine advanced settings. This enhancement allows administrators to:
- Export all engine settings, even for modules that are currently deactivated.
- Import these settings into a new installation, ensuring that module activation states and configurations are preserved.
- Restore previous settings for engines if they are re-enabled after import.
- Control the feature via the API header
engine_config: GET - Export configurationAPI.
This feature improves configuration management and migration scenarios, especially for customers who need to maintain consistent engine settings across deployments.
User Management via My OPSWAT Central Management API Endpoints
MetaDefender Core now supports local user management through the REST APIs of My OPSWAT Central Management when integrated with that platform. This allows administrators to automate user account provisioning and role assignments across distributed environments, enabling better alignment with centralized identity practices.
This support is available starting from MetaDefender Core version 5.15.0 and My OPSWAT Central Management version v10.1.2507.
For more information, please refer to the official My OPSWAT Central Management documentation.
Additional File Size Limit Enforcement
Administrators can now define a file size limit at the NGINX layer. This enables earlier enforcement of policy controls and supports more distributed or containerized environments.
This is configurable at the key body_size in ignition file. More details at Ignition file fields.
Post-Action Triggers Scoped to Root Archive Files
To improve processing efficiency, post-action triggers, such as copying or quarantining files, now apply to root archive files. This refinement avoids unnecessary processing of nested archive layers and aligns more closely with typical workflow logic.
You can find the new option Only trigger post action on root archive file under tag Post Action in Workflow Rule.
System Specification Warning at License Activation
The product now displays a warning if the system does not meet the minimum recommended hardware specifications.
This post-activation check helps administrators verify whether their environment is properly sized. While continuing with an under-spec setup is allowed, doing so may lead to performance issues or instability under certain workloads.
Setting Up A Secure Connection During Installation
Administrators can configure HTTPS during the initial deployment process using ignition file, rather than post-installation on web console or via API call. This simplifies secure setup and reduces deployment time.
A new set of settings are introduced at HTTPS section in Ignition file.
Executive Report with Blocked Reasons Summary
Administrators can obtain number of objects blocked by several reasons.
Improved Local Folder Update Functionality
Using the Local Folder Update folder with a UNC path previously consumed significant network bandwidth.
An optimization for new update check in this version considerably reduces network bandwidth and hardware resource usage.
Allow OPSWAT Module Update Packages
MetaDefender Core always performs integrity checks and verification to ensure the packages remain untampered. Therefore, Administrators can allow trusted OPSWAT update packages to pass through policy filters, ensuring essential updates are applied reliably without triggering unnecessary scan and consuming additional resources for deep processing.
New options have been introduced in the Allowlist workflow configuration to automatically allow the OPSWAT engine and database packages.
Usability Enhancements & Changes
1) Automatic Cleanup for File Corruption: The product now includes automatic cleanup functionality to address file corruption and residual files caused by external issues, such as connection loss, during the process of adding files to sanitizing storage. This enhancement ensures improved cleanliness of the storage environment.
2) Improved the look and feel of multiple text boxes within lists in Workflow Rule.
3) When Local Folder Update is selected and in use, the button Update all , which manually triggers update of engine and database packages, becomes unnecessary and is therefore grayed out.
4) A new sub-option, Exception by file types , has been added under the Output filename format section in the Deep CDR tab of Workflow Rules. This feature allows users to control and customize the naming convention of sanitized files, particularly enabling the retention of original file extensions when required.
REST API Enhancements
1) Attach MetaDefender Core server information in the response header X-Core-Id of the following API endpoints:
POST/file/batch- Initiate BatchAPIGET/hash- Fetch Analysis Result By HashAPI
2) Supporting customizable parameters with new header info in the REST API GET /readyzAPI allows users to query specific system metrics, such
as CPU load thresholds, relevant to their use case. Available values:
- all: return all the information
- database: obtain database status
- license: obtain license status
- avg_duration_time: obtain average duration (processing) time
- cpu_load: obtain CPU load as of calling the API
- scan_queue: obtain scan queue stats
- number_active_av_engines: obtain the number of active AV engines threshold
- engines: obtain engine status
3) Introduce a new API endpoint to fetch a list of blocked leaf files inside the archive by Hash: GET /hash/{hash value}/blocked-leavesAPI.
4) Introduce a dedicated API endpoint to validate PIN code: POST /admin/pincode/validateAPI.
5) Provide a new API endpoint to trigger Local Folder Update even during business hours or pause update window: POST /admin/update/folderAPI.
Logging Improvements
- Improved audit logs to include all activities on administrative configurations.
- To easily investigate network error while using SSO, we added more detailed log messages for authentication module.
Security Enhancements
Upgraded libraries for vulnerability fixes:
- PostgreSQL v14.18
- Angular v19
- yaml-cpp v0.8.0
Bug Fixes
- Fixed a crash issue that potentially happens during proxy setup. Network management is unavailable when the proxy configuration is applied, leading to a crash of MetaDefender Core. This scenario occurs with an extremely low likelihood.
- Fixed an issue where the setting
Processing results to be classified as Allowedwas not applied correctly, causing erroneous blocking of results.
Known Limitations
| Details | |
|---|---|
| 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 MetaDefender Core v5.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. |
| Performance degradation when processing large archive files | This issue has been resolved in MetaDefender Core version 5.5.0 and the Archive Extraction engine version 6.2.1.
|
| 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 MetaDefender Core v5.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) |
