Windows Explorer Preview Pane Disabled for Internet Files in October 2025 Update

Microsoft has turned off File Explorer’s Preview pane for files tagged as coming from the internet, a deliberate security hardening shipped in the October 2025 security rollup that trades a decades‑old convenience for protection against a subtle but real credential‑leak attack vector.

Background / Overview​

File Explorer’s Preview pane has been a small productivity superpower: select a PDF, Office document, image, or script and the right‑hand pane shows the file contents without launching a full application. That quick glance saves time for triage tasks — invoices, receipts, vendor documents and email attachments can be inspected in seconds.
Windows marks many downloaded files with the Mark‑of‑the‑Web (MoTW), a tiny provenance tag stored as a Zone.Identifier alternate data stream on NTFS. Attachment Manager, Office Protected View and other security subsystems consult that tag to decide when to warn or block a file. Starting with the cumulative security updates distributed around October 14–15, 2025, Microsoft changed Explorer’s policy so that files carrying the Internet zone tag are no longer handed to preview handlers; the Preview pane now shows a protective message instead of content. This behavior is intentional and documented in Microsoft’s update notes for the October 2025 rollups.
Community and field testing reproduced the change across many devices: downloaded PDFs and Office files that previously previewed now display the message “The file you are attempting to preview could harm your computer. If you trust the file and the source you received it from, open it to view its contents.” Removing the Zone.Identifier (for example via the file Properties → Unblock UI or PowerShell’s Unblock‑File) restores preview behavior for that file.

---

Why Microsoft did this: the NTLM leakage risk explained​

The change is a blunt mitigation for a specific attack class that has been demonstrated repeatedly by security researchers: preview handlers and the Shell can parse or resolve externally referenced resources inside documents (images, CSS, embedded HTML or UNC paths). If those embedded references point to a network resource the attacker controls (for example, an SMB/UNC share), Windows may attempt network authentication as part of resolving or fetching those resources.

• That network exchange can trigger NTLM (or related) authentication attempts.
• An attacker controlling the endpoint can capture negotiable authentication material (NTLM challenge/response or hash blobs).
• Captured authentication material can be used for later relay, cracking, or other credential‑abuse attacks, depending on the target environment’s protections (SMB signing, Kerberos usage, segmented networks).

Because File Explorer’s Preview pane invokes preview handlers inside the shell process, the attack required minimal user interaction: simply selecting the file in Explorer (or allowing Explorer to enumerate/thumbnail files) could be enough to trigger the network fetch and authentication attempt. Blocking the Preview pane for Internet‑zoned files removes a low‑interaction trigger for this class of credential leakage. Multiple community writeups and Microsoft’s own support note describe this rationale and the related October security fixes.

---

What changed, exactly — mechanics and scope​

Which files are affected​

• Files that carry the Internet zone marking (MoTW / Zone.Identifier ADS) will display the protective message in Explorer’s Preview pane and will not be rendered inline.
• Files created locally (not marked by MoTW) and files from Trusted or Intranet zones continue to preview normally.
• Files already present on disk that retained previews before the update may require an unblock operation to restore previewing.

How to recognize the symptom​

• Open Downloads (or any folder with files from the web) and enable Preview pane (Alt+P). If many PDFs or Office docs show the security message rather than content, the update has altered Explorer behavior.
• Using Streams or PowerShell to inspect alternate data streams will reveal a Zone.Identifier ADS if the file is Internet‑marked.

How to restore preview for one file​

• Right‑click → Properties → check “Unblock” → Apply/OK. This removes the Zone.Identifier for that file and, in most cases, restores previewing after a brief delay or an Explorer restart.

Bulk/unattended unblocking​

• PowerShell offers an efficient route for trusted folders. Example commands:
• To unblock a specific pattern: Unblock-File -Path "C:\Users\admin\Downloads*.pdf"
• To recurse and unblock many files: Get‑ChildItem -Path "C:\path\to\folder" -Recurse | Unblock‑File

These cmdlets are part of standard PowerShell utility cmdlets and have been used in scripts and community guidance to remove the Zone.Identifier ADS en masse. Exercise extreme caution before mass unblocking on multi‑user or enterprise systems: you are removing a security flag that was intentionally set by the OS.

