On Tuesday, two numbers started going around online, a pair of CVE IDs for PHP, with the wrong score and the wrong release time attached. Within a day, every supported version of PHP had an emergency release out, a day ahead of schedule, and by the release, government websites in four countries had gone dark on purpose. A bug first glimpsed in 2024, that nobody could prove was exploitable, until a few months ago, somebody did.
Hello world, it's Thursday, October 22, 2026, and here's what happened This Week in PHP Internals. There was no episode last week. I was in Austin for Longhorn PHP, and it never got recorded, so I'm sorry about that. This one covers both weeks. 18 stories, so let's get into it. But first,
What does your team pay every month to get a PDF signed, or to keep every app's logs somewhere you can search them? Scalpels replaces subscriptions like those with open source apps you host yourself. The catalog is up to 13, and two are new since our last episode: Witness, for e-signatures, and Wake, a central log sink for your Laravel apps. Each app is forked into your GitHub organization and deployed to your own Laravel Cloud account, so your data never leaves your infrastructure. The apps are open source, and resources scale to zero by default. And the platform that manages it all is one lifetime purchase, not another subscription. It launches October 31st, at scalpels.app.
Security Release (01:45)
This week's top story is two critical vulnerabilities in PHP itself, both rated 9.2, that let an attacker run code on your server without ever logging in. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix them, and they shipped Wednesday, a day early. And here's the part that matters before any of the engine detail: this is not theoretical.
Calif, who found it, says it sent the PHP team a working exploit back in August, and the team confirmed it ran. The GitHub advisory for the first bug says that complete remote code execution "was validated over HTTP against mod_php with default PHP input and memory limits …" Default limits. No login.
So the only real fix is to update. Distributions got the patches ahead of time, so check your vendor. If you're on 8.1 or older there's no release for you, just source backports for 7.4, 8.0 and 8.1. PHP's own advisory on php.net lists some stopgaps if you genuinely can't patch today, but it's blunt about them: they reduce your exposure, they don't make you safe.
Links: PHP security advisory · CVE-2026-109618 advisory · CVE-2026-109619 advisory · downloads
How It Breaks (03:09)
Both bugs live in the parts of PHP that nearly every request runs through: memory management and error handling. The Foundation says that's exactly why they're so dangerous, and why they were so hard to fix.
When PHP hits its memory limit, it has always stopped the request with a C trick called a long jump: it leaps straight back out to a safe point and abandons every function it was in the middle of. The problem is when that can fire. In a few spots, PHP has set some request data up but not finished wiring it together, and if the memory runs out right there, the long jump bails out and leaves that half-built data behind. Then cleanup comes along and trusts it. PHP's advisory: request cleanup "may then treat the invalid data as valid."
Now the second bug. A PHP worker handles one request after another, and some internal state is supposed to be wiped between them. A fatal error at the wrong moment can skip that wipe, leaving a pointer aimed at the request that just finished. That request's memory gets freed, the next request lands on the same worker, and it reads the stale pointer before anything resets it. On 8.5 the clearest example is the backtrace PHP saves for a fatal error, which is on by default; the other is session upload progress, also on by default. The team says that first one is the basis of the confirmed attack on mod_php.
Links: Calif's write-up · Wiz Research's write-up
The Fix (04:46)
The fix is a single commit, pushed to every branch, with a blunt title: "Avoid state corruption via bailout." Arnaud Le Blanc wrote it, with Ilija Tovilo, Jakub Zelenka, Nora Dossche and Nicolas Grekas. And it is enormous — 389 files and around 249 new tests.
The heart of it is this: PHP stops jumping out of an out-of-memory error. When you cross the normal memory limit now, it doesn't bail mid-operation; it raises a flag, finishes what it's safely doing, and reports the error at the next safe point, so cleanup never sees half-built data. There's a second, higher ceiling as a backstop — a hard limit — and if you somehow blow past that, PHP exits the process on the spot rather than risk running over bad memory. That hard limit is a new setting, memory_hard_limit_percent.
For the stale-state bug, the patch resets those worker globals early, before the next request can reach them, and makes session upload progress do its work without waking up any of your objects. And that's why this touches 389 files. Once an out-of-memory can be handled gracefully instead of jumping out, an allocation is allowed to simply fail and return nothing — so every corner of the engine that allocates memory had to be taught to check for that and back out cleanly. A narrow bug, a codebase-wide fix. That's the shape of a problem that sat unsolved since 2024.
Links: the fix commit · PHP 8.6.0 RC4
Leak Timeline (06:32)
Here's how it got out. The Foundation says the memory bug first surfaced in that 2024 external audit, but with no known way to exploit it, the fix stalled for months over hard trade-offs. About that delay, the Foundation didn't hedge: "We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."
What changed is that in August, the security firm Calif, auditing PHP through OpenAI's "Patch the Planet" program, reported a working remote code execution with that same root cause — and OpenAI reported it independently the same day. Suddenly it wasn't theoretical.
Then, on Tuesday, the two CVE numbers leaked online, with the wrong release time and a wrong score of 10. The Foundation says no technical details leaked with them, but the PHP project moved the release up a day anyway, and not sooner, because distributions were still packaging the fix. Soon after, Calif accidentally posted a video of its exploit running against a number of targets, then took it down — but copies were already spreading. And on Wednesday morning, six hours before the release, the Foundation says Chainguard broke the embargo and shipped patched images, letting anyone diff the binaries for the fix while everyone else was still waiting.
Links: the PHP Foundation's account · the pre-announcement · OpenAI's disclosure post
Sites Go Dark (08:10)
And this is where it stops being an engine story and starts being a news story. As the patch landed, governments took some of their own websites offline rather than serve them unpatched. Finland's state IT centre started pulling public services down. France's Interior Ministry said its prefecture sites were temporarily offline pending the patch. The Dutch national cyber agency took down its own website. And Canada's AI minister, Evan Solomon, said some federal sites went dark as, in his words, a "precautionary measure."
That's the thread running through this whole story: the exploit is proven, and with the patch out, the fix itself shows where to look.
Now, the one honest caveat. When Chainguard shipped early, its CEO Dan Lorenc said, "I made the call to get these out early when exploits hit in the wild." Others dispute that there ever were working exploits at release. Nils Adermann, who runs Packagist, replied flatly: "This is false. There were no confirmed exploits. All that was reported … was people probing, trying to exploit." The PHP team says the same — it watched for working exploits after the leak and didn't find any at release, and the US agency CISA says it hadn't seen any either. So: the capability is real and proven, the recipe is now out in the open, and neither the PHP team nor CISA had confirmed a break-in yet. Which is exactly the window the patch is for. Update your PHP.
Links: CNBC · CBC · The Register · CISA alert
CSV Extension (09:52)
Now, the week we missed, starting with a CSV extension for PHP core, and a debate over whether PHP needs one. PHP 8.6 deprecates the CSV methods on SplFileObject, and the RFC that did it said future work would be better served by a dedicated extension. Damian Jóźwiak's new RFC is that extension, built on Gina Peter Banyard's CSV extension: 6 functions and a lazy collection in a Csv namespace. It follows RFC 4180 by default, with no escape character, no dependence on your locale, and multibyte delimiters. Lynn asked for support for streams that are already open, and Damian plans entry points for them.
Then Artem Ukrainskiy went through the RFC's list of things it says can't be fixed without breaking compatibility, and argued each one can be, in the functions PHP already has. He says the new branch is in good shape, and now faster than fgetcsv in his benchmarks. He wrote: "My concern is the long-term maintenance cost of introducing a second parser when the existing one can be improved incrementally."
Damian agreed the RFC's claim was too broad. He pointed to the new DOM API and the URI extension as precedent for a new API beside an old one. Then he laid out 3 directions: improve the existing functions, keep the dedicated extension, or rework it as an object-oriented API. He still prefers a dedicated API, and asked whether a directional vote would help. The thread has been quiet since, and no vote has been called.
Links: CSV extension RFC · thread · implementation · Artem's locale fix · Artem's benchmarks
JSON Comments (11:37)
Your tsconfig.json and your VS Code settings can have comments in them, and json_decode won't read them. Otar Chekurishvili's new RFC adds two opt-in flags, one for comments and one for trailing commas. They work in json_decode and json_validate, strict JSON stays the default, and each flag gets its own vote.
Back in September, Tim Düsterhus asked for a single JSONC flag instead. The RFC keeps two, because the JSONC spec is still a draft, and it makes trailing commas optional. It also points out that Chromium's JSON reader uses the same two flag names. Tim replied: "I'm not happy, but the rejected [alternative] is well-argued." He also called the RFC "incredibly well-written", and Larry Garfield wrote: "I am forced to agree with Tim. This is a very tight RFC, and I have no remaining objections to it."
Links: JSON comments and trailing commas RFC · thread · implementation
Bcrypt SHA256 (12:37)
The fix for bcrypt's 72-byte limit, from our last episode, got its first challenge: who vouches for it? Mirco Babin said Passlib, the Python library it's borrowed from, isn't a trusted source for security, and asked where bcrypt-sha256 is specified. He also asked about C# and JavaScript apps sharing the database, and said it goes against OWASP's guidance. OWASP's cheat sheet pre-hashes with a secret pepper kept out of the database, where the RFC keys its HMAC with the salt.
Sjoerd Langkemper asked for a standardized alternative, noting PBKDF2 is a NIST standard, but generally seen as less secure than bcrypt. Mirco has no plans to write an RFC. Rowan Tommins looked up the attack OWASP guards against, password shucking, which needs the same inner hash for the same user somewhere else. He wrote: "To put it another way, the salt in the proposal's HMAC is essentially doing the same thing as the pepper in the OWASP suggestion - making it sufficiently unlikely that an attacker can find the exact inner hash they need somewhere else." Rowan also noticed the same OWASP page recommends a 72-byte maximum, which is what Sjoerd's first RFC proposed. He wrote: "Even an expert opinion is just an opinion, of course, but it does mean we're going in circles a bit."
Andrey Andreev, who says he's been working on an alternative for weeks, asked for time before another RFC moves ahead. He hoped to post it soon. Nothing yet.
Links: PASSWORD_BCRYPT_SHA256 RFC · thread · OWASP on pre-hashing with bcrypt
Single Binary (14:14)
If PHP ships as one binary for your scripts and for FPM, which half should be in charge? In the week we missed, the answer flipped, and then drew pushback. As we covered last time, Nicolas Grekas and Jakub Zelenka argued the FPM binary should carry the CLI, the way FrankenPHP does. Matthieu Napoli agreed and rewrote the RFC. Now php-fpm includes the CLI and runs as the CLI when it's invoked under the name php, with no build option and no --fpm flag.
Tim Düsterhus disagreed. He says a binary that changes behaviour based on its name is hard to discover, and naming a symlink wrong could suddenly start FPM and bind a port. He'd rather have an explicit php --fpm, the way -S starts the built-in web server. Marc Henderkes agreed with Tim, and doesn't see FrankenPHP replacing FPM any time soon. He wrote: "There has to remain a way to run php without locking ourselves to Go (and realistically Caddy)." And Levi Morrison floated a third option: a shared libzend.so engine library, which PHP could build in the past.
Links: single binary RFC · thread · implementation
PEAR Sunset (15:36)
Back to this week. PHP has voted to stop endorsing PEAR. Nick S.'s RFC closed Monday at 40 to nothing, with no abstentions. The static archive stays up until the end of 2027, and Sebastian Bergmann, who maintains PHPUnit, pointed out that it keeps serving executable code from php.net until then. He wrote: "This includes go-pear.phar, the file that was replaced with a malicious copy in January 2019."
He suggested a signed list of SHA-256 hashes for every file in the archive, and pinning the hash of the installer that PHP's build downloads and runs when you configure it with PEAR. Before the cut-off, he'd plan brown-outs, so forgotten automation fails early, before the final shutdown. After it, a tombstone PHAR that explains what happened, instead of a plain 404. PHPUnit did the same before its own PEAR server shut down.
Links: End PEAR Project Endorsement RFC · result · Sebastian Bergmann's suggestions
Votes (16:35)
Three votes this week, with three very different scores. Weilin Du's IntlRelativeDateTimeFormatter closed at 25 to nothing, and it's already merged for PHP 8.7. Sjoerd Langkemper's RFC to make hexdec, octdec, bindec and base_convert throw on invalid characters is at 22 to 1, and it closes November 1st.
The one no is CHU Zhaowei's, only because the RFC throws a plain Exception, which you can only catch along with every other exception. He pointed out that the 2019 RFC planned an InvalidArgumentException. Sjoerd replied that a generic exception can become more specific later, and that InvalidArgumentException signals a programming error, when bad input here might just be user input.
And Muhammed Arshid's Filter enums RFC is at 1 to 10, closing November 4th. Tim, one of the no votes, argued two weeks ago that combining the flags as a bitmask turns them into fancy constants. Muhammed replied that many use cases only need a filter, without any flags. Tim's worry is that adding the enums now would likely block a design based on tagged unions later.
Links: IntlRelativeDateTimeFormatter RFC · merged · number base RFC · CHU Zhaowei's no · Filter enums RFC · tagged unions RFC
PDO Binary (17:52)
PDO drivers handle binary data inconsistently. Calvin Buckley, one of the 8.4 release managers, has an RFC to make it explicit. It offers two shapes: a new PARAM_BINARY type, or a binary flag you combine with strings and large objects. Calvin says a user asked him that very morning about an ODBC quirk that needed a bin2hex workaround.
Ilia went through the RFC against the actual drivers. PARAM_LOB with a string is already binary in some of them, so he asked what the new constant adds, driver by driver. He wrote that "Neither representation degrades safely": a driver that doesn't know the new type falls back to text in some places, and to a fatal error in the SQL Server driver. He also called the ODBC case a driver issue that can be fixed without a new constant. Calvin plans a per-driver table, and is open to making PARAM_LOB consistent instead, if that's what people prefer.
Links: PDO binary RFC · implementation · thread
SSRF in curl (18:56)
If your app fetches URLs your users give it, someone can point it at your own server or your internal network. That's server-side request forgery, and Sjoerd Langkemper reopened the question of how curl should let you block it.
Xavier Leune has two pull requests. One exposes curl's own socket callbacks, which hands a socket to userland, and the other adds a pre-connect hook that only PHP would have. The current plan is narrower: just CURLOPT_OPENSOCKETFUNCTION, with a callback that gets the address and port and returns a boolean. Xavier said that may be a good idea. He's building it as an extension first, as a polyfill for older PHP versions, and he'll follow whatever API the list agrees on for PHP 8.7.
Links: thread · PR #22159 · PR #23657 · Xavier Leune's extension
Quick Hits (19:45)
Quick hits, from both weeks. Máté Kocsis answered Tim Düsterhus's 14-point review of the query parameters RFC. He's open to dropping the length limit, fine with renaming list to toList, and prefers parseWhatWgUrlSearchParams, even if it's somewhat verbose.
Links: query parameters RFC · Máté's reply
Tim sent 15 more points on Jakub Zelenka's polling additions, agreeing with Ilia that they should be voted on separately.
Links: Polling API Additions RFC
Marc still finds getNanoseconds on Time\Instant ambiguous, and suggests getNanoOfSecond.
Links: Time\Instant RFC
Tim backs David Carlier's IntlNumberFormatter, and would deprecate the old NumberFormatter later.
Links: IntlNumberFormatter discussion · GH-24165
Juliette Reinders Folmer is writing up the b prefix deprecation for the 8.7 bulk deprecations RFC.
Links: 8.7 deprecations RFC
Weilin Du's new RFC lets ini_get_all accept extension names in any case, the way extension_loaded already does.
Links: ini_get_all RFC
Frode Børli wants wiki karma for an RFC called Scope, so superglobals, the timezone and the locale can follow each request in long-running servers like FrankenPHP.
Links: Scope RFC draft · karma request
PHP 8.6's fourth release candidate is out with the security fixes, and RC5 is due November 5th.
Links: RC4 announcement
The security release slowed the list, too. Pratik Bhujel planned to open the Io\Terminal vote this Friday, and Tim Düsterhus replied: "Large parts of the core team have been busy in the past week(s) due to today's security release. I assume not everyone has been able to catch up with RFCs in that time …" Pratik is holding the vote until things settle.
Links: Io\Terminal RFC · Tim's reply
TL;DR (21:31)
So that's two weeks. Two critical vulnerabilities in PHP got an emergency release a day early after their CVE numbers leaked, and some governments took their own sites offline until they could patch. If you haven't updated yet, do it today.
From the week we missed: a CSV extension for core met a review that says to fix the old functions instead, an RFC to allow comments in JSON was called incredibly well-written, the bcrypt-sha256 RFC was challenged over OWASP's guidance, and the single binary flipped and drew pushback. And this week, PHP voted 40 to nothing to stop endorsing PEAR. Links below.
The PHP Foundation funds more than half of ongoing php-src commits, so if you use the language, maybe consider donating at opencollective.com/phpfoundation — or try guilting your employer into it.
If you found this useful, a like or a comment helps more people find it. And if you missed our last episode, where the fix for bcrypt's 72-byte limit was borrowed from a Python password library, that's a good one to watch next. Thanks again to Scalpels.app for supporting this week's episode. We're Artisan Build. See you next week.
