June 2026 Windows Update: Desktop.ini Trust Changes in File Explorer

Microsoft’s June 9, 2026 Windows security updates, including KB5094126 for Windows 11 24H2 and 25H2 and KB5093998 for Windows 11 23H2, changed how File Explorer handles desktop.ini folder customizations from sources Windows does not trust. The result is not data loss, and it is not a broken Explorer shell. It is Microsoft drawing a harder line between cosmetic convenience and an old, quiet attack surface that most users never knew existed. For administrators, the lesson is blunt: if a folder’s identity depends on a hidden configuration file from a remote or internet-marked source, Windows may now refuse to play along.

Microsoft Turns a Cosmetic File Into a Trust Boundary​

Desktop.ini has always been one of those Windows details that feels too small to matter until it suddenly does. It is a hidden configuration file that lets Windows give folders custom icons, localized display names, and other Explorer presentation behavior. In ordinary use, it is why a folder can appear with a friendly translated name or a branded icon even though the underlying file system name remains more prosaic.
The June 2026 security updates change the assumption behind that convenience. Starting with updates released on or after June 9, Windows now ignores certain desktop.ini files when it cannot establish that the file’s source is trusted. When that happens, File Explorer behaves as though the desktop.ini file simply is not there.
That means a folder may still open, files may still be present, permissions may still work, and the underlying directory may still be healthy. What disappears is the presentation layer: the custom icon, the localized folder name, or the display treatment that made the folder look managed, branded, or user-friendly.
This is why the change is easy to underestimate. Nobody’s documents vanish because of it. But in managed Windows environments, the visual layer often carries operational meaning. A folder icon can signal a department share, a published application directory, a training library, or a localized system folder. When that signal disappears, users do not see “security hardening.” They see “something broke.”

The Old Explorer Contract Was Too Trusting​

The old behavior reflected a long-standing Windows bargain: the shell would read desktop.ini automatically and use it to decorate the user interface. That made sense in a world where most customized folders lived on local disks or tightly managed corporate shares. It makes less sense in a world where files constantly arrive from browsers, sync clients, remote WebDAV locations, collaboration systems, and loosely classified network paths.
Microsoft’s June change treats desktop.ini as something closer to active content than passive metadata. That is the right mental model. A file that is automatically parsed by the shell, used to pull icons or localized strings, and processed simply because a user browses into a directory is not just a decoration. It is part of the code path between untrusted content and the Windows user session.
The company’s support note frames the behavior as expected, not as a known issue. That distinction matters. This is not a temporary regression that administrators should assume will quietly disappear in July. It is a new default security posture, and Microsoft is providing workarounds because compatibility still matters, not because it believes the previous behavior was safer.
The change also lands in a Patch Tuesday month already crowded with security fixes. June 2026 brought roughly 200 Microsoft vulnerability fixes, depending on how third-party republished CVEs are counted, and several publicly disclosed zero-days were part of the conversation around the release. Against that background, a desktop.ini hardening note looks minor. Strategically, it is not minor at all.

Mark-of-the-Web Comes for Folder Polish​

The most familiar trigger is Mark-of-the-Web, the zone metadata Windows attaches to many files downloaded from the internet. For years, MotW has been central to SmartScreen prompts, Office Protected View behavior, archive extraction debates, and script-blocking decisions. Now it is also part of the trust story for folder presentation.
If a desktop.ini file arrives with MotW, Windows may treat it as coming from an untrusted source and decline to apply its folder customizations. That can happen when content is downloaded directly, extracted from a downloaded archive that preserves zone information, or moved through workflows that keep internet-origin metadata intact.
This is not the only affected path. Microsoft also calls out files copied from certain remote locations, including some WebDAV or HTTP-based locations, and network paths that are not classified as intranet or trusted by Windows zone policy. In other words, this is not simply a “downloaded from Edge” story. It is a broader zone-classification story.
That puts the burden back where Microsoft increasingly wants it: on explicit trust configuration. If an organization wants Windows to treat a remote location as safe enough to provide shell customization data, it should classify that location accordingly. The default is moving away from “it worked before” and toward “prove this source belongs inside the trust boundary.”

The Enterprise Blast Radius Is Narrow but Annoying​

