Version | 5.24.0 |
|---|---|
Release date | 04 November 2026 |
Scope | Adds more Central Management control and engine end-of-support warnings. New options include percentile processing times, slot-limit email alerts and log file-name redaction. File Structure Validation can now decide which files go to Adaptive Sandbox, and Deep CDR can skip files that it already sanitized |
Making sure to check out the Known Limitations.
New Features, Improvements and Enhancements
Keep instance-specific settings under a Central Management group policy
A My OPSWAT Central Management (MOCM) group policy can now leave selected settings to each instance, while every other setting continues to sync from the policy. A new exclusions tab in the policy covers:
HTTPS certificate: each instance keeps its own host-specific certificate instead of receiving one certificate for the whole group.
Adaptive Sandbox: each instance keeps its own Sandbox connection, such as the server address and API key, so instances in the same group can use different Sandbox servers.
Turning an exclusion off applies the policy values again on the next sync, with no need to re-enroll the instance.
Splunk configuration from Central Management
Splunk integration can now be configured from My OPSWAT Central Management for instances it manages. In the setup wizard, the Splunk step now comes before Central Management enrollment and is skipped once the instance is enrolled, since Central Management then owns that setting.
Engine lifecycle notifications
Administrators are now told when an engine needs attention:
End of support: a console notification appears when an engine is near or past its end of support.
Newer MetaDefender Core required: an engine package that requires a newer version of MetaDefender Core is no longer installed, whether it arrives by download, manual upload, or pickup folder, and the current package stays in service. The rejection is shown in the update status on the Engines page, including when updates are applied manually, with a recommendation to upgrade instead of retrying. An installed engine that needs a newer version shows a warning on its tile.
Percentile processing-time metrics in the Executive Report
The Executive Report and related dashboard views add P50, P90, P95, and P99 processing-time metrics. A few slow objects no longer hide typical processing speed behind average and maximum alone
Optional skip for already-sanitized Deep CDR output
Administrators can enable an option so Deep CDR does not sanitize a file again when Core already produced a sanitized result. The option is off by default. It helps MetaDefender Kiosk and USB repeat-scan flows avoid growing piles of sanitized copies. Details: Skip Sanitizing Already-sanitized Files
Email notification when processing slots exceed a threshold
Administrators can configure alerts when the scan queue or processing-slot usage crosses a defined threshold. Alerts can go by email and surface in the dashboard
Further Enhancements
1) Reliable reporting to Central Management over slow connections
For deployments managed by My OPSWAT Central Management across slow or long-distance connections, reports are now sent reliably during continuous, high-volume scanning. The local report buffer uses far less disk space and memory, and reporting no longer stalls for long periods under load.
2) Centrally managed certificates in Central Management policies
The certificate fields of a My OPSWAT Central Management policy, for Secure Connection and for batch signing, now list the certificates assigned to that policy. Each instance in the policy uses its own copy of the selected certificate, even when the instance stores it under an adjusted name.
3) Skip by Hash expiration from Central Management
The Skip by Hash list now shows the expiration date that My OPSWAT Central Management sets on a centrally managed entry, so administrators can see when a temporary approval or block ends. After the upgrade, existing centrally managed entries are refreshed once so they show their expiration.
4) File Structure Validation works with Adaptive Sandbox
File Structure Validation findings, such as macros and hyperlinks, can now decide whether a file is sent to Adaptive Sandbox, the same way Deep CDR findings already can. Organizations that rely on File Structure Validation instead of Deep CDR for this decision keep the same Sandbox filtering behavior. Files that File Structure Validation extracts are also scanned as soon as the engine returns them, for engine versions that return results during processing.
5) Add a certificate and its private key from a single file
Adding a certificate by file upload now accepts a single file that contains both the certificate and its private key, so a combined certificate file can be used as it is delivered.
6) Clearer Deep CDR summary on the processing result
The Deep CDR card on the processing result now leads with the total number of objects processed, instead of the sanitized count alone, which often read as zero because Deep CDR mostly removes objects.
7) Vulnerable packages listed first in the SBOM filter
When the SBOM filter is selected in an archive's extracted file list, files with vulnerable packages are now listed first, so they no longer have to be found among thousands of clean entries.
8) Full engine name in the File Processing Time chart
The File Processing Time chart on the dashboard now labels File Structure Validation by its full engine name in the legend and tooltips, consistent with the other engines in the chart.
9) Clearer Troubleshooting page layout
Expanded Troubleshooting content is easier to read and navigate in the Management Console.
10) File name redaction in logs (data ID instead of file name)
A setting can replace scanned file names in logs with the scan data ID. This reduces exposure of sensitive names in SIEM and log exports while keeping correlation to the scan record
11) Usage Report settings included in configuration export
Usage Report settings are included when you export Core configuration, so container and automated deployments can preserve those choices across environments.
Security Enhancements
Several issues found in an internal security review have been addressed, tightening access control on administrative and configuration operations and strengthening input validation.
Replace 7-ZIP - MetaDefender Core is no longer using 7-ZIP since v5.24.0
Upgraded 3rd-party libraries:
Protobuf: upgrade to v33.5
gRPC: upgrade to v1.84.0
Bug Fixes
Fixed an issue where a split archive submitted with a workflow rule other than the default was processed with the default rule's settings, although the result showed the selected rule.
Fixed an issue where a request refused through a My OPSWAT Central Management connection returned the same generic error for every request, instead of naming the refused request.
Core can start the bundled PostgreSQL in immutable, non-root containers with a read-only root file system when FIPS-related OpenSSL config must be written to a writable location
Upgrading to 5.23.0-era builds could add a MetaDefender Managed File Transfer rule bound to a disabled security zone, which blocked workflow and zone saves with “Rule refers to invalid zone”. That upgrade path is corrected
Importing Skip by Hash CSV lists larger than about 10,000 entries completes reliably. Comments with unpaired UTF-16 surrogates no longer reject the whole batch with HTTP 500
A crash path in
ometascanwhile scanning and viewing Processing History results was fixed.Post Action webhooks use the network manager from its owner thread, which removes related Qt warnings from syslog
Microsoft Visual C++ Redistributable version 14.44 or later is required for version 8.0 of the following modules: File Type, Archive Extraction, Archive Compression, Country of Origin, and Deep CDR.
OPSWAT will discontinue support for the following OS in MetaDefender Core and its associated engines:
Ubuntu 22.04 since Apr 2027.
Known Limitations
Bundled PostgreSQL v18 problem with non-ASCII locale name | PostgreSQL v18 itself cannot initialize its database cluster when the Windows system locale name contains non-ASCII characters. For example, Turkish Windows uses the locale Instruction for safe upgrade at Upgrade to MetaDefender Core 5.21.0 or later on Windows systems with a non-ASCII locale. |
Bundled PostgreSQL v18 problem with non-ASCII password | If your bundle PostgreSQL password contains non-ASCII characters (for example MetaDefender Core v5.22.0 and above will resolve this issue |
Displaying issue of Processing History | In MetaDefender Core v5.21.0, PostgreSQL has problem with some special characters in results returned by engines. As a consequence, Processing History on web console becomes empty in those cases. This is a displaying issue; your data in database is retained as is, and REST API integrations work properly. Upgrading to MetaDefender Core v5.22.0 will resolve this issue. |
Some Settings Not Editable When Managed by Central Management (CM7) in version v5.21.0 | When MetaDefender Core v5.21.0 is managed by Central Management v7, the following configurations are read-only and cannot be modified:
To modify these settings, temporarily disconnect the MetaDefender Core instance from CM7, apply the required configuration locally, then reconnect the instance. |
Kubernetes v1.35 or containerd v2.2.0 could not deploy MetaDefender Core images | This issue is a bug of Until the vendor provides a fix, use one of the following mitigations:
More details at Unable to deploy MetaDefender Core in Kubernetes with containerd engine 2.2.x |
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. |
Workflow configuration fails to synchronize from OPSWAT Central Management to MetaDefender Core after creating a new Workflow template | This issue affects MetaDefender Core versions 5.17.0 and 5.17.1. Workflow configuration from OPSWAT Central Management will fail to synchronize to MetaDefender Core (MD Core) once a new Workflow template is created. To restore normal synchronization, the newly created Workflow template must be deleted. As a workaround for creating new templates on these affected MD Core versions, the Clone Workflow Template feature can be used as an alternative. |
Temporary files may persist if an OPSWAT AI Content Inspector scan is canceled | If a scan is canceled while the OPSWAT AI Content Inspector engine is actively processing, intermediate files may remain in the temporary directory. These files do not affect the current or any subsequent scan results. Resolution: This issue has been fixed in MD Core 5.20.0. Workaround (if you remain on MD Core 5.19.0): The temporary files are automatically removed when the OPSWAT AI Content Inspector engine restarts. |