---

Practical guidance: options, trade‑offs and recommended admin steps​

This is not a binary “security vs convenience” problem — there are multiple, auditable ways to restore preview functionality while managing risk. The following steps are ordered from lowest to highest security risk (and from most targeted to most sweeping).

For individual users (safe, conservative)​

• Use the Unblock checkbox for one‑off, known‑good files. This is the least risky and preserves MoTW protections for other files.
• If you preview many files from a trusted vendor, download attachments into a controlled folder and unblock only that folder’s files after vetting.

For power users / small teams (scripted but cautious)​

• Use PowerShell to unblock a specific folder tree you control:
• Get‑ChildItem -Path "C:\Users\YourUser\Downloads" -Recurse | Unblock‑File
• Log and hash files before unblocking as an audit trail.
• Restrict the unblock script to specific file types and locations (avoid blindly unblocking all file types in arbitrary locations).

For enterprises (policy and compensations)​

• Preferred approach: reduce the need to change zone behaviour. Instead:
• Add known vendor portals and internal resources to Trusted Sites or Local intranet zones so files saved from those locations do not receive the Internet zone tag by default.
• Harden network egress: block outbound SMB/445 and other file‑sharing protocols to the Internet at the perimeter; this prevents attackers from capturing NTLM authentication even if a client attempts to resolve an external UNC.
• Enforce SMB signing and modern authentication to reduce the usefulness of captured NTLM material.
• Use EDR and network monitoring to detect anomalous SMB/NTLM sessions or attempts to reach suspicious endpoints.
• If you must remove MoTW at scale, do it with targeted, logged automation and deploy compensating controls (EDR, DLP, strict segmentation).

Group Policy / Registry option (high‑risk)​

• The Group Policy “Do not preserve zone information in file attachments” (Attachment Manager) prevents writing the Zone.Identifier to saved attachments. This stops MoTW from being added, thereby restoring preview behavior for new downloads, but it removes a key provenance signal the OS uses to apply other protections (Office Protected View, SmartScreen). Only consider this with robust compensating controls and approval from security/compliance teams.

---

Quick checklist for triage (IT teams)​

• Confirm the behavior: select a downloaded file in Explorer; see the protective message.
• Check for Zone.Identifier ADS: Get‑Item -Path .\file.pdf -Stream * or use Sysinternals streams.exe.
• Test unblock for a single file to confirm preview returns.
• Evaluate the workflow impact (which teams rely on Preview for high‑volume triage).
• Decide mitigation: per‑file unblock, scripted unblocking for constrained repositories, Trusted Sites for vendor portals, or network/EDR hardening.
• Document any bulk operations and maintain audit logs.

Community practitioners and forum posts are already sharing pragmatic playbooks that mirror the steps above, but they caution against wholesale removal of MoTW without auditing and compensations.

---

Critical analysis: strengths, costs and open questions​

Strengths — why this is defensible​

• The mitigation is immediate and simple: blocking inline previews for Internet‑zoned files removes a low‑effort trigger attackers could abuse for NTLM capture.
• It reduces exposure without requiring complex fixes to dozens of preview handlers across third‑party applications.
• The change buys time for more surgical patches or architectural fixes that eliminate the root parsing bugs without impacting user productivity.

Short‑term costs and operational friction​

• The Preview pane is heavily used in many workflows; the change imposes extra clicks and application launches that add time and friction.
• High‑volume operations that triage dozens or hundreds of documents per day (accounts payable, legal intake, HR onboarding) face measurable productivity loss.
• Administrators now must choose between restoring convenience and retaining a valuable security artifact (MoTW). Many of the available workarounds (mass unblocking, disabling MoTW) increase attack surface if misapplied.

Gaps and risks in public explanation​

