2 PHP use-after-free flaws sat dormant for 22 years

The PHP use-after-free is a memory management flaw in the runtime's multipart request parser, not in a plugin or framework. It allowed remote code execution on affected builds, the code path ran before any PHP script executed, and the fix shipped in PHP 8.5.12.

What is the PHP use-after-free vulnerability?

The PHP use-after-free is a memory management flaw in PHP's runtime that allowed remote code execution through crafted multipart requests. A fatal but non-crashing parse failure frees a session structure while its global pointer stays live, and a second request writes through that dangling pointer, which the attacker can steer toward control of the process.

The flaw sits in the request handling layer rather than in an application. PHP, the Hypertext Preprocessor, parses multipart bodies and tracks upload progress against a session before application code loads. That placement is what makes the bug serious: sites running Laravel, Nextcloud, phpMyAdmin, Joomla, Drupal, or WordPress all depend on the same runtime underneath.

The researcher credited with the primary finding publishes under the handle LCFR, and the most detailed public write-up came from the security firm Khif. The exploit chain is described in two parts there: an allocator failure used to break an internal hash table, and a separate session upload progress path that reaches further back in version history.

Patch status is the part to verify yourself. Public posts in October 2026 reported that the ASAN build of the PHP 8.5.12 patch still produced a sanitizer violation, a double free, and one prominent researcher called the security fix incomplete and in need of further validation. Treat any single patch version as unconfirmed until the PHP project's own changelog and security announcements confirm it.

How the exploit chain works

The exploit runs in two requests, and neither needs a valid script endpoint behind it. The first request starts a file upload tied to a session; the parser then fails while mapping the multipart body into PHP's session globals. The failure is fatal enough to free the session structure, yet the global reference survives.

The second request resumes a multipart form upload and ends the file upload. PHP reads the freed session value and then destroys it, which means it writes into memory it no longer owns. That write into a dangling pointer is the use-after-free.

Turning that primitive into remote code execution is the hard part. The animation circulating alongside the disclosure, an anime character dancing over a successful exploit, compresses a much longer chain. The practical point is narrower: a memory-safety bug in PHP's request parser becomes a server-level problem, not a plugin-level one.

• Request 1 sends a multipart request with session upload progress enabled, with a deliberately failing parse.

• PHP frees the session structure while a global still references it.

• Request 2 sends a second multipart body that ends the upload and writes through the stale pointer.

• The write corrupts a target structure the attacker can shape into code execution.

Why a use-after-free becomes code execution

A use-after-free becomes code execution when two parts of a program interpret the same memory differently. One structure writes a value into a field, and another structure reads the same address as a function pointer and calls it. The attacker's control of the written value becomes control of execution.

A simplified way to see it is a struct holding an animal's name and a pointer to its speak function. When two structs of equal size sit over the same freed block, a write to one struct's name lands on the other struct's function pointer. That overlap turns memory reuse into a control-flow hijack.

That toy example understates the engineering required. Real exploitation requires crafting allocator behavior, defeating randomization, and building a read-write primitive before an indirect call is possible. The key takeaway is that a session handle, which most developers treat as inert data, sits close enough to the process's control structures to matter.

Why fuzzers missed it and models found it

Fuzzers search for spatial memory bugs, where a single input at a single moment drives a buffer past its bounds. The PHP use-after-free bug is temporal: the crash is defined by the order and divergence of two program states, one a fatal failure mid-operation. Coverage-guided fuzzing is not built to manufacture that pair.

The hunting method described in the disclosure ran the other way. A skill file documented the pattern found in PHP 7.3 and asked a language model to locate the same pattern elsewhere in the codebase. The model quickly located it in a different subsystem, the session upload progress handling, reaching back to older versions.

That method scales reasoning over invariants rather than over execution. A model can be asked whether a fatal error during fallible work can leave cleanup incomplete, then asked where. The cost is hallucinations and false positives, which is why the double-free report against the 8.5.12 patch matters: it is a claim that needs reproduction.

Which PHP versions and systems are affected

Confirmed disclosure material ties the bug back through multiple major release lines, with the earliest affected version reported as PHP 5.4.0. One account dates PHP 5.4.0 to July 2004, an unusual pairing that does not match the 2012 release date the PHP project's own release archive lists for that branch. The version boundary affects you; the age of the branch does not.

The practical rule is to inventory exact PHP versions per host instead of assuming one site equals one runtime. A shared host, container base image, or vendor appliance can run a runtime older than the application itself, and patch levels vary across each deployment.

Surface	Why it matters	What to check
PHP web application	The bug sits in built-in multipart handling	Exact PHP version and patch level
WordPress, Drupal, Joomla	PHP runtime underneath the CMS	Runtime version, not the CMS version
Docker base images	Same base image reused across services	Image tag and rebuild date
Hosting panels	Control is one or more layers away	Provider patch statement
Serverless and managed runtimes	Platform patches, users do not	Vendor advisory and runtime version pin

How to check and patch your stack

Confirm the exact PHP build on each host before acting. The disclosure points to PHP 8.5.12 as the release carrying a fix, but the pre-deployment check is the same either way: know what you are running and decide the support window explicitly.

1. Read the runtime version from the command line where you can.
2. Compare it against the security releases on the php.net download page.
3. Track every component that bundles PHP, including container images built by third parties.
4. Re-run your own memory tests if you run a hardened build; public reports of an incomplete fix in 8.5.12 have not been reconciled upstream.
5. Review request handling in front of your app. A reverse proxy that rejects malformed multipart bodies reduces exposure but does not replace a patched runtime.

Frequently asked questions about the PHP use-after-free

• Is the PHP use-after-free remotely exploitable? Yes. The vulnerable path parses network requests before application code runs, and public disclosure describes a route to remote code execution. The patch level in your exact build decides whether you are exposed.

• Does converting PHP to Rust prevent this bug class? It does, in principle. Rust's compile-time borrow checker catches use-after-free through ownership and reference counting, which covers this design flaw. A full PHP rewrite would carry its own costs, and no such migration is planned or announced.

• Does a WAF stop an exploit for this bug? It can help if it blocks malformed multipart bodies, but a patch is the direct fix. A WAF does not address memory safety inside the PHP process.

• Are plugins and content management systems the affected component? No. The flaw is in the PHP runtime's built-in multipart and session handling. A CMS or framework is affected only because it runs on the runtime.

• How current is this analysis? The public disclosure arrived in October 2026. Verify details you plan to rely on against the PHP project's own security announcements and the researcher's published write-up, because patch-status claims are moving.

Source video