--- title: "PHP's Memory Bug Had Fixes Long Before It Had a Decision" canonical: "https://current.tinyfish.ai/issue/53/practitioners-corner/article/57552/phps-memory-bug-had-fixes-long-before-it" publication: "TinyFish" publisher: "TinyFish" language: "en-US" guide: "https://current.tinyfish.ai/llms.txt" format: "Feature Essay" author: "Sevda Polat" author_url: "https://current.tinyfish.ai/team/200" issue: 53 section: "practitioners-corner" section_name: "Practitioner's Corner" published: 2026-10-30 description: "PHP's emergency releases show what shared infrastructure is shortest on: a way to decide which downstream group pays for a fix, and people to deliver it." word_count: 788 source_links: 13 --- # PHP's Memory Bug Had Fixes Long Before It Had a Decision *By [Sevda Polat]()* *October 30, 2026* [Read on the website]() On October 21, PHP shipped [emergency releases](https://www.php.net/archive/2026.php) for every version it still maintains. PHP is the programming language underneath roughly [seven in ten websites](https://w3techs.com/technologies/details/pl-php) 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](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) 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](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/), 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 delay was a structural failure, caused by both the security team's decision process and its lack of resources." 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](https://www.php.net/manual/en/ini.core.php#ini.memory-hard-limit-percent) now kills the process outright, skipping the cleanup and error reporting a script would normally get. The same day, a [proposed change](https://github.com/php/php-src/pull/24516) 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](https://ubuntu.com/security/notices/USN-8948-1) it already ships; Red Hat adopted [PHP's own new release](https://access.redhat.com/errata/RHSA-2026:87070). 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](https://therecord.media/php-foundation-statement-critical-vulnerabilities) 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](https://www.streetinsider.com/Reuters/PHP%2BFoundation%2Bunder-funded%2Bwith%2Bone%2Bfull-time%2Bstaff%2Bmember,%2Bdirector%2Bsays%C2%A0/27228741.html) 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. ## Things to follow up on... - **Who settles security disagreements:** PHP's [Working Groups RFC](https://wiki.php.net/rfc/working_groups) says internal security processes were insufficiently defined and sometimes confused release managers, and its proposed Security Working Group is still marked "Under Discussion." - **The residency clock runs:** In May the Foundation [announced an Ecosystem Security Team](https://thephp.foundation/blog/2026/05/18/announcing-ecosystem-security-team/) with a six-month, Alpha-Omega-funded engineer-in-residence post for Volker Dusch that included producing a sustainability plan, so the end of that term and what follows it are worth watching. - **The Expat fix's fate:** The [pull request making Expat allocators fallible](https://github.com/php/php-src/pull/24516) had approval on October 23 but remained open, which leaves open whether the hard limit's side effects get repaired one extension at a time. - **PHP 8.2's approaching cutoff:** PHP's [supported-versions schedule](https://www.php.net/supported-versions.php) ends security fixes for the 8.2 branch on December 31, 2026, so the next emergency could reach many installations only through vendor backports. ## More - [Practitioner's Corner — Issue 53]() - [Issue 53]() - [Publication guide]()