• Microsoft’s consumer‑facing support note explains the behavior and how to unblock files, but it does not publish a full engineering postmortem with the precise internal registry keys, URLAction values, or the full set of affected preview handler conditions. Community analysis has inferred the likely internal check (URLACTION_SHELL_PREVIEW) but that remains a well‑reasoned inference until Microsoft publishes a detailed technical breakdown. Administrators should treat low‑level registry “fixes” from community threads as experimental until validated.
• The mitigation is effective against the documented NTLM capture model, but defenders still need to monitor for other vectors where automatic parsing or indexing (search crawlers, antivirus engines, thumbnailers) might trigger outbound resolution.

What to watch next​

• Microsoft’s Release Health and Windows Update channels for a targeted fix or Known Issue Rollback (KIR) that restores a more nuanced preview behavior.
• Official engineering documentation that explains whether this is a permanent policy change or an interim mitigation while root causes are fixed.
• Security vendor telemetry for any observed exploitation attempts that align with the attack model the mitigation defends against.

---

The bigger picture: security posture vs. user experience​

This change demonstrates a recurring trade‑off platform vendors face: retrofitting decades of convenience features into an environment where remote content and advanced credential attacks are routine. The Preview pane sits at the intersection of usability and security — it’s convenient because it performs lightweight rendering in‑process, and it’s risky because that same lightweight rendering can be coerced into network activity.
Microsoft’s choice to flip the default is conservative and defensible from a threat mitigation perspective. It prioritizes cutting a low‑cost path attackers can exploit before more precise mitigations are broadly available. The cost falls on users and administrators, who must now implement targeted workarounds or adjust processes. That friction is real but also manageable if organizations apply principled, auditable steps: zone exceptions for trusted portals, scoped PowerShell scripts with logging, and network/SMB hardening to blunt the underlying risk.

---

Step‑by‑step recovery recipes (concise)​

Restore preview for a single trusted file​

• Right‑click file → Properties.
• Under General, check Unblock, then Apply → OK.
• Select the file again in Explorer; preview should return.

Unblock all PDFs in Downloads (PowerShell)​

• Open PowerShell as Administrator.
• Run: Unblock-File -Path "C:\Users\admin\Downloads*.pdf"
• Verify previews for those files.

Unblock recursively for a folder​

• Get-ChildItem -Path "C:\Shared\VendorDocs" -Recurse | Unblock-File
• Log the action and consider hashing files pre/post as an audit.

Add a vendor portal to Trusted Sites (so files won’t get MoTW)​

• Open Internet Options → Security → Trusted Sites → Sites.
• Add https://portal.vendor.example
• Files downloaded from that site will derive from a non‑Internet zone and will not receive the Internet tag.

Warning: each of the above steps weakens a specific protection layer; treat them as compensating controls and maintain logs and approvals.

---

How to talk to leadership and users about this change​

• For leadership: explain the change as an intentional, preventive security hardening deployed to stop an attack technique that could extract negotiable authentication material with very little user interaction. Emphasize that the buttoned‑down default reduces risk immediately while a more surgical fix is developed.
• For users: explain the short‑term friction (a few extra clicks to view downloaded file contents) and provide a simple, documented unblock process for known good files. Offer a scripted, logged path for teams that process high volumes of vendor documents.

Community threads and enterprise boards have been flooded with reports of the change and how to mitigate its impact; those conversations reflect both the security rationale and the pain users feel when the Preview pane no longer works as expected.

---

Conclusion​

Microsoft’s disabling of File Explorer’s Preview pane for Internet‑zoned files is a deliberate, security‑first move that addresses a practical NTLM credential‑leak attack vector. The change is effective and immediate, but it also imposes real productivity costs that administrators and users must manage. For most environments the safest path is targeted mitigation: add trusted portals to appropriate zones, script narrow unblocks for constrained repositories, harden authentication and network egress, and monitor for suspicious SMB/NTLM traffic. Avoid broad, permanent disabling of MoTW unless you pair that step with robust compensating controls and an auditable governance process.
Until Microsoft publishes more detailed engineering notes or issues a more surgical fix, organizations should treat the October 2025 behavior as an intentional hardening and plan compensating controls accordingly — balancing the immediate security benefits against the operational pain of lost preview convenience.

---

Source: Windows Latest Microsoft admits File Explorer Preview pane won't work in Windows 11 25H2 for internet files by default