Windows 11 24H2 Security Flaw: PowerShell Enforcement Bypass Explained

A security crisis with broad implications has emerged in recent months as Windows 11 24H2, the much-anticipated feature update, rolled out to users worldwide. Despite Microsoft’s assurances about the readiness and stability of this release, seasoned administrators and cybersecurity professionals have sounded the alarm over a significant flaw: the apparent breakdown of PowerShell script enforcement under AppLocker and Windows Defender Application Control (WDAC). This persistent issue, publicly discussed on platforms such as Stack Exchange and Reddit, exposes organizations to potentially unchecked script execution. The story, as it has unfolded, offers a revealing look at both the challenges of modern Windows deployment and the complex interplay between innovation and security within Microsoft’s ecosystem.

Understanding AppLocker and WDAC: Critical Layers of Security​

Before delving into the specifics of the 24H2 defect, it is essential to grasp the role of AppLocker and WDAC in Windows’ layered defense strategy.

• AppLocker: Introduced as a feature in Windows 7 and refined over successive versions, it allows administrators to define rules about which executable files, scripts, DLLs, and installers can run on managed endpoints. Organizations depend on AppLocker to strictly limit attack surfaces, particularly from malicious or unauthorized scripts.
• Windows Defender Application Control (WDAC): An evolution in application whitelisting, WDAC leverages code integrity policies, cryptographic signatures, and hardware-backed security to determine what software is trusted to run, including PowerShell scripts. WDAC is increasingly central to Microsoft’s “zero trust” approach in enterprise environments.

Both technologies are foundational to compliant, secure organizational IT, especially where regulatory requirements or high-value assets are at stake.

The 24H2 Update: Promises and Perils​

When Microsoft announced Windows 11 24H2’s general availability, it pointed to advancements in performance, reliability, and security. However, a growing number of reports highlight that the update came with substantial baggage:

• Upgrade-related bugs: Many organizations experienced deployment headaches, reporting that patch installations sometimes failed or caused configuration drift.
• System performance issues: Forums display widespread complaints about laggy UI, slow application launches, and unexplained CPU spikes post-upgrade.
• Potential data loss: Unconfirmed reports suggest that, during certain failed upgrades, user data might be at risk, raising concern among IT managers.

Yet, while these problems are disruptive, the AppLocker/WDAC bug stands out for its fundamental security implications.

Discovery of the Flaw: Community Vigilance Outpaces Official Response​

The first hints of the PowerShell enforcement problem emerged not from Microsoft’s documentation or patch notes, but directly from the field. According to posts on Stack Exchange, a user known as “CFou” noticed that PowerShell sessions—intended to be locked down by policy—were instead defaulting to FullLanguage mode, ignoring ConstrainedLanguage restrictions that are critical for prevention of script-based attacks.
Shortly thereafter, sysadmins discussed parallel observations in the r/sysadmin subreddit, with contributors confirming that even rigorously enforced AppLocker or WDAC configurations failed to limit PowerShell script behavior on 24H2 endpoints. This exposed systems to the risk that any script, regardless of provenance or content, might execute without oversight—a direct contradiction of enterprise security policy.

Timeline of Discovery​

Date	Community Event
Early 2024	“CFou” posts about AppLocker enforcement failure on Stack Exchange
Weeks following	Additional sysadmins confirm reproducibility on Reddit
Spring 2024	Microsoft MVP Roody Ooms provides deep technical analysis
June 2024	Microsoft acknowledges the flaw and proposes a fix

Technical Analysis: What Went Wrong Beneath the Hood?​

PowerShell script enforcement in Windows has, over the years, relied on API calls that communicate system lockdown states. For legacy implementations, PowerShell would invoke the WldpGetLockdownPolicy API, which returned relevant configuration for script control. This allowed AppLocker and WDAC to determine, at runtime, whether a PowerShell session needed to enforce ConstrainedLanguage mode—a crucial setting that disables most offensive scripting techniques.

The Breaking Change: A Shift to WldpCanExecuteFile​

With Windows 11 24H2 and newer versions of PowerShell (starting around 7.3), engineers introduced a transition to a new API: WldpCanExecuteFile. This function, in theory, should have provided more granular control and security context. However, according to research by Microsoft MVP Roody Ooms:

• The implementation of WldpCanExecuteFile in 24H2 was incomplete or incorrect, causing PowerShell to misread the lockdown status.
• As a result, PowerShell defaulted to FullLanguage mode, bypassing critical controls meant to block or restrict untrusted scripts.

This meant that, despite painstaking GPO configurations and enforcement efforts, organizations were left with an invisible vulnerability.

Verification and Acknowledgment​

Roody Ooms’ investigation, as detailed in his widely cited technical blog, methodically compares system behavior between Windows 11 23H2 and 24H2. The outcome is clear: only the latter version fails to respect AppLocker/WDAC script restrictions due to the API mishandling.
Subsequently, technical leaders and admins validated this finding across numerous enterprise environments, bolstering confidence in the diagnosis. Nevertheless, at the time of discovery, Microsoft had not yet publicly documented the bug in official release notes, risking slow or incomplete mitigation across its vast customer base.

Security Ramifications: Open Door for Attackers​

What does this mean in practice? The temporary loss of AppLocker/WDAC enforcement for PowerShell scripts is not merely an administrative inconvenience—it is a critical security lapse with real-world consequences.

• Privilege escalation: Attackers or rogue insiders could elevate privileges by running sophisticated scripts that would otherwise be suppressed or logged by AppLocker.
• Lateral movement: During a breach, malicious scripts could propagate across a network, unchecked, dramatically increasing the blast radius of any compromise.
• Malware deployment: Ransomware and other malware are often deployed via obfuscated PowerShell scripts specifically designed to evade detection—precisely the cases AppLocker was meant to stop.