For most home users, the impact will be close to invisible. A custom folder icon from an old theme pack may disappear. A downloaded folder template may look generic. A localized display name may fall back to the directory’s real name. Annoying, yes, but rarely business-critical.
Enterprise environments are where this gets more interesting. Shared folders are often curated more heavily than outsiders realize. IT departments and line-of-business teams use folder icons, display names, and localized resources to make large network hierarchies navigable. A finance share might use an icon that distinguishes it from a project archive. A multilingual environment might rely on localized display names so users do not have to interpret internal English directory names.
The problem is not that the folders stop working. The problem is that Windows can make a managed structure look unmanaged. Help desks will hear reports that shared folders “changed,” “lost their labels,” or “look wrong” after the June updates. The actual fix may involve zone policy and trust classification, but the user-facing symptom is cosmetic enough to be dismissed until it becomes a support pattern.
This is precisely the sort of change that punishes informal infrastructure. If a company’s network shares are correctly classified as intranet or trusted through policy, there may be little disruption. If teams have built ad hoc WebDAV repositories, HTTP-exposed document stores, or remote paths outside clean zone governance, June’s update may expose that mess in the Explorer UI.

Microsoft Offers an Escape Hatch, but It Is the Wrong Default​

Microsoft’s preferred mitigation is narrow trust. If affected content lives on a known internal or managed source, administrators should add that source to Trusted Sites so Windows continues processing desktop.ini customizations from that location. That keeps the hardening in place for unknown or internet-origin sources while restoring expected behavior for controlled infrastructure.
That recommendation is not glamorous, but it is sound. It forces administrators to distinguish between “this source is ours” and “we want the old behavior everywhere.” In security terms, that distinction is everything.
There is also a Group Policy option: “Allow the use of remote paths in file shortcut icons.” Enabling it restores the pre-June 2026 behavior for affected remote or untrusted scenarios. That is the compatibility lever for organizations that cannot quickly reclassify sources or untangle legacy folder customization workflows.
But broad opt-outs should be treated as temporary debt, not a fix. Restoring old behavior may be convenient, especially when a help desk is flooded with cosmetic complaints, but it also weakens the hardening Microsoft just introduced. If the point of the change is to prevent untrusted remote customization content from being processed automatically, telling Windows to broadly trust that content again is a retreat.

Unblocking Files Is a Scalpel, Not a Broom​

Microsoft also points to removing Mark-of-the-Web from trusted desktop.ini files as a possible workaround. In PowerShell, that means using Unblock-File against a specific desktop.ini or recursively against desktop.ini files under a known folder path. Technically, this can restore the expected folder presentation.
Operationally, it is easy to misuse. Removing MotW is not a cosmetic repair; it strips a security signal. That may be perfectly reasonable for a desktop.ini file staged by IT from a verified internal package. It is much harder to justify as a blanket action against a pile of downloaded archives, user-submitted content, or loosely governed shared folders.
The better pattern is to decide whether the source should be trusted, not whether the symptom is irritating. If the source is a managed repository, classify it properly. If the file is a one-off from a trusted internal package, unblock it deliberately. If nobody can explain where the desktop.ini came from, Windows ignoring it is probably doing exactly what it should.
This is where Windows administration has quietly become less about toggles and more about provenance. The old question was “how do I make Explorer show the right icon?” The new question is “why should Explorer trust this hidden file in the first place?”

A Small Change With a Familiar Microsoft Tradeoff​

Microsoft has been steadily moving Windows toward stricter defaults around files from the internet, remote content, macros, scripts, and shell-adjacent behavior. The June desktop.ini change fits that arc. It is another case where compatibility yields to a security model that assumes untrusted content will eventually be weaponized.
The tradeoff is that Windows still carries decades of behaviors designed for a more trusting computing environment. Desktop.ini is not some exotic enterprise extension. It is part of the ordinary shell. That makes hardening difficult because every security improvement risks breaking workflows that were never documented as workflows in the first place.
There is also a communication problem. A security update that changes visual behavior in File Explorer will feel like a bug to many users. The absence of a custom icon is not obviously related to internet zone metadata. A localized folder name falling back to its real directory name does not scream “trust classification.” It screams “the update changed my folders.”
That gap between cause and symptom is where administrators need to get ahead of the story. If your organization uses customized network folders, June’s update should trigger a quick audit: where do those desktop.ini files live, how are they distributed, and does Windows classify those locations as trusted?

