Release Notes

Release date

21 Oct 2026

Scope

File-type scan control, processing stages, new File Security dashboard, ICAP/HTTP traffic capture, and FIPS 140-3 enforcement

This release enables users to scan only the file types they need, resolve request issues faster with built-in traffic capture, and see why files are allowed or blocked. Users can also upgrade instances remotely, keep instance-specific Server Profiles under group policies, and meet compliance requirements with FIPS 140-3.

• Scan Scope by File Type: Scan all file types, all except an excluded list, or only an included list.

• Processing History Stages: Each request is logged on arrival and shows its current processing stage until the verdict is returned.

• Built-in Traffic Capture: Capture ICAP and HTTP traffic from the Web UI. Download it as parsed transactions or raw .pcap files.

• File Security Dashboard: Shows request outcomes, allow/block reasons, and system performance metrics.

• Remote Upgrades and Server Profiles: Upgrade instances from My OPSWAT Central Management. Applying a group policy preserves each instance's Server Profiles.

• FIPS 140-3 and TLS Hardening: Enforce FIPS 140-3 from the Web UI. Harden each TLS listener with per-listener override files, as described in the new hardening guide.

Scan Scope by File Type

Choose which files are sent to MetaDefender Core, so scan capacity isn't spent on files that don't need scanning.

What changed: File type control used to work only as an allowlist. Selected types skipped scanning, and everything else was scanned. To scan just a few types, you had to select almost every other type. The allowlist is now called Scan Scope by File Type, and its Scan mode has three options:

• Scan all file types (default) — Every file goes straight to the scan server. File type detection is skipped, so this is the fastest option.

• Scan all except selected file types — Selected types are returned to the ICAP client as Allowed without scanning; everything else is scanned. This is the previous allowlist behavior.

• Scan only selected file types — Only selected types are scanned; everything else is returned as Allowed without scanning. This works well when a workflow only needs to inspect a few high-risk types. You must select at least one file type to save the workflow.

More details:

• Files whose type is unknown or cannot be detected follow the File type engine failure setting, so nothing slips through unscanned by accident.

• Custom scan targets apply the same scan mode, and files that match no target use the default scan target.

• Existing workflows are migrated automatically and keep their current behavior. No action is required.

How to access: Go to Workflows > select a Workflow > File Scanning > Scan Scope by File Type

Live Scan Status in Processing History

Long-running scans are no longer invisible.

What changed: Previously, a request used to appear in Processing History only after its scan finished. A file still being analyzed looked the same as one that never arrived, and you had to open the MetaDefender Core™ console to check. Now a record is created as soon as the ICAP request is received. It shows the current stage:

• Receiving — The file is being received from the ICAP client, such as a web proxy or MFT server.

• Submitting — The file is being sent to MetaDefender Core™ for scanning.

• Scanning — MetaDefender Core™ is analyzing the file while MetaDefender ICAP Server waits for the verdict.

• Retrieving — The scan is finished. MetaDefender ICAP Server is collecting the result, along with the sanitized or redacted file if Deep CDR™ or Proactive DLP™ produced one.

• Responding — The final file is being returned to the ICAP client. Large files can remain in this stage for some time.
  
  

Built-in Traffic Capture for Troubleshooting

Troubleshoot ICAP integrations without installing Wireshark, tcpdump or Npcap, and without shell access to the server.

How it works: If a proxy, MFT server, or other ICAP client can't connect, gets unexpected responses, or times out, start a capture from the Web UI. Reproduce the problem, then download the evidence. Each capture records the same traffic in two ways, so you can see both what was exchanged and how the connection behaved:

• Transactions — Every ICAP and HTTP request and response, recorded after TLS termination so ICAPS traffic is readable. Review them directly in the Web UI or download them as text files to see what was sent and why it was rejected.

• Packets — Raw network traffic saved as standard .pcap files that open in any packet analyzer, showing connection setup, resets, retransmissions and timing. No capture tool needs to be installed: MetaDefender ICAP Server includes one on Linux and uses the built-in Packet Monitor (pktmon) on Windows. If the host does not permit packet capture, transactions are still recorded and the capture shows why packets are missing.

Capture only what matters: Filter by traffic source (ICAP, HTTP or both), network interface and client IP. Give each capture a meaningful name, such as “Proxy timeout – client 10.0.0.12.” The name is also used as a prefix for the downloaded files, so they are easy to find later.

Safe for production

• Traffic is processed normally while a capture runs.

• Each capture stops automatically at its time, size or packet limit, and only one capture can run at a time.

• Finished captures are deleted automatically after a short retention period (15 minutes by default).

• When the maximum number of stored captures is reached, starting a new one replaces the oldest, and you can download it first.

Note: Captures can contain file contents and other sensitive data, so handle downloaded files accordingly. For security reasons, this feature is disabled by default. To enable it, set the corresponding flag in the diagnostic section of the configuration file (see Linux or Windows) and restart MetaDefender ICAP Server.

How to access: Go to Diagnostics > Traffic Capture

New File Security Dashboard

The Dashboard now answers three questions: how much traffic was processed, what happened to it, and why.

Security Tab

• A Requests Summary shows the overall outcome of requests in the selected period, with breakdowns explaining why requests were allowed (by scan result, by configuration without scanning, or by override settings) and why they were blocked.

• Requests closed by the client before completion are shown separately as Aborted by client, so totals always add up. Trend charts show how request processing and file security outcomes change over time, alongside summary cards by outcome and by file type.

System Tab

• Monitor system performance alongside security activity.
  
  

Automatic Upgrades through My OPSWAT Central Management

