A rigged 7-Zip archive can erase the Windows warning on downloaded files, and there is no fix yet

The current release of 7-Zip on Windows, version 26.02, will quietly hand attackers something they want badly: a way to make a file they sent you look like a file you created yourself. A crafted archive can strip the Mark-of-the-Web, the hidden tag Windows attaches to anything that came from the internet, so the warnings that normally fire on a risky download never appear. The flaw is tracked as CVE-2026-58052, it affects every 7-Zip build up to and including the latest, and as of this writing there is no patched version to install.

Scored on its own, the bug looks minor. CVSS 3.1 rates it 3.3 (low) and CVSS 4.0 rates it 4.8 (medium). That number measures the wrong thing. The Mark-of-the-Web is not a vulnerability class on its own; it is the tripwire that makes phishing payloads announce themselves. Take it away and a malicious script in an emailed archive runs with no SmartScreen prompt, no Office Protected View, none of the friction Windows builds around untrusted files. The score says low. The role it plays in a real intrusion says otherwise.

What the flaw actually does

Windows stores the internet origin marker in an alternate data stream named Zone.Identifier attached to the file. 7-Zip already knows an archive should not be allowed to supply its own copy of that stream, so it has a guard that blocks any incoming stream called exactly Zone.Identifier. The new bug is that the guard reads the name too literally. A RAR5 archive can carry a stream record named :Zone.Identifier:$DATA, which the guard does not recognize but which the NTFS file system treats as the same stream once it is written to disk. The attacker's version lands with a zone value of 0, the code Windows uses for trusted local files, on top of the internet marker that extraction was supposed to set.

A second trick rides along. A second record, this one named ::$DATA, lets the sender replace the file's real bytes outright. So the attacker controls both what the file is and what Windows believes about where it came from. The result is a file that opens with no warning and contains whatever the sender chose. Defenders track this behavior as a Mark-of-the-Web bypass (MITRE ATT&CK technique T1553.005), the same family Windows malware has used for years to slip past SmartScreen.

We have seen this movie before

This is the second distinct Mark-of-the-Web bypass to hit 7-Zip in eighteen months, and the first one did real damage. CVE-2025-0411 used a different mechanism, a nested archive whose inner contents never inherited the marker, and was exploited from September 2024 by Russian operators dropping the SmokeLoader malware on Ukrainian government and private organizations through phishing email. 7-Zip fixed that one in version 24.09. The new bug reaches the same destination by a different route, and that is the part worth sitting with: the marker-propagation logic in this tool has now failed twice, in two unrelated ways, and the payoff for breaking it is high enough that attackers keep coming back.

A public proof-of-concept already exists, published alongside the disclosure by the researcher credited as ashdfrkl. No in-the-wild use of this specific bug has been reported yet. Given the history, treat that as a head start, not a reprieve. The same logic that betrayed users when state-backed crews phished Signal recovery keys applies here: the human-facing safety prompt is the control, and attackers invest in turning it off.

There is no patch. Here is what to do now

Until 7-Zip ships a fix, the safe assumption is that any file a user extracts with 7-Zip on Windows may have lost its internet marker even though it came from outside. Build your response around that assumption rather than around a version number you cannot yet bump.

• Stop trusting the marker on extracted files. Do not let application-control or conditional-access rules treat "no Mark-of-the-Web" as "safe local file" for anything that came out of an archive. Where you can, prefer Windows Explorer's built-in extraction, which propagates the marker, for archives from untrusted senders.
• Hunt for the tell. Look for archives carrying alternate data stream records named :Zone.Identifier:$DATA or ::$DATA, and for freshly extracted files in download and temp folders that show a zone value of 0 when their source was clearly external.
• Watch the next step, not just the file. The bypass only matters if something then runs. Alert on processes spawned from recently extracted files in user-writable paths, the scripts, installers, and shortcuts launched out of Downloads or Temp, which is where a missing warning turns into an actual intrusion.
• Tell users the warning may not come. The whole point of this bug is that the prompt people are trained to respect will stay silent. Refresh the guidance to not open archives from unexpected senders, because the technical guardrail behind it is down.

This is the kind of gap that endpoint and log telemetry closes when the file-level signal can no longer be trusted. A managed detection team watching process execution and child-process lineage will catch the payload running even when SmartScreen never fired, because the suspicious behavior happens after extraction, where the missing marker no longer hides anything. The same pattern showed up when opening the wrong file quietly ran code as the user: the file looked benign, so the only durable signal was what it did next.