The Explorer Shell Is Still an Attack Surface​

It is tempting to roll one’s eyes at security hardening around folder icons. That temptation should be resisted. The Windows shell has always been a rich attack surface because it automatically interprets so many file types, metadata formats, preview handlers, icon handlers, property sheets, and extension points. Anything that runs because a user browses a folder deserves scrutiny.
Desktop.ini is less powerful than many shell extension mechanisms, but the principle is the same. If untrusted content can influence what Explorer loads or how it resolves resources, it belongs in a threat model. Attackers do not need every primitive to be spectacular. They need enough small, reliable behaviors to chain into something useful.
Microsoft’s support article does not claim that every desktop.ini file is dangerous. It says Windows will ignore desktop.ini when it cannot establish trust. That is a more measured position. Trusted local and managed sources continue to work. Unknown remote or internet-marked sources are treated with suspicion.
That is the right direction for a platform that must serve home users, schools, hospitals, manufacturers, governments, and sysadmins still nursing file-share conventions from the Windows 7 era. The hard part is not the security logic. The hard part is the installed base.

---

The June Patch Quietly Makes Folder Branding a Governance Problem​

This update’s real message is that folder customization is no longer just a UX preference. It is now tied to Windows’ broader source-trust model, and that makes it part of endpoint governance.

• Windows now ignores some desktop.ini files when their source cannot be established as trusted.
• The visible symptoms are missing custom folder icons, missing localized display names, or folders reverting to their underlying file system names.
• The change affects presentation only and does not block access to the folder or its contents.
• The most likely pain points are downloaded content, WebDAV or HTTP-based locations, and network paths not classified as intranet or trusted by policy.
• Microsoft’s preferred remediation is to trust known internal sources narrowly, not to restore legacy behavior everywhere.
• The Group Policy escape hatch should be treated as a compatibility bridge rather than a permanent security posture.

The practical path forward is not to panic over missing icons, and it is not to disable the hardening across the estate at the first complaint. It is to treat the symptom as a map of trust assumptions Windows used to forgive. June’s updates make those assumptions visible, sometimes awkwardly, and the organizations that respond by cleaning up source classification will be in a better place than those that simply teach Windows to look away again.

---

References​

1. Primary source: Windows Report
   Published: 2026-06-11T07:10:12.521253
   
   

   KB5094126 and KB5093998 Introduce New Desktop.ini Security Restrictions in Windows

   Microsoft confirmed that June 2026 Windows updates now block some desktop.ini folder customizations from untrusted sources.

   windowsreport.com

 

[ChatGPT]

Microsoft’s June 9, 2026 Windows security updates deliberately changed how Windows 10, Windows 11, and supported Windows Server releases handle folder customizations stored in desktop.ini, causing some custom folder icons and localized folder names to disappear when Windows cannot trust the file’s origin. What looks like another Explorer regression is really a security boundary being moved into one of Windows’ oldest personalization mechanisms. The change is narrow, but the lesson is broad: Windows is becoming less willing to treat decorative metadata as harmless. For users and administrators, the annoyance is not that Microsoft broke icons; it is that Microsoft broke an old assumption silently.

Microsoft Turns a Cosmetic File into a Trust Decision​

The humble desktop.ini file has always lived in a strange corner of Windows. It is not an executable, not a document most users open, and not a setting exposed in a modern Settings page. It is a hidden configuration file that tells Explorer how a folder should present itself: which icon to show, which localized display name to use, and how the shell should dress up a directory that is otherwise just a directory.
That design made sense in an era when Windows was a local-first operating system and the file system was a trusted neighborhood. A folder on disk could carry a little metadata, Explorer would read it, and the user would see a nicer icon. The feature became part of the furniture: language packs, special folders, media libraries, and obsessive desktop customizers all leaned on it.
Microsoft’s June 2026 hardening changes that bargain. If Windows cannot establish that the desktop.ini file came from a trusted source, Explorer ignores it and behaves as if it were not there. The folder still opens. The files are still accessible. But the visual layer — the custom icon or localized display name — is stripped away.
That distinction matters. Microsoft is not deleting customizations, and it is not corrupting folders. It is refusing to honor presentation instructions from a file that has crossed a trust boundary. In security terms, that is defensible. In user-experience terms, it is maddening.

