Mark of the Web: seven ways a file from outside stops looking like one

On Tuesday the 13th, in the October update bundle, Microsoft fixed CVE-2026-96951. The official entry is titled Windows Shell Security Feature Bypass Vulnerability, and its own FAQ answers which security feature gets bypassed: "An attacker who successfully exploited the vulnerability could evade Mark of the Web (MOTW) defenses". Scored 8.8, with a vector flagging a functional exploit and an official fix available. And one line worth reading in full: "Publicly Disclosed:No;Exploited:Yes;Latest Software Release:Exploitation Detected". Nobody knew about it and it was already in use.

The normal reaction to that is to patch, and patch you should. But this week's bug is the least interesting part of the story. What matters is what exactly was being bypassed, because it is the foundation of the protection your staff ever get to see when they open an attachment, and because Microsoft's own documentation lists, without hiding them, seven perfectly legitimate situations in which that foundation is absent.

What decides that Office will not run that macro

Mark of the Web is an NTFS alternate data stream called Zone.Identifier that Windows attaches to files arriving from places it does not trust. Inside sits a number, the ZoneId: 0 is the local machine, 1 the local intranet, 2 trusted sites, 3 the internet and 4 restricted sites. You read it from a console, with no tooling:

notepad informe-trimestral.xlsm:Zone.Identifier

[ZoneTransfer]
ZoneId=3

That 3 is why Excel shows the red security risk banner and refuses to run the macro. The decision flowchart Microsoft publishes has seven steps, and the first is the sentence holding up everything else: "A user opens an Office file containing macros obtained from the internet. (…) The file has Mark of the Web (MOTW)". If the file does not carry it, there is no step two. It is not that the user can click past the warning: the warning never arises.

Four routes by which the tag never gets applied

All four are on the same documentation page, in different sections, and none of them is a bug. They are the intended behaviour.

• Open in Desktop App. If someone is viewing the file on the OneDrive website or a SharePoint site — including the one behind a Teams channel — and clicks Open in Desktop App, "the file won't have Mark of the Web". That is the route you teach everyone to use because it is the convenient one.
• The OneDrive sync client. When it is the one downloading the file, the tag is not applied either: "If a user has the OneDrive sync client running and the sync client downloads a file, then the file won't have Mark of the Web".
• Known folders. Desktop, Documents, Pictures, Screenshots and Camera Roll, once synced to OneDrive, "don't have Mark of the Web". Which means the folder backup you switch on for hygiene also switches off the tag exactly where people keep their files.
• The file system. "Mark of the Web only applies to files saved on an NTFS file system, not files saved to FAT32 formatted devices". The USB stick from the trade fair, the exchange drive you share with the accountants, a camera card: if it is FAT32, there is nowhere to write the tag.

Three more where the tag is there and decides nothing

• Trusted Locations. Saving an internet file into one of them "ignores the check for Mark of the Web and opens with VBA macros enabled". Microsoft itself recommends managing them "carefully" and using them "sparingly"; what you find when you pull the list are locations nobody can justify, added years ago to clear one specific ticket.
• The source zone. The tag is added "only from the Internet or Restricted sites zones", and with ZoneId=2 macros are not blocked. Adding a file server to trusted sites to clear a ticket has a side effect the documentation states out loud: "you're also giving the entire site elevated permissions for scenarios not related to Office".
• The user. The Unblock checkbox in the file properties, or an Unblock-File in PowerShell, wipes the ZoneId. And there is a quiet inheritance: if somebody clicked "Enable content" on that document before the 2022 change, it became a Trusted Document and its macros "will continue to run" despite the new blocking.

None of the seven is an attack. They are product and administration decisions, taken for good reasons, which together describe something uncomfortable: the protection that actually stands between your staff and a hostile macro does not depend on a policy you wrote, but on which door the file came through.

And the eighth, which this week cost an emergency patch

Tuesday's CVE adds one route to that list which is not legitimate. Per Microsoft's entry it is a command injection in Windows Shell that an attacker uses by sending "a specially crafted file" over email or instant messaging, and the advisory stresses that somebody has to open it. It affects 31 products: thirty Windows editions, from Windows 10 1607 to Windows 11 26H2 and from Server 2012 R2 to Server 2025, plus Outlook.com, the only one on the list with no KB because it is not patched on your premises. The other thirty need nine different packages depending on the branch. If your inventory has four Windows versions living side by side, that is four validations, not one.

