Overview
Malformed ZIP headers can cause antivirus and endpoint detection and response software (EDR) to produce false negatives. Despite the presence of malformed headers, some extraction software is still able to decompress the ZIP archive, allowing potentially malicious payloads to run upon file decompression.
Description
ZIP archives contain metadata such as compression method, flags, and version information. Antivirus engines typically rely on this metadata to determine how to preprocess files before scanning. If an attacker modifies the compression method field, antivirus software may fail to properly decompress the file, and will therefore be unable to analyze the actual payload.
After antivirus evasion, the payload can be recovered by using a custom loader that ignores the declared Method field and instead decompresses embedded data directly. This allows the attacker to hide malicious content from antivirus engines while still being able to recover it programmatically.
Notably, standard extraction tools (e.g.: 7‑Zip, unzip, bsdtar, Python’s zipfile) trust the declared compression method and attempt decompression, but then fail with CRC or “unsupported method” errors. These tools do not extract the payload and do not expose the underlying data.
This vulnerability is similar to VU#968818, CVE-2004-0935.
Impact
A remote attacker may craft a ZIP archive with tampered metadata that prevents antivirus or EDR software from properly decompressing and inspecting its contents. The file can thereby evade full analysis, though many products will still flag it as corrupted.
To execute malicious code, however, a user must extract or further process the archive. Standard extraction tools may or may not reveal the hidden payload. It is possible that a custom loader that ignores the declared compression method could recover and execute the concealed content.
Solution
Antivirus and EDR vendors should not rely solely on declared archive metadata to determine content handling. Scanners should have more aggressive detection modes to validate compression method fields against actual content characteristics, and flag inconsistencies for further inspection.
Users are encouraged to contact their antivirus or EDR providers to identify whether they are vulnerable and obtain guidance on additional mitigation options.
Acknowledgements
Thanks to the reporter, Christopher Aziz. This document was written by Laurie Tyzenhaus.

Privacy and security concerns around AI are not hypothetical. They are real, present, and often misunderstood. This article breaks down the key risks, explains how AI companies handle your data, and gives you practical steps to protect yourself.

Overview
The Rakuten Viber messaging app for Android V25.7.2.0g and Windows V25.6.0.0-V25.8.1.0, has a flaw in its TLS handshake implementation when using the Cloak proxy configuration. This flaw allows for easy identification of proxy usage, potentially compromising user anonymity.
Description
Rakuten Viber can be configured to use a proxy server. Multiple proxy configurations, including Cloak, are supported. Rakuten Viber in Android V25.7.2.0g and Windows V25.6.0.0–V25.8.1.0 exhibits a flaw in the TLS handshake implementation for Cloak mode. Cloak mode is designed to hide the fact that a proxy or VPN is in use.
However, the Cloak proxy mode has a rigid and easily identified fingerprint, making it trivially identifiable by Deep Packet Inspection (DPI) systems. This allows networks to block Viber traffic, undermining the app’s ability to circumvent censorship and potentially leading to denial of service in certain cases.
Impact
The Cloak-mode proxy traffic fails to hide the use of a proxy. The outgoing data is easily identifiable due to the rigid fingerprint and no longer appears to be normal browser TLS behavior. The user has no indication the proxy is not protecting their data.
Solution
Windows users should upgrade to V27.3.0.0 or later, and Android users should upgrade to V27.2.0.0g or later.
For continued support, Windows users can implement automatic updates for Viber.
Acknowledgements
Thanks to the reporter Oleksii Gaienko, an independent security researcher. This document was written by Laurie Tyzenhaus.