The Bug That Was Never a Bug​

The first wave of complaints was predictable because the symptom looks exactly like a bad Windows update. A user installs the latest cumulative update, reboots, opens File Explorer, and suddenly lovingly curated folder icons have reverted to beige defaults. No warning appears. No toast explains the policy. No migration assistant says, “This customization was blocked because the source is untrusted.”
Microsoft’s documentation says the behavior is expected for Windows security updates released on or after June 9, 2026. It affects custom folder icons defined by desktop.ini and localized folder display names defined the same way. It can occur even when the user did not change any app setting or folder setting.
That last point is the crux. From the user’s point of view, the operating system changed the rules after the fact. A folder that looked correct on Monday may look generic after Tuesday’s Patch Tuesday cycle. A customization that has sat harmlessly for years can suddenly fail because the file now carries a trust signal Windows chooses to enforce.
This is why “by design” is never the end of the story. A change can be intentional and still disruptive. Microsoft is correct that the new behavior is not a defect in the narrow engineering sense. But users are also correct to experience it as breakage, because the visible output of the system changed without consent or explanation.

Mark-of-the-Web Keeps Escaping Its Original Box​

The most important phrase in this story is Mark-of-the-Web. MotW is Windows’ way of recording that a file came from the internet or another less trusted zone. Technically, it is often stored as Zone Identifier metadata attached to a file on NTFS. Practically, it is the reason downloaded installers trigger SmartScreen, Office documents open with additional caution, and some files behave differently after extraction from a ZIP archive.
For years, MotW was something power users mostly associated with executables, scripts, macros, and documents. That mental model is now too small. Microsoft has been expanding the places where origin metadata affects behavior, including File Explorer’s preview behavior for internet-origin files. The desktop.ini hardening is another example of the same philosophy moving deeper into the shell.
The logic is easy to follow. If a file came from the internet, a remote WebDAV location, an HTTP-based share, or a network path that policy does not classify as intranet or trusted, Windows should not blindly let it influence the shell. Even if the visible effect is “just an icon,” Explorer is still parsing instructions from metadata supplied by an external source.
That does not mean every blocked desktop.ini file was dangerous. Most are probably mundane. But modern Windows security increasingly works by treating origin as a first-class signal, not by waiting until a file proves malicious. In that model, the operating system would rather inconvenience a customization enthusiast than keep an ambiguous legacy behavior alive.

The Real Target Is Remote Presentation Mischief​

A custom folder icon sounds harmless until you remember what icons and names do in a graphical shell: they tell users what something is. A folder icon can make one location look like another. A localized display name can obscure the underlying file-system name. A network-delivered folder can present itself with a visual identity that nudges users toward trust.
That is not the same as arbitrary code execution. Microsoft is not saying that a desktop.ini file is suddenly the new macro virus. The risk is subtler: presentation metadata can be part of deception, especially when combined with remote paths, downloaded archives, phishing lures, or enterprise shares that users do not fully understand.
Windows has a long history of attacks that abuse the gap between what a user sees and what the system is actually doing. File extensions can be hidden. Shortcut icons can be misleading. UNC paths can cause authentication leakage. WebDAV can make remote content feel local. Against that backdrop, tightening the rules around folder presentation is not paranoia; it is a continuation of a very old defensive trend.
The awkward part is that Windows users have also spent decades using the same mechanisms for legitimate customization. The same desktop.ini file that localizes a folder name or gives a project folder a distinctive icon can be treated with suspicion if it arrives with the wrong provenance. Microsoft is not killing personalization outright. It is making personalization conditional on trust.

The Fixes Reveal Microsoft’s Preferred Security Model​

Microsoft’s suggested mitigations are revealing because they are not all equal. The recommended path is to add the affected source to Trusted Sites if it is an internal or managed location. That keeps the new protection intact everywhere else while telling Windows that a specific source should be allowed to provide folder presentation metadata.
The second option is broader: enable the policy that allows the use of remote paths in file shortcut icons. That restores older behavior for affected remote or untrusted scenarios, but Microsoft warns that it reduces protection against malicious remote folder-customization content. In other words, this is the compatibility lever, not the security-first lever.
The third option is to remove Mark-of-the-Web from trusted desktop.ini files. PowerShell’s Unblock-File can do this for a single desktop.ini, and a recursive command can remove the mark from multiple such files under a folder. That will be attractive to enthusiasts who downloaded icon packs or copied carefully customized folders from another machine.
But this is also where users should slow down. Removing MotW is not a magic “make icons work” button; it is a statement that the file and its source are trusted. The safer pattern is to narrow the trust decision as much as possible. Trust the internal share you control, not the entire internet. Unblock the known icon pack you downloaded from a reputable source, not a random archive of shell tweaks you forgot you had.

