Zombie ZIP – The New Attack Technique That Bypasses Almost All of Security Tools
In early March 2026, the global security community was shaken by an alarming discovery: attackers can hide malware inside a deliberately malformed ZIP file — dubbed Zombie ZIP — effectively neutralizing nearly all antivirus (AV) engines and Endpoint Detection and Response (EDR) systems in use today. This technique requires no complex encryption, no sophisticated obfuscation — just a few bytes manipulated in the ZIP file header is enough to become "invisible" to 50 out of 51 security engines tested on VirusTotal.
Background: Who Discovered It and Why It Matters
The Zombie ZIP technique was discovered and disclosed by Chris Aziz, a security researcher at Bombadil Systems. After reporting to the CERT Coordination Center (CERT/CC), the vulnerability was assigned the official identifier CVE-2026-0866. Subsequently, expert Didier Stevens from the SANS Internet Storm Center (ISC) published an independent technical analysis confirming its severity and providing detection tooling.
What makes CVE-2026-0866 particularly noteworthy is not just its effectiveness — but its history. CERT/CC noted that this is a long-standing problem, reminiscent of CVE-2004-0935 — a similar vulnerability in older ESET software discovered over 20 years ago. This raises a serious question: has the approach of AV engines blindly trusting ZIP headers been an overlooked design flaw for two decades?
ZIP File Structure: The Technical Foundation
To understand Zombie ZIP, one must first understand the basic structure of the ZIP format:
A ZIP file consists of the following main components:
Local File Header (LFH): A per-file header immediately preceding each stored file; contains critical metadata such as filename, timestamp, compression method (
Compression Method), compressed data size (compressedSize), original data size (uncompressedSize), and the CRC-32 checksumFile Data: The actual content of each file (either raw or compressed)
Central Directory (CD): A master index located at the end of the ZIP file, listing all files in the archive; tools typically read the Central Directory before the LFH
End of Central Directory Record (EOCD): A marker signaling the end of the ZIP file, containing the location of the Central Directory
The Compression Method field is at the heart of the Zombie ZIP technique. The two most common values are:
0= STORED: Data is saved as-is, uncompressed8= DEFLATE: Data is compressed using the DEFLATE algorithm
ZIP-processing tools — including AV engines — typically trust this value to determine how to read and decode the subsequent data. This is precisely what Zombie ZIP exploits.
How It Works: Step by Step
Step 1: Prepare a Valid Malicious Payload
The attacker starts by creating a standard ZIP file containing a malicious payload (e.g., an executable, a PowerShell script, a malicious DLL). At this stage, the ZIP is fully valid and would be detected by AV engines during a normal scan.
Step 2: Header Manipulation — "Killing" the ZIP
This is the core step that defines the Zombie ZIP technique:
The attacker uses a hex editor or custom script to change the Compression Method field in both the Local File Header (LFH) and the Central Directory from 8 (DEFLATE) to 0 (STORED). However, the actual data is left untouched — the payload remains in its DEFLATE-compressed form.
Simultaneously, the CRC-32 value is updated to the checksum of the payload in its compressed (not decompressed) state. This creates an internal inconsistency: when standard ZIP tools (7-Zip, WinRAR, unzip, etc.) attempt to decompress the file, they read Method=STORED, treat the data as raw bytes, then fail the CRC check — reporting the file as "corrupt" or returning an "unsupported method" error.
The result: technically, this is an invalid ZIP file — yet the payload inside remains completely intact and recoverable.
Step 3: The AV Engine Is Fooled
When an AV engine or EDR scans this ZIP file, it reads the header and sees Method = 0 (STORED). Following standard logic, this means the data inside consists of raw, uncompressed bytes. The engine directly scans those bytes against its malware signature database.
But those bytes are actually DEFLATE-compressed data — appearing as "random noise," matching no known signatures. No match found → AV concludes the file is clean.
Step 4: Payload Execution via Custom Loader
The attacker deploys a pre-built custom loader — which may be a Python script, a Go binary, or a small executable — programmed to:
Read the "Zombie" ZIP file
Ignore the
Compression Methodfield in the headerDirectly apply the DEFLATE algorithm to decompress the data
Write the decompressed file to memory or disk and execute it
The loader bypasses the OS's standard ZIP library entirely — this is what allows it to "resurrect" the payload without triggering any security alert.
Attack Flow Summary
text
[Normal ZIP file — detected by AV]
↓ Change Method: 8 → 0, keep DEFLATE data intact, adjust CRC
[Zombie ZIP — appears as "corrupt file"]
↓ AV reads Method=0, scans raw bytes = DEFLATE noise → No signature match
[AV: "File is clean ✓"]
↓ Custom loader ignores header, directly DEFLATE-decompresses
[Malicious payload recovered and executed]
Real-World Test Results
Chris Aziz uploaded a Zombie ZIP containing the EICAR test file — an internationally standardized pseudo-malware file used to validate AV detection — to VirusTotal. The results:
50 out of 51 AV engines failed to detect the file
Only 1 engine flagged it as suspicious
Bypass rate: ~98%
This is a staggering figure, especially considering the technique uses no encryption, no packing, and no complex obfuscation whatsoever. A single trivial header modification is sufficient to become invisible to almost the entire commercial security ecosystem.
Independent Technical Analysis by SANS ISC
Didier Stevens from the SANS Internet Storm Center conducted an independent analysis and confirmed the technique works exactly as described. He published a set of custom command-line tools to detect Zombie ZIP files:
search-for-compression.py
This script scans ZIP file contents looking for genuinely compressed data blobs — based on high entropy characteristics and DEFLATE magic bytes — even when the header declares STORED. This is a heuristic approach: instead of trusting the header, it analyzes the actual data.
zipdump.py v0.0.35 with the -f l flag
This tool parses ZIP records directly without using Python's standard ZIP library. When run with the -f l flag, it displays detailed Local File Header information for each entry, enabling detection of the following anomaly:
compressedSize ≠ uncompressedSize (while Method = STORED)
Per the ZIP specification, if Method = STORED then compressedSize must equal uncompressedSize. Any discrepancy is a red flag indicating a potential Zombie ZIP.
The -s forcedecompress Option
Once an anomaly is detected, analysts can use this option to force decompression regardless of the declared compressiontype. The output reveals the true payload content. In Didier Stevens' testing, applying this to a Zombie ZIP containing EICAR successfully recovered the original EICAR file — independently confirming the technique.
Why Has This Problem Persisted for So Long?
The natural question is: how has such a simple technique evaded the entire security industry for years?
Several explanations exist:
Implicit trust in format standards: AV engine developers tend to trust header fields per the ZIP specification (PKZIP App Note), rather than performing cross-validation between the header and the actual data content
Performance trade-offs: Actually decompressing every ZIP file to scan its contents is far more resource-intensive than simply reading the header and scanning raw bytes. In enterprise environments processing millions of files daily, this is a significant trade-off
Corrupt files are often skipped: When an archive reports an error, many security systems choose to skip it rather than investigate further — inadvertently creating a blind spot
History repeating: CVE-2004-0935 warned of this exact issue back in 2004, but the lesson was never broadly applied
Real-World Attack Scenarios
The Zombie ZIP technique can be integrated into a wide range of attack vectors:
Phishing emails: Attaching a Zombie ZIP to a phishing email; email gateways and AV engines let it through because no malware is detected
Malware dropper: A custom loader is embedded inside a benign-looking executable; when run, it fetches and decompresses the Zombie ZIP to drop the real payload
Supply chain attacks: Embedding Zombie ZIPs inside fake software packages or malicious update bundles
Sandbox bypass: Automated analysis sandboxes may also be fooled if they rely on the same ZIP header-trusting logic
Web shell delivery: Uploading a Zombie ZIP through a file upload form, bypassing server-side file filters
Chris Aziz published a complete Proof-of-Concept (PoC) on GitHub with sample files, step-by-step explanations, and a sample loader. This means any attacker can replicate the technique without needing particularly advanced skills.
Defensive Recommendations
For Security Vendors
Never blindly trust headers: Always cross-validate
Compression Methodagainst actual data — if Method=STORED butcompressedSize ≠ uncompressedSize, treat this as a red flag requiring deeper inspectionDetect compression magic bytes: Inspect the first bytes of the data section — DEFLATE blobs have characteristic magic bytes (
0x78 0x9C,0x78 0xDA,0x78 0x01, etc.)Implement "force decompress" logic: Add logic to attempt DEFLATE decompression even when the header declares STORED
Elevate heuristics for malformed archives: Rather than skipping corrupt archives, treat them as suspicious signals warranting deeper analysis
For System Administrators
Enforce a "reject malformed archives" policy at email gateways and web proxies: block all ZIP files that do not conform to the standard rather than allowing them through
Use SANS ISC's
zipdump.pytool for periodic inspection of externally received ZIP filesMonitor vendor patch advisories and apply updates related to CVE-2026-0866 as soon as they become available
Consider deploying Content Disarm and Reconstruction (CDR) — a technology that rebuilds files after stripping all non-essential components, including malformed or suspicious structures
For End Users
Do not open ZIP files from unknown or untrusted sources, especially those received via email, messaging apps, or suspicious download links
If an attempt to extract a ZIP returns errors such as "unsupported method", "bad CRC", or "file is corrupt" — delete it immediately and do not execute any files associated with it
Report suspicious files to your IT or security team rather than attempting to handle them yourself
