PHP's Memory Bug Had Fixes Long Before It Had a Decision

On October 21, PHP shipped emergency releases for every version it still maintains. PHP is the programming language underneath roughly seven in ten websites whose server language can be identified, so "every version" covers a large share of the web's plumbing.

One of the two critical flaws lived in an unglamorous place: what PHP does when it runs out of memory. An attacker could send a file upload chopped into many small pieces, arranged so that PHP hit its memory cap partway through updating its own internal records. The cleanup code that ran next then read records only half written. On servers running PHP inside the Apache web server, the advisory says, this let an anonymous outsider run code before the website's own code had even started.

The bug was not new. According to the PHP Foundation's retrospective, it surfaced while a developer was fixing a finding from a 2024 security audit, and then it sat. The Foundation's own verdict is blunt:

The Foundation's list of possible fixes shows why. There were three. The first would break some existing websites. The second would give attackers a new way to crash servers. The third required changes to many extensions, the add-on modules that outside developers plug directly into PHP's internals, and nobody believed those developers could be coordinated. Each would have repaired the bug and sent the bill somewhere different: to site owners, server operators or extension maintainers. The handful of specialists able to weigh those costs had other jobs, and the team worked by consensus, which kept faltering over the fear of choosing wrong. Work stopped and restarted repeatedly.

The reforms the Foundation now proposes are all ways of ending an argument: majority votes, open acceptance of compromise, earlier escalation of stuck problems to leadership. The project had people who could write a fix, but no dependable way to settle who should absorb its cost.

The fix that finally shipped has a cost of its own. PHP's memory_limit setting becomes a soft ceiling, and a second, higher hard limit now kills the process outright, skipping the cleanup and error reporting a script would normally get. The same day, a proposed change noted that PHP's XML parser, when built with the widely used Expat library, could now hit that wall and stop dead where it previously reported an ordinary error. That doesn't make the repair wrong. It does mean that software built on PHP inherits its compromises, including ones nobody documented.

Then the repair had to travel, and it splintered along the way. Ubuntu stitched the fix into the older PHP versions it already ships; Red Hat adopted PHP's own new release. For versions PHP no longer supports, the project posted minimal patches that handle running out of memory in yet another way. Even the timing was disputed. Chainguard, a company that sells prebuilt software packages, shipped fixes more than six hours early, citing attack attempts; the Foundation argued that releasing early let attackers study the repair before others could install it. These notices show that a patch existed, not whether a given server applied it.

Elizabeth Barron, the Foundation's only full-time employee, told Reuters that it otherwise relies on 14 contractors, most of them part-time. Reuters reports that proposed code changes have nearly doubled in a year. "Yet the number of contributors hasn't doubled," she said. Reuters gives no figure for how much of that surge, if any, comes from AI tools. The memory bug had candidate fixes all along; what held it up was deciding which group would pay, and having enough specialists to turn that decision into a shipped repair. Whatever their origin, more proposals only add to what those same few people have to get through.