Windows has one widely relied-upon control for files arriving from the internet: the Mark-of-the-Web. It is the reason SmartScreen evaluates a downloaded executable, the reason Office opens a document in Protected View, and the reason a user sees a warning before running something from an email attachment.

CVE-2026-96951 is a Windows Shell security feature bypass, rated 8.8, that Microsoft confirmed as exploited in the wild with its October 2026 Patch Tuesday release. It undermines that control.

What was disclosed

The October 2026 update addressed a record volume of vulnerabilities, and among the three zero-days two were security feature bypasses. CVE-2026-96951 affects Windows Shell and lets a crafted file evade the Mark-of-the-Web, which in practice means SmartScreen, Office Protected View and the run-prompt warning may not fire.

The second bypass, CVE-2026-108398 in .NET Framework, was publicly disclosed before patching and is reported to allow bypassing Windows Defender Application Control to run unauthorized applications. A third publicly disclosed flaw, CVE-2026-92707, is a denial-of-service issue in MessagePack-CSharp.

Microsoft described exploitation of CVE-2026-96951 as detected. CISA added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of 16 October 2026.

Why a marking flaw outranks many code execution bugs

Defenders often rank vulnerabilities by the damage an exploit causes after it runs. A Mark-of-the-Web bypass changes the damage calculation before execution, because it removes the decision points where a cautious user or an automated control would have stopped.

The realistic delivery path is a user opening an attachment or a file received over chat. That is an extremely low social-engineering bar, and it is the standard path for commodity malware distribution.

Once the mark is absent, a chain of assumptions collapses:

  • SmartScreen no longer treats the file as untrusted.

  • Office no longer routes it to Protected View.

  • The shell may not display the origin warning.

  • Application control policies keyed on the mark no longer apply.

Each of those is a defence layer an organization believes it has. A single bypass removes several at once, which is why the CVSS 8.8 rating understates operational impact for environments that lean on these controls.

Detection is the hard part

There is no clean signature for "mark was missing." The effects are downstream: execution of a binary from a download or attachment directory, Office documents opening outside Protected View, and processes starting from paths that normally carry the mark.

Useful hunting approaches, given the reported mechanism:

  • Correlate file creation in download, mail-attachment and chat-cache directories with subsequent process creation from the same path.

  • Alert on Office child processes spawning from documents in those directories without Protected View having been entered.

  • Track alternate data stream writes on files in user-writable download paths, and compare against expected behaviour for the applications involved.

  • Review endpoint telemetry for binaries whose first execution occurred within minutes of file creation from an external source.

None of this is novel hunting; the difference is that these events now matter more because the pre-execution warnings that used to filter them may not appear.

What to do about it

Patch. This is the only durable fix. The October 2026 cumulative updates for supported Windows client and server versions contain the correction.

Reduce reliance on a single control. If an application control policy depends on the Mark-of-the-Web, add a second criterion such as publisher signature or hash allowlisting. Policies built on the mark alone are exactly what this class of bypass targets.

Review attachment handling. Blocking executable attachment types at the mail gateway remains effective regardless of marking behaviour, because the file never reaches a user-writable path.

Recheck the Application Control posture. CVE-2026-108398 is described as allowing unauthorized applications to run despite Windows Defender Application Control. If your estate relies on WDAC, verify that its policy is enforced in a mode that cannot be bypassed by a marking or trust decision, and confirm the policy applies to the paths users actually download to.

Treat the 16 October deadline as a floor. Federal agencies had days. The rest of us should not interpret the absence of a deadline as slack, given confirmed exploitation.

The broader point

Security controls that depend on metadata the operating system attaches to files are only as strong as the code that writes and reads that metadata. When a bypass appears, it invalidates every policy built on the assumption, not just the single detection rule.

That argues for defence layers that do not share the same dependency: allowlisting by hash, application control with multiple criteria, network egress restrictions, and detection on execution context rather than file provenance.

References