Home Users Get the Weirdest Version of the Change​

For home users, the impact will be uneven and sometimes baffling. Many people never touch folder icons and will never notice. Others keep elaborate collections of custom folders for games, media, work projects, photography archives, or school files. Those users are exactly the sort of Windows enthusiasts who feel small visual regressions most acutely.
The confusing cases will involve copied folders. A folder customized on one PC may lose its icon after being downloaded from cloud storage, extracted from an archive, moved from a NAS, or copied from a remote HTTP or WebDAV-backed location. The desktop.ini file may still be present. The icon file may still exist. The attributes may still look mostly right. Explorer may simply decline to honor the instruction.
That makes old troubleshooting advice incomplete. Clearing the icon cache, reapplying the folder icon, toggling hidden files, or blaming OneDrive sync may not solve the problem if the root cause is origin trust. The relevant question is no longer only “Is desktop.ini correctly formatted?” It is also “Does Windows trust where this desktop.ini came from?”
The best consumer fix is usually modest. If the folder came from a ZIP file or download you trust, unblock the relevant desktop.ini files and, if necessary, the icon files themselves. If the folder lives on a NAS or remote share, consider whether Windows classifies that location as intranet or trusted. If the source is not something you would trust with scripts or shortcuts, do not trust it just to recover a prettier icon.

Enterprise IT Gets a Policy Problem Disguised as a Cosmetic One​

In managed environments, this change is less about aesthetics and more about support friction. Enterprises often rely on localized folder names, branded shared folders, departmental icons, packaged training materials, and file shares that have accumulated shell customizations over years. If those folders suddenly present differently after June 2026 updates, help desks will hear about it.
The good news is that the affected behavior is presentation-only. Microsoft says access to the folder and the files inside it is not affected. This should not break line-of-business data by itself. A user may see the original folder name instead of the localized display name, or a default icon instead of a departmental one, but the underlying path remains available.
The bad news is that presentation changes can still disrupt workflows. Users navigate by recognition, not just by path. A localized display name reverting to an internal name can create confusion in multilingual organizations. A custom icon disappearing from a shared project directory can make a familiar file tree feel unfamiliar.
Administrators should resist the temptation to flip the broad compatibility policy everywhere. The better response is inventory and classification. Identify which shares or remote locations legitimately need to provide desktop.ini customizations, ensure they are controlled, and classify them appropriately through zone policy. Treat the icon regression as a signal that Windows does not understand your trust boundary, not merely as a nuisance to suppress.

The Silent Failure Is the Part Microsoft Still Hasn’t Solved​

The strongest criticism of Microsoft is not the security decision. It is the silence. Explorer ignores the untrusted desktop.ini file and falls back to defaults without surfacing a reason to the user. That may reduce noise, but it also sends people chasing ghosts through icon caches, folder attributes, and registry tweaks.
Windows has always struggled with this trade-off. Too many prompts train users to click through warnings. Too few explanations turn deliberate protections into folklore. Here, Microsoft chose the quiet path, likely because a warning for every ignored folder customization would be absurd. But there is room between nagging and opacity.
Explorer could expose a property-sheet note when a folder customization is blocked. Windows Security could log a user-readable event. The shell could offer a controlled “trust this folder customization” action for local administrators. Enterprise tooling could provide clearer reporting for blocked desktop.ini processing across managed devices.
Instead, users get a default folder icon and a mystery. That is how security hardening earns a reputation as random breakage. The more Windows moves trust decisions into everyday surfaces, the more it needs everyday explanations to match.

---

The Old Windows Customization Culture Meets the New Windows Threat Model​

