The PHP project quietly shipped a high-severity fix for a memory corruption bug in its March 2025 updates, and Windows administrators running PHP 8.3 or 8.4 need to act fast. CVE-2024-11235—a use-after-free vulnerability in the interpreter’s shutdown sequence—can be exploited remotely without authentication to crash web services or, under the right memory conditions, achieve remote code execution. Microsoft itself flagged the issue in its Security Response Center after confirming the bug’s presence in Azure Linux, but the vulnerability hits every PHP build on every platform.

The vulnerability at a glance

The core of CVE-2024-11235 lies in how PHP handles object destruction and memory cleanup when exceptions interrupt a request. If an attacker can trigger a magic property assignment (using __set()) that throws an exception, followed by a null coalescing assignment (??=), the PHP engine may free variables prematurely during the exception unwind. Later, during php_request_shutdown, reference counting operations access that freed memory—a classic use-after-free situation.

In technical terms, cleanup_live_vars can release memory that zend_gc_refcount and zend_gc_delref still try to read or write. Because PHP’s memory allocator stores metadata inside freed chunks, an attacker who can carefully shape the heap might overwrite function pointers or other control structures. That worst-case scenario makes reliable remote code execution plausible, though public proof-of-concept exploits at the time of writing focus almost exclusively on achieving denial-of-service crashes.

Who is affected

The vulnerability is confirmed in:

  • PHP 8.3.x before 8.3.19
  • PHP 8.4.x before 8.4.5

Any Windows system running these versions—whether through a WAMP/XAMPP stack, a manual IIS deployment, or a containerized setup—is exposed. Linux distributions, including Microsoft’s own Azure Linux, received patched packages shortly after the upstream fix, but Windows users rely on the official binaries from php.net or on manually compiled sources.

What this means for your Windows environment

For everyday users running a local PHP test server through XAMPP or similar tools, the immediate risk is low unless the server is exposed to the internet. Still, outdated local builds can become a stepping stone for attackers who gain internal network access later.

Production environments are a different story. IIS-hosted PHP applications, API backends, or any public-facing PHP service can be crashed at will by sending crafted requests. Repeated crashes lead to service disruption, thread exhaustion, and operational noise that masks deeper intrusions. Even without full remote code execution, the availability impact alone justifies urgent action.

If you use Azure Linux or any other Microsoft-managed VM that includes PHP, Microsoft’s own advisory recommends updating promptly. However, the MSRC note clarifies that the CVE publication there stems from Azure Linux’s adoption of the open-source library, not from any Windows-specific component. The fix must come from PHP itself.

How the bug was found and fixed

PHP developers identified the flaw during internal code review and released patched versions 8.3.19 and 8.4.5 on March 13, 2025. Details were backfilled into the PHP security advisory system and picked up by vulnerability databases like OpenCVE and Snyk. Microsoft added it to its own database on March 17, emphasizing Azure Linux customers should apply updates.

Notably, the trigger—combining magic methods, exceptions, and the ??= operator—is not an obscure edge case. Modern PHP frameworks and ORMs frequently use property overloading and the null coalescing assignment operator. The attack surface is broad, which is why multiple trackers assign a high or critical severity score despite the theoretical nature of RCE.

Immediate steps for Windows admins

1. Audit every PHP instance

Use the command line to check versions across all servers. PowerShell can iterate through remote hosts:

Invoke-Command -ComputerName (Get-Content servers.txt) -ScriptBlock { php -v }

Don’t forget build agents, CI/CD pipelines, or any tooling that embeds PHP—Composer-based orchestration often pulls its own PHP engine.

2. Download and deploy patched binaries

Visit windows.php.net and grab the latest 8.3.19 or 8.4.5 (or higher) release. Replace the old PHP directory entirely rather than patching individual files. If you use IIS, ensure the FastCGI module points to the new php-cgi.exe. Restart the application pool.

For WAMP/XAMPP installations, the vendor usually provides updated packages within days. Check Bitnami, WampServer, or XAMPP official sites for repackages that include PHP 8.3.19+.

3. Harden while you upgrade

If you can’t patch immediately, reduce exposure:

  • Limit inbound traffic to PHP endpoints with IIS IP restrictions or a perimeter firewall.
  • Enable IIS request filtering to block overly long or malformed inputs.
  • Set up process recycling to mitigate crash-based DoS—set a rapid failure limit so IIS gracefully restarts the worker process.

4. Monitor for suspicious activity

Look for:

  • Frequent application pool recycles logged in the Windows Event Viewer under System.
  • Core dumps or PHP crash files in the C:\PHP\temp or custom temp directory.
  • Web server logs showing repeated 500 errors or abnormally long response times from PHP pages.

If you run any form of web application firewall or endpoint detection, tune rules to flag repeated crashes and heap corruption signatures.

5. Test the fix in a staging environment

Recreate the vulnerable pattern from public advisories in an isolated test lab to confirm the update resolves the crash. A simple PHP script that throws an exception inside __set() while using ??= should no longer lead to a process crash after updating.

The Microsoft connection

Microsoft’s involvement through the MSRC advisory might confuse Windows administrators into thinking a Windows Update or a Microsoft-specific patch is coming. That is not the case. The company’s advisory (linked below) exists because Azure Linux ships PHP, and Microsoft is transparent about CVEs in included open-source libraries. The actual fix remains upstream, so the remediation path for Windows users is the same as for any other platform: get the updated PHP binaries from the PHP project.

What Microsoft’s advisory does signal is the seriousness of the bug. If the company that maintains one of the largest cloud ecosystems treats a third-party library vulnerability as worth a dedicated CVE entry, it’s not something to ignore.

What to watch next

No public weaponized exploit has surfaced in the wild, but the technical ingredients are well documented. Researchers have shared crash PoCs, and the step from a crash to code execution in a use-after-free scenario depends on how much effort an attacker invests. Given PHP’s ubiquity in web hosting and CMS platforms, a reliable RCE exploit would be a valuable commodity.

Windows administrators should treat the window between disclosure and exploitation as narrow. If your business runs WordPress, Drupal, or any custom PHP application on Windows, the update should be a top priority this week.