If you found an empty C:\inetpub folder in the root of your Windows 11 install after applying recent cumulative updates, don’t panic — Microsoft put it there on purpose as a protective measure tied to a security patch, and deleting it can weaken your system’s defenses or even break future updates if misused.
Windows users started reporting a mysterious, empty folder named inetpub appearing on the system drive after installing April 2025 cumulative updates (packages such as KB5055523 and related rollups). The folder looks like an IIS artifact — because that’s what the name traditionally signals — but it was created even on machines that did not have Internet Information Services (IIS) installed. Initially the behavior caused confusion and prompted many to delete the empty folder, believing it to be harmless clutter or a mistake. Microsoft later clarified that folder creation was intentional and tied to the mitigation of an elevation-of-privilege vulnerability tracked as CVE-2025-21204. The company updated its security advisory to explicitly warn administrators and end-users: “After installing the updates listed in the Security Updates table for your operating system, a new %systemdrive%\inetpub folder will be created on your device. This folder should not be deleted regardless of whether Internet Information Services (IIS) is active on the target device.”
Source: BetaNews What is the inetpub folder that’s suddenly appeared on Windows 11 systems?
Background / Overview
Windows users started reporting a mysterious, empty folder named inetpub appearing on the system drive after installing April 2025 cumulative updates (packages such as KB5055523 and related rollups). The folder looks like an IIS artifact — because that’s what the name traditionally signals — but it was created even on machines that did not have Internet Information Services (IIS) installed. Initially the behavior caused confusion and prompted many to delete the empty folder, believing it to be harmless clutter or a mistake. Microsoft later clarified that folder creation was intentional and tied to the mitigation of an elevation-of-privilege vulnerability tracked as CVE-2025-21204. The company updated its security advisory to explicitly warn administrators and end-users: “After installing the updates listed in the Security Updates table for your operating system, a new %systemdrive%\inetpub folder will be created on your device. This folder should not be deleted regardless of whether Internet Information Services (IIS) is active on the target device.” What is inetpub and why does it matter now?
The historic purpose of C:\inetpub
- inetpub is the traditional filesystem root used by Internet Information Services (IIS) on Windows systems. When IIS is enabled, inetpub typically hosts web content, logging, and service-related folders (for example, inetpub\wwwroot and inetpub\logs). That association led many users to assume IIS had been installed or activated when the folder appeared.
Why Microsoft created it this time
Microsoft’s April 2025 security updates addressed a link‑following vulnerability in the Windows Update / Process Activation stack (CVE-2025-21204). The underlying flaw concerns how the servicing stack resolved links (symbolic links / junctions) prior to performing file access. On unpatched systems, a low‑privilege local user could create links that redirect privileged file operations to unexpected locations, enabling escalation to SYSTEM-level file management actions. Creating a controlled folder with restricted permissions reduces the attack surface by occupying an expected filesystem path and enforcing a predictable Access Control List (ACL) — a pragmatic mitigation while the servicing stack is hardened.- In short: the folder is not accidental. It acts as a protective placeholder that, together with updated code, helps block attacks that rely on tricking privileged components into following attacker-controlled links.
Technical mechanics — how the mitigation works (plain language)
- The vulnerable component is part of the Windows update/activation stack and runs with elevated privileges (NT AUTHORITY\SYSTEM).
- If a privileged component attempts to access or create files under a path that does not exist, a local attacker could previously create a link (junction or symlink) at that path that resolves to another file or folder under their control.
- The attacker’s link could redirect the privileged operation to alter or replace files that should be protected — enabling local privilege escalation or tampering with critical files.
- By pre‑creating the target folder (C:\inetpub) with system-only and tightly restricted ACLs, the update removes the opportunity for an attacker to plant a redirecting link at that path.
- Additional servicing fixes harden the link‑resolution logic; the folder is part of a layered defense.
Evidence and independent corroboration
Multiple independent technology and security outlets confirmed Microsoft’s advisory and investigated the behavior:- BleepingComputer reproduced the folder creation during testing and reported Microsoft’s advisory telling users not to delete it. They also noted the folder is owned by the SYSTEM account, which aligns with it being created by elevated update processes.
- The Register and other outlets explained the change as part of the fix for CVE‑2025‑21204 and described how the folder is created with restrictive permissions to act as a shield.
- Security vendors and vulnerability trackers include the inetpub creation in their mitigation notes for CVE‑2025‑21204 and assign the vulnerability a significant risk score, underscoring why an aggressive, visible mitigation was warranted.
Practical consequences and risks
What happens if you delete C:\inetpub?
- Immediate system behavior: Deleting the folder typically does not break day‑to‑day Windows functionality for consumer users — in many tests the OS continued operating normally after removal. However, doing so removes a component of the mitigation and leaves the system in a state where the underlying servicing stack fix may not function as intended.
- Update failures and update-blocking attacks: Security researchers and journalists noted a secondary risk: if C:\inetpub is missing or, worse, replaced by a file or a malicious junction, update installation can fail or become manipulable. Attackers with local access can potentially exploit that state to block updates or force installer errors. One public write‑up demonstrated how a malicious junction could be used to interfere with updates, turning deletion of the folder into an operational weakness.
How attackers might abuse folder deletion
- A local, non‑privileged user could create a junction named C:\inetpub that resolves to an arbitrary file path. Since some privileged operations assume inetpub is a folder, the presence of a file or link can make installers or update components misbehave, potentially stopping future updates.
- That means deleting or replacing the folder can be weaponized: an attacker with local access could interfere with system updates and persistence mechanisms. Security advisories therefore treat preservation of the folder as part of the mitigation strategy.
Enterprise impact
- Imaging and provisioning: Organizations that create golden images or custom provisioning scripts should account for the inetpub folder and its ACLs; otherwise, deployment sequencing could surface unexpected update failures.
- Patch management: WSUS, SCCM, and other update orchestration tools may encounter error codes if the expected path exists as a file or with different permissions; administrators should test updates against their baseline images and follow Microsoft’s remediation guidance if the folder was removed.
- Incident response: If a workstation is found missing the inetpub folder, teams should treat that as a configuration drift issue and restore the folder before running further updates; a missing or suspicious inetpub may warrant forensic review for local tampering.
How to check the folder and verify it’s the legitimate mitigation
- Inspect the folder owner and ACL:
- Right‑click C:\inetpub → Properties → Security → Advanced.
- The folder should be owned by SYSTEM and show restrictive ACLs that prevent standard user write access.
- Confirm the folder is empty (most systems will show no files) and that IIS is not enabled (Control Panel → Programs and Features → Turn Windows features on or off).
- If you see unexpected files inside inetpub or the folder is owned by a regular user, treat that as suspicious and investigate further; revert the ACL and ownership to SYSTEM, or follow Microsoft’s restoration procedures below.
Restoration and remediation: what to do if you deleted it
If you removed the folder before Microsoft clarified its purpose, or if an admin image lacks it, these are supported ways to restore the folder and ACLs.- Option A — Reinstall/repair via Windows Features (simple, GUI):
- Open Control Panel → Programs and Features → Turn Windows features on or off.
- Enable Internet Information Services (IIS), click OK. This will recreate C:\inetpub with the standard permissions.
- Once recreated, you may choose to disable IIS again; the folder and ACLs will remain.
- Option B — Microsoft’s PowerShell script (recommended for automation):
- Microsoft published (and the community mirrored) a small PowerShell script to re‑create the folder and set ACLs correctly: the Set‑InetpubFolderAcl utility on the PowerShell Gallery.
- From an elevated PowerShell prompt:
- Install‑Script ‑Name Set-InetpubFolderAcl
- Run the script from the installed path (example instructions are published alongside the script).
- The script sets ownership and restrictive ACL entries appropriate for the mitigation and is suitable for batch or remote remediation tasks.
- Option C — Manual recreation (advanced):
- Create the folder as Administrator: mkdir C:\inetpub
- Set owner to SYSTEM and apply restrictive ACLs using icacls or PowerShell Set‑Acl. This requires accuracy — incorrect ACLs may leave the system vulnerable or cause update issues — so prefer Microsoft’s script if possible.
Recommendations for end users and administrators
- For home users:
- Do not delete C:\inetpub. It occupies negligible disk space and is part of a security mitigation for CVE‑2025‑21204. Leave it alone.
- If you already removed it, restore using the PowerShell script or by toggling IIS on in Windows Features to recreate it, then turn IIS off again if you don’t need it.
- For system administrators:
- Update golden images: ensure images used for deployment include C:\inetpub with the correct ACLs or run the Microsoft script as part of imaging post‑provisioning tasks.
- Audit endpoints: scan for devices where inetpub is missing, is a file, or has weaker-than-expected ACLs; prioritize remediation.
- Harden local user environments: restrict the ability for non‑privileged users to create arbitrary junctions in user-writable locations; monitor for symlink/junction abuse where local users should not have such capabilities.
- Test patches in representative lab environments to confirm your update tooling (WSUS, Configuration Manager, third‑party patch managers) tolerates the folder state in your organization.
What this episode reveals about patch communication and trust
Microsoft’s decision to deploy a visible filesystem artifact as part of a security mitigation — and to leave early guidance sparse — exposed a communications gap. The unexpected appearance of an empty folder named after a long‑standing IIS directory name was understandably alarming to users and led to rushed deletions that undermined the mitigation. That confusion highlights two lessons for vendor patching and enterprise security:- Vendors should anticipate and explicitly document visible, non-obvious artifacts introduced by mitigations — particularly when those artifacts are named after long‑established system folders that signal other, unrelated subsystems (IIS in this case).
- Administrators need an established practice for checking vendor advisories and for handling unexpected changes from monthly update cycles; changes that are safe to ignore for functionality may still be important for security.
Quick reference: facts you can rely on
- The inetpub folder was created by Microsoft’s April 2025 security updates (examples include KB5055523 and related packages) as part of mitigation for CVE‑2025‑21204.
- Microsoft explicitly advised that the folder should not be deleted, even if IIS is not used on the device.
- If you already deleted the folder, Microsoft published remediation options including enabling IIS (which recreates the folder) and a PowerShell script (Set‑InetpubFolderAcl) to recreate the folder and correct ACLs.
- Deleting or replacing the folder with a file/junction can be weaponized to block updates or cause installer errors; leave it in place.
Final analysis — strengths of Microsoft’s approach and remaining risks
Strengths
- The mitigation is pragmatic and immediate: creating a folder with correctly set ACLs is a rapid, clear way to close a local attack vector while code‑level hardening is delivered.
- The approach is minimally invasive for end users (a near‑empty folder with restricted access) and straightforward to deploy through the normal Windows Update channel.
- Microsoft provided follow‑up remediation tools (PowerShell script) and updated advisories after community reporting, which helps administrators standardize remediation across fleets.
Risks and trade‑offs
- The folder’s name and placement caused user confusion and reactive deletions — illustrating the risk of visible mitigations that are not accompanied by immediate, clear vendor communication.
- The mitigation relies on filesystem state; if that state is altered (folder removed, replaced with a file, or redirected via junction), the mitigation can fail and create an operational weakness, potentially allowing attackers to disrupt updates.
- The incident shows how local, low‑privileged operations like creating junctions can be weaponized in obscure ways — organizations should treat such filesystem manipulations as suspicious and monitor accordingly.
Conclusion
The unexpected C:\inetpub folder that appeared after Windows 11 updates in April 2025 is not malware and wasn’t placed there by accident — it’s an intentional, visible element of Microsoft’s mitigation for CVE‑2025‑21204. While it does nothing visible for most users, it performs a defensive role and should not be deleted. Administrators and security teams should verify the folder’s presence and ACLs on managed systems, remediate deleted or misconfigured instances using Microsoft’s guidance, and revise imaging and provisioning processes to ensure the mitigation remains effective. Leaving the folder in place — or restoring it when necessary — is a small step that removes a potential avenue for local privilege escalation and update tampering.Quick checklist (one-minute actions)
- Do nothing if you see C:\inetpub and it’s owned by SYSTEM. Leave it alone.
- If you deleted it, run Microsoft’s Set‑InetpubFolderAcl script or re‑enable IIS to recreate it.
- Audit endpoints for unexpected inode types (file vs folder) at C:\inetpub and remediate suspicious cases.
- Update image build and deployment scripts so newly provisioned machines aren’t missing the folder.
Source: BetaNews What is the inetpub folder that’s suddenly appeared on Windows 11 systems?