This episode is small, but it sits inside a larger cultural shift. Windows used to be unusually permissive about personalization, extension, and shell behavior. You could skin, replace, script, patch, and bend the interface in ways that made the operating system feel personal, messy, and powerful.
Modern Windows is less sentimental. It is a platform under constant attack, running in regulated enterprises, hybrid workplaces, schools, hospitals, and consumer homes full of downloaded archives and synced folders. Microsoft’s security posture has moved toward reducing ambient trust, even when the affected feature looks cosmetic.
That shift frustrates enthusiasts because it narrows the gap between “my PC” and “a managed endpoint.” A personal machine can feel like it is inheriting enterprise paranoia. But the threat model has also changed for personal machines. Home users download more, sync more, mount more remote storage, and interact with more files whose origin is ambiguous.
The desktop.ini change is therefore not an isolated quirk. It is another reminder that Windows is gradually treating the shell as an attack surface, not just a user interface. The beige folder icon is the visible artifact of an invisible policy decision.

The June Patch Leaves Users With a Trust Chore​

The practical path forward is not complicated, but it does require users and administrators to think like Windows now thinks. A folder customization is no longer valid merely because the file exists and the syntax is right. It is valid if Windows trusts the origin of the file providing that customization.
For readers trying to separate real risk from mere annoyance, the shape of the change is fairly clear:

• Windows security updates released on or after June 9, 2026 can cause custom folder icons or localized folder names defined through desktop.ini to stop appearing.
• The affected folders still open normally, and the change does not remove access to the files inside them.
• Files carrying Mark-of-the-Web, files copied from some WebDAV or HTTP-based locations, and files on network paths outside trusted or intranet zones are the main scenarios to check.
• The safest enterprise fix is to classify known internal sources as trusted rather than restoring older behavior broadly.
• PowerShell’s Unblock-File can restore behavior for trusted desktop.ini files, but it should not be used as a blanket cure for unknown downloads.
• If clearing the icon cache does nothing, the problem may be trust metadata rather than Explorer’s thumbnail or icon database.

The most Windows thing about this story is that both sides are right. Microsoft is right that shell metadata from untrusted sources deserves more scrutiny in 2026 than it received in 2006. Users are right that a silent visual regression after a security update feels like breakage, especially when the affected feature is one of the oldest ways people make Windows feel like their own. The future of Windows customization will not disappear overnight, but it will increasingly live behind trust decisions, policy knobs, and provenance checks — and the users who understand that shift will spend less time fighting Explorer and more time deciding which sources actually deserve to shape what Windows shows them.

---

References​

1. Primary source: XDA
   Published: Fri, 12 Jun 2026 05:11:57 GMT
   
   

   Microsoft just broke some custom folder icons, and it's deliberate

   Fortunately, there's an easy fix.

   www.xda-developers.com
2. Related coverage: windowscentral.com
   
   

   “It is intentional” Microsoft says Windows 11’s broken folder icons are by design. Here's what's going on. | Windows Central

   Windows 11 changes how folder customizations work, and what looks like a bug is actually a security upgrade.

   www.windowscentral.com
3. Related coverage: windowslatest.com
   
   

   Microsoft confirms the new Secure Boot folder in Windows 11 isn't a bug, you don't need to delete it

   New “SecureBoot” folder created by Windows 11 KB5089549 is expected behavior for Secure Boot certificates update and not a known issue.

   www.windowslatest.com
4. Official source: learn.microsoft.com
   
   

   How to Customize Folders with Desktop.ini - Win32 apps | Microsoft Learn

   Customize the appearance and behavior of an individual folder with a Desktop.ini file.

   learn.microsoft.com
5. Related coverage: windowsforum.com
   
   

   June 2026 Windows Update Breaks Custom Folder Icons from desktop.ini | Windows Forum

   Microsoft says Windows security updates released on or after June 9, 2026, may stop some custom folder icons and localized folder display names from...

   windowsforum.com
6. Official source: support.microsoft.com
   
   

   Os ícones de pastas personalizadas ou os nomes de pastas localizadas podem não aparecer após a instalação da atualização de segurança do Windows de junho de 2026 - Suporte da Microsoft

   support.microsoft.com

Spoiler: Additional references (1)

1. Official source: techcommunity.microsoft.com
   
   

   Advancing Windows driver security: Removing trust for the cross-signed driver program

   Microsoft announces the removal of trust for all kernel drivers signed by the deprecated cross-signed root program, enhancing Windows security by enforcing...

   techcommunity.microsoft.com