It is not the first this year in that same component. February brought CVE-2026-21510, and April brought CVE-2026-32202 because the February patch had stopped halfway: Akamai's research team documented that the fix closed the code execution path but left the earlier stage open — icon extraction — so the machine kept authenticating against the attacker's server. Three entries for the same component in CISA's exploited vulnerabilities catalogue in eight months, one of them the child of an incomplete fix.

The deadline no longer fits a maintenance window

All three entries carry a due date, and the progression reads itself. CISA gave the February one until 3 March: 21 days. The April one, until 12 May: 14. Tuesday's, until 16 October: three. We downloaded the whole catalogue (version 2026.10.13, 1,741 entries) and counted the windows on the 257 added this year: 132 are three-day, 78 fourteen-day, 44 twenty-one-day and three carry odd windows. Half this year's additions are now settled within 72 hours.

It is worth saying where the narrowing comes from, because it is not that the bugs get worse each time: CISA changed the framework halfway through. Directive BOD 26-04, published on 10 June, splits remediation into three, fourteen or thirty-day windows, or defers it to the next system upgrade, and the three-day one comes from four conditions met at once: publicly exposed asset, flaw listed in the catalogue, automatable exploitation and complete system control. The February and April deadlines were set before the directive existed. Afterwards: of the 124 entries added since 10 June, 101 carry three days and 23 carry fourteen, and the thirty-day tier has not appeared once. Before that date it was 31 out of 133.

And it is worth saying who that binds: US federal civilian agencies, with their exclusions. Nobody is forcing a small firm in Manresa. What that deadline measures is not a fine, it is how long the body publishing it reckons you have before the problem is inside. We wrote in August about the arithmetic of those deadlines against the working calendar — three days to patch and the third lands on a Saturday; what has changed since is not the arithmetic, it is that the short window is now the rule rather than the exception.

The policy that would make it mandatory is not in every plan

There is a way not to depend on default behaviour: enable the "Block macros from running in Office files from the Internet" policy, which Microsoft recommends as part of its security baseline for Microsoft 365 Apps for enterprise. With it in place, the documentation says, "your organization won't be affected by this default change". And much further down, in another section and another box, the small print that bounds it: "You can only use policies if you're using Microsoft 365 Apps for enterprise. Policies aren't available for Microsoft 365 Apps for business".

This does not mean a twenty-person company on Business Premium is unprotected: the default block applies to them too. It means they cannot pin it down, that they depend on that default staying the default and on nobody touching the Trust Center on their machine. The difference between a protection and a default setting is who can change it without you finding out. It is the same reasoning we apply to perpetual Office versions, where what expires is not the program but the testing — Office 2021 does not stop working, it stops being tested.

The table that answers this in your own place

The above is what the documentation says. What happens in your company is found out by sending the same file through every door with a notepad file:Zone.Identifier behind each one. It takes half an hour and produces a three-column table:

Two things do not fit in the table and answer just as fast. One: which Office plan you actually pay for, because that is what decides whether the policy exists at all. Two: how many days pass between publishing an update and 95% of machines having actually rebooted. If that second answer is "next Saturday", you already know the three-day window is not for you, and what you have in the meantime is detection on the endpoint.

What stays on the record

Office's yellow bar has spent twenty years training people to distrust what comes from outside, and it has worked reasonably well. The trouble with training somebody using a signal is that the day the signal does not appear, what you have taught is trust. An attachment arriving through the convenient route, with no tag, asks permission for nothing, and the user who did their job right for years has no way of telling the difference.

Sources (checked 14 Oct 2026): the official title of CVE-2026-96951, the 8.8 score, the vector, the "Publicly Disclosed:No;Exploited:Yes" line, both FAQ answers, the 31 affected products and the nine update packages come from the October 2026 CVRF file published by MSRC. The addition dates and due dates of the three Windows Shell entries, the count across the 257 added in 2026 and the 10 June cut-off are ours, run against the KEV catalogue at version 2026.10.13 (1,741 entries): anyone can download the JSON and redo them. The remediation windows and the four conditions behind the three-day tier come from directive BOD 26-04; the federal scope, from the 13 October alert. The seven-step flow, the Zone.Identifier command, the zone table, the four routes without the tag, Trusted Locations, Trusted Documents and the sentence about plans come from "Macros from the internet are blocked by default in Office". The analysis of February's incomplete patch is Akamai's. One counting caveat, in case you compare headlines: the October CVRF carries 1,760 identifiers, but 341 are Mariner, the Azure Linux, which most public counts leave out; hence the different figures from different houses. We have not reproduced the flaw and have no telemetry of our own on its exploitation: what is ours is the catalogue count, reading the seven routes together, and the table of entry doors.