Release notes

Version	5.15.2
Release date	28 August 2025
Scope	This minor version introduces OAuth for Microsoft 365 email authentication, enhanced nested archive error visibility, rejected scan request logging, certificate import support, non-TLS support and group configuration stability for My OPSWAT Central Management. It also includes security upgrades, and bug fixes for a more reliable experience.

Making sure to check out the Known Limitations

New Features, Improvements and Enhancements

OAuth for Email Server Authentication for Microsoft 365

In March 2026, Microsoft will be retiring Basic authentication with SMTP AUTH, and the change will complete after April. That means applications will no longer be able to use this authentication method to send emails.

This change prompts us to prioritize implementing OAuth support for Email Server as soon as possible. If you are using Basic Auth, we encourage you to review this document Microsoft 365 OAuth and change your MetaDefender Core's configurations to OAuth.

Enhanced Extraction Issue Visibility for Nested Archives

Earlier, users might have struggled to determine the cause of extraction errors in nested archive files. This update introduces a additional interface that highlights any extraction issues, making it easier for users to identify problematic nested files quickly.

Configuration Import & Export Supports Certificates

The ability to export certificates with database mode simplifies the process of backing up certificates. Administrators no longer need to manually configure Certificates settings.

The export/import feature will export/import certificate data by default. Its compatibility checks, automatic routing based on database mode and automatic deletion of existing certificates before import ensure integration of certificates without conflicts and prevent duplication. When an import fails, the product restores the previous state.

Rejected Scan Request Logging

Scan requests that are rejected such as those surpassing file size limits or occuring when local scanning mode is turned off, are not stored and displayed in the Processing History. A new optional setting now enables users to store these requests for later review and analysis.

Note: This feature only supports Standalone mode.

More details at Track Rejected Requests.

Non-TLS Communication for Local User Management Configuration in My OPSWAT Central Management

Added support for non-TLS communication with My OPSWAT Central Management (MOCM) for Local User Management configuration in specific on-premises deployments. This feature allows MOCM and MetaDefender Core to operate without TLS when both are deployed within the same isolated network.

Use Case: This enhancement is designed for scenarios where MOCM and MetaDefender Core are running in a secure, isolated network environment, and TLS is deemed unnecessary.
Recommendation: While non-TLS communication is now supported, TLS is strongly recommended to ensure secure communication. Non-TLS should only be used in environments where security risks are minimal and well-understood.

Improved Stability for Group Configuration in My OPSWAT Central Management

In collaboration with My OPSWAT Central Management, MetaDefender Core begins to use dedicated endpoints and storage for configuration data and status, minimizing scenarios where a Core instance in a group fails to apply the group configuration. This should make life easier for system administrators managing large or complex groups.

REST API Enhancements

1) A dedicated API endpoint to fetch and monitor system's resources including Disk space usage, CPU and RAM utilizations. Document at GET - Get server system resourceAPI.

2) The feature Scan-from-Link can now skip its metadata check and proceed directly to file downloading when clients set the new header skip-head-request of POST - Analyze File (Asynchronous mode)API to false.

Further Enhancements

1) Human-readable display for package URLs in engine processing results.

2) Filetype engine has been offering enhanced features and detection rates, which requires slightly more resources and processing time. Tracking the wait time at the Filetype engine will provide useful observability insights.

3) Setting private username for PostgreSQL can now have "-" (dash) character.

4) Slightly improved performance for scanning large archive files.

5) Retired the page Data Reporting from registration wizard screens since this feature was deprecated for years.

6) Enforced rate limiting on PIN entry attempts.

Security Enhancements

Upgraded libraries for vulnerability fixes:

PostgreSQL v14.19
NGINX v1.28.0
7zip v25.01

Bug Fixes

Addressed an issue that poped up No modification detected message while assigning new workflow template to existing workflow rules.
Addressed an issue that intermittently caused Not Scanned to file scannings with an error Can't convert to engine message. This issue was observed to occur only when two actions, posting a file and performing a local scan for a file with the same hash, are executed.
Addressed an edge case issue where the product failed to retrieve the workflow configuration for the Filetype engine, resulting in an error Missing preferences.filetype_mismatch.
Addressed an issue that prevented editing of the Country of Origin's advanced settings while the engine was disabled or inactive.
Addressed an issue where a negative value for others_time could occur after Compression sanitization execution.
Addressed a comestic issue where Metascan tile was temporarily grayed out while Country of Origin was processing files.

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 `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 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: Extract the config zip file. Open the "`export_settings.json`" and set "`required_engines`" to an empty array. Recompress the files into a new zip. 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.
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.
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. If you're using MetaDefender Core version 5.4.1, you can update the Archive Extraction engine to version 6.2.1 or newer without waiting for MetaDefender Core version 5.5.0 release. If you're using MetaDefender Core 5.4.0 or older, you can upgrade it to version 5.4.1 or newer, and update the Archive Extraction engine to version 6.2.1 or newer. If you are not able to upgrade MetaDefender Core, it is recommended to stick with the Archive Extraction engine version 6.0.2 until you are able to upgrade MetaDefender Core.
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: Switch to using a Docker base image RHEL 8 or Debian. 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)

Last updated on

Was this page helpful?