Introduction

In April 2025, Microsoft released a cumulative update for Windows 11 (notably KB5055523) that introduced an unexpected security feature — the automatic creation of an empty INLINECODE0 folder on all system drives. While this folder historically belongs to Microsoft's Internet Information Services (IIS) and is used mainly on servers hosting web content, its enforced presence on all Windows 11 systems, even those without IIS installed, sparked confusion. More importantly, though designed as a security measure to mitigate a critical vulnerability, this new INLINECODE1 folder itself became the target of a novel security exploit. This article unpacks the background, risks, technicalities, and practical guidance around this security development.

Understanding the inetpub Folder and Its New Role

Traditionally, the INLINECODE2 folder hosts web content, logs, and scripts related to IIS — a web server platform typically installed on Windows Server systems or developer machines. It's unusual to find this folder on personal or business devices that do not have IIS enabled.

However, the April 2025 Windows 11 update changed this by creating the folder on nearly all PCs. This was a deliberate move to counter a serious security vulnerability designated CVE-2025-21204. This flaw involves the inappropriate handling of symbolic links (also called symlinks or junctions), which are special filesystem objects pointing to other files or directories. Poor handling of such links within the Windows Servicing Stack and Update process could allow attackers with local machine access to redirect system file operations maliciously.

By introducing the INLINECODE3 folder with strict permissions (owned exclusively by SYSTEM and TrustedInstaller accounts), Microsoft intended it as a hardened, trusted container or "safe zone" for Windows Update servicing operations. This setup aims to prevent attackers from redirecting or tampering with files during update staging, thus closing an important security loophole.

The Irony: Vulnerability in the inetpub Folder Itself

Despite its protective intent, security researcher Kevin Beaumont highlighted that the INLINECODE4 folder itself can be exploited. The problem is that the Windows Servicing Stack, running with SYSTEM privileges, treats the path INLINECODE5 as fully trusted and does not verify:

  • Whether this folder is a regular directory or a directory junction (reparse point)
  • Who owns the folder or if it has been manipulated

A local user without administrative privileges can create a directory junction in place of the INLINECODE6 folder pointing to an arbitrary location or file using a command like:

CODEBLOCK0

This redirection causes Windows Update operations to incorrectly target the wrong file or location, leading to update failures, rollbacks, or denial-of-service (DoS) against the update mechanism.

Since no administrator privileges are required and the process blindly trusts this path, non-admin users with local access can disrupt critical update installations, increasing the system's exposure to other security threats.

Implications and Impact

This new vulnerability poses several risks and consequences:

  • Denial of Service on Windows Update: Attackers can prevent successful installation of security patches, extending the window for exploitation of other vulnerabilities.
  • Local Non-Admin Attack Vector: Lowering the privilege requirement expands the attack surface significantly, especially in shared or multi-user environments.
  • Increased Troubleshooting Complexity: Errors from this exploit produce confusing Windows Update failures that can mislead even experienced system administrators.

The broader implication is a cautionary tale about balancing patch deployment with new vulnerabilities, and the complexities inherent in modern operating system security design involving legacy system components.

How to Mitigate and Secure the inetpub Folder

Until Microsoft issues a formal fix addressing the servicing stack's trust verification, users and administrators can adopt the following workaround to protect their systems:

  1. Locate the INLINECODE7 folder, usually at INLINECODE8 .
  2. Right-click on the folder and choose Properties.
  3. Go to the Security tab and click Advanced.
  4. Click Disable inheritance and choose Remove all inherited permissions.
  5. Add SYSTEM and NT SERVICE\TrustedInstaller explicitly with Full Control permissions.
  6. Remove permissions for all other users, including local administrators.
  7. Apply and confirm the changes.

This permission lockdown ensures that only trusted system accounts can modify or delete the INLINECODE9 folder, preventing users from creating malicious directory junctions.

If Windows Update encounters issues after this change, resetting Windows Update components typically helps restore functionality.

Importantly, users should never delete the INLINECODE10 folder. Doing so invalidates the original security patch mitigating CVE-2025-21204, exposing the system to symbolic link-based attacks. If the folder is accidentally deleted, reinstalling the update or temporarily enabling IIS features will restore it.

Conclusion

The INLINECODE11 folder's establishment as part of the Windows 11 April 2025 update is a strategic security enhancement to close dangerous symbolic link exploit paths in the update servicing process. However, its imperfect implementation introduced a new vulnerability that can be exploited by non-privileged local users to disrupt patch application.

By understanding the dual nature of the INLINECODE12 folder — both protector and potential attack vector — system administrators and users can take informed steps to safeguard their systems today while awaiting a permanent fix from Microsoft.

Maintaining rigorous folder permission settings and heeding Microsoft's guidance against deleting system folders like INLINECODE13 remain essential practices in securing Windows systems against evolving threats.