For organizations under regulatory mandates—such as healthcare, finance, or public sector—this gap could also compromise compliance, potentially triggering audit failures or legal repercussions.

Microsoft’s Response: From Awareness to Remediation​

After extensive community reporting and press coverage, Microsoft acknowledged the flaw. In a notable development, PowerShell 7.6-preview.4—available as a public preview—implements a key corrective measure:

• Fallback to AppLocker: PowerShell now attempts to use WldpCanExecuteFile (the new API), but if this fails, it falls back to the older and still-reliable WldpGetLockdownPolicy API.
• Commit Reference: The fix is reflected in public changelogs and is tracked as issue #24912 in the official PowerShell repository.

This fallback mechanism effectively restores enforcement on affected systems, but final adoption depends upon both Microsoft shipping the fix in stable builds and organizations actually updating endpoints—an inherently slow process for large enterprises controlling upgrade timelines.

Clarity from Independent Sources​

Cross-referencing reporting from Neowin, Roody Ooms’ blog, and GitHub issue trackers, these events and technical details remain consistent and verifiable. However, as of press time, Microsoft’s own documentation on the issue is sparse, and the fix is only present in preview builds, not yet backported to released PowerShell or Windows 11 stable channels.

Broader Lessons: The Double-Edged Sword of Modernization​

This episode exemplifies the risks inherent in OS and platform modernization. Microsoft’s push toward agile updates and cloud-aligned frameworks has, on one hand, delivered rapid innovation and responsive security. On the other, even small missteps in critical integration points—like API changes in PowerShell—can ripple out to disrupt carefully maintained enterprise defenses.

Notable Strengths​

• Community vigilance: The ultimate discovery, analysis, and escalation of the bug demonstrate the strength of the Windows community—sysadmins, MVPs, and independent researchers remain a vital part of the platform’s resilience.
• Prompt engineering fixes: Once acknowledged, Microsoft shipped a preview fix quickly, reflecting some alignment with modern DevOps principles.
• Transparency through public code: The presence of PowerShell as an open-source project enables independent verification, fostering trust and accountability.

Ongoing Risks​

• Delayed propagation of fixes: Many production systems run deeply tested, stable channels and are not ready—or permitted—to deploy preview code. This delay extends vulnerability windows.
• Incomplete documentation: As of now, Microsoft’s mainstream channels (official support KBs, release notes) have not fully documented the defect or provided step-by-step mitigations. This leaves less-connected organizations at greater risk.
• Overreliance on automation: Many organizations trust security baselines (CIS, Microsoft Security Baselines) to be comprehensive and current. Hidden implementation bugs challenge this assumption and highlight the need for periodic, manual reviews.

Mitigation: What Should Organizations Do Now?​

While awaiting an official, broadly shipped fix, IT teams should consider several mitigations:

• Monitor for Updates: Track announcements related to PowerShell and Windows 11, especially for out-of-band security patches.
• Supplemental Controls: Employ endpoint detection and response (EDR) tooling to watch for suspicious PowerShell activity. Some EDR platforms can proactively detect scripts running in FullLanguage mode.
• Network Segmentation: Limit the scope of potential script abuse by restricting privileged account lateral movement within the network.
• Manual Policy Auditing: Manually verify that ConstrainedLanguage mode and AppLocker rules are enforced on critical endpoints following any OS update.
• Consider Version Hold: For high-value systems, delay upgrades to Windows 11 24H2 until the bug is fully resolved in production-ready code.

A Cautionary Tale: The Value of Defense in Depth​

The broken PowerShell enforcement issue in Windows 11 24H2 underscores a perennial truth in IT security—the importance of defense-in-depth and proactive monitoring. As reliable as any automation framework or policy engine might be, the possibility of silent failures exists, particularly in complex ecosystems like Windows.
Administrators should remember that:

• Trust, but verify: Automated controls are critical, but manual spot-checking remains irreplaceable for layered assurance.
• Change management: Testing updates in non-production environments, with explicit focus on key enforcement mechanisms, can catch issues before exposure widens.
• Engaged community: Participation and monitoring of forums, technical blogs, and issue trackers can provide early warnings that official channels may miss or delay.

Looking Forward: How Microsoft Can Rebuild Trust​

To repair confidence in Windows 11’s security for enterprises, Microsoft must do more than simply patch the immediate bug. The following strategies are essential:

• Full Disclosure: Provide detailed retrospectives on high-impact bugs, including timelines, affected configurations, and recommended user actions—not just terse patch notes.
• Channel Parity: Ship fixes consistently across preview, current, and long-term servicing branches to minimize risk disparity between early adopters and stability-focused enterprises.
• Strengthen Testing Pipelines: Prioritize integration testing for security-critical features like WDAC and AppLocker, simulating real-world enterprise deployment scenarios.

Conclusion: A Turning Point for Windows 11 Security?​

The months-long AppLocker and WDAC enforcement gap in Windows 11 24H2 represents both a moment of vulnerability and a testament to the power of the extended Windows community. While Microsoft’s swift engineering response is commendable, the lag in documentation and patch rollout spotlights systemic challenges in ensuring enterprise operating system integrity.
As organizations plan future migrations and policy updates, the lessons of this episode—trust but verify, diversify controls, and stay connected with both peer and vendor ecosystems—will remain as relevant as ever. For now, vigilance and collaboration stand as the best defense while Windows 11 continues its evolution in a complex, threat-rich landscape.

---

Source: Neowin Admins find Windows 11 24H2 PowerShell AppLocker/WDAC script enforcement broken for months