Instances managed by My OPSWAT Central Management can now download and install new versions on command, and report their new version back once the upgrade completes. No setting is required on MetaDefender ICAP Server: once the instance is enrolled in My OPSWAT Central Management, upgrades are scheduled and managed from the Central Management console.

Upgrades are designed to run safely unattended:

• Verified Packages — The installer’s size and checksum are verified before it is staged.

• Health-Gated Start — After upgrading, the instance must start successfully and pass a health and license check.

Supported on Windows and Linux (Red Hat-based and Debian-based distributions).

Note: Automatic upgrades are available for instances running v5.16.0 or newer. Instances on v5.15.0 or earlier must be upgraded to v5.16.0 manually once; every later release can then be installed from My OPSWAT Central Management.

Granular Group Policies in My OPSWAT Central Management

Previously, applying a configuration group (policy) replaced the entire configuration of every instance in the group, including its Server Profiles — so administrators had to restore each instance's MetaDefender Core™ connections by hand after every policy update.

Server Profiles are now treated as instance-specific: when a policy is applied, all shared settings follow the policy while each instance keeps its own Server Profiles.

FIPS 140-3 Mode

Run MetaDefender ICAP Server in environments that require FIPS 140-3 validated cryptography.

MetaDefender ICAP Server now ships with the OPSWAT FIPS Provider, a cryptographic module validated under the NIST Cryptographic Module Validation Program.

• One-Switch Enforcement — A new FIPS 140-3 mode card shows the current status and lets administrators enforce FIPS mode with a single switch. The web server restarts automatically to apply the change.

• Built-in Readiness Check — FIPS mode cannot be enforced while any TLS connection (HTTPS, ICAPS or NGINX Support) still allows a legacy protocol — TLS 1.1, TLS 1.0 or SSL 3.0. A TLS Connections table lists each affected connection with a direct link to fix it, and a header notification flags legacy protocols in use.

• Protected Configuration — While FIPS mode is enforced, legacy protocols are marked and cannot be selected or saved in any TLS settings.

How to access: Go to Settings > Security > FIPS 140-3 Mode

Usability Improvements

• Clearer Central Management Sync Messages — If the instance cannot reach Central Management while you save a configuration change, the save is now reported as successful, with a separate notice that the change could not yet be synced. Previously, the entire save was shown as Failed even though the change had been applied.

• Log Rotation for the Central Management Transporter on Linux — oms_ocmdatatransporter.log is now rotated daily, compressed and limited to 30 files on Linux, as it already was on Windows. Previously, this log could grow without limit and fill the disk.

Security Enhancements

Upgraded third-party libraries to address known vulnerabilities:

• OpenSSL v3.6.5

• NGINX v1.30.5

• curl v8.22.0

• PostgreSQL v16.15

• libxml2 v2.15.3

• c-ares v1.34.8

Applied additional security hardening measures across the product.

Health Check Reporting Not Ready with Dynamic Load Balancing

Fixed an issue where /readyz returned 503 while some server profiles were still available, when the health check was set to fail only if all server profiles were unavailable and an unavailable profile used dynamic load balancing. Load balancers could take a healthy instance out of rotation as a result.

Special Characters Accepted in Request Filtering

The Request Filtering lists (Host IP/Domain, Request URL, Client IP, ICAP Client IP) and header fields now reject < and > with an inline error, consistent with the previous UI.

Minor Fixes

Resolved various cosmetic UI issues and other minor issues.

Log Rotation Not Functioning on Windows

Log rotation failed to function correctly on Windows systems.
Impact: Introduced in v5.13.0
Resolution: Fixed in v5.14.0 and newer.

Proxy Configuration

Currently, HTTPS proxy configuration is not supported.

SAML Directory (SSO Integration) Limitations

In v5.5.0, users cannot create a new SAML directory via the web UI.

• Workaround: Use REST API to create the SAML directory

• Impact: Existing SAML directories remain unaffected after upgrading to v5.5.0

• Resolution: Fixed in v5.5.1 and newer

Stability Issues on Red Hat/CentOS (Kernel Version 372)

MetaDefender ICAP Server v5.1.0 or newer may encounter stability issues on Red Hat/CentOS systems running kernel version 372.

Solution: Upgrade to kernel version 425, where Red Hat has resolved this issue.

MetaDefender ICAP Server's NGINX Web Server Fails to Start with Weak Cipher Suites for HTTPS

Starting in v5.1.0, OpenSSL 3.x replaced OpenSSL 1.x across the product and its dependencies, to improve security and address vulnerabilities.

As part of this upgrade, the NGINX web server in MetaDefender ICAP Server now enforces stricter cipher policies and rejects all weak cipher suites. The web server now only accepts "HIGH" encryption cipher suites https://www.openssl.org/docs/man1.1.1/man1/ciphers.html (cipher suites based on MD5 or SHA-1 hashing are also rejected).

As a result, if you have already configured MetaDefender ICAP Server for HTTPS using a weak SSL cipher with your certificate, the server will not start due to the enforced security policies in NGINX's OpenSSL 3.x.

no_proxy Configuration

Starting with MetaDefender ICAP Server v5.1.0, the no_proxy setting must support CIDR for IP addresses. For more details, see No Proxy configuration.

TLS Connectivity to MetaDefender Core on Debian

On Debian OS, MetaDefender ICAP Server v5.1.0 requires the two following commands to enable TLS communication with MetaDefender Core:

sudo mkdir -p /etc/pki/tls/certs/

sudo ln -s /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt

Resolution: Upgrade to MetaDefender ICAP Server v5.1.1, where the issue is resolved.

TLS 1.3 Not Supported on Windows Server 2012

TLS 1.3 is not supported on Windows Server 2012 due to limitations with Schannel SSP. Reference