This Week in PHP Internals | Nov 5, 2026

Hello world, it is Thursday, November 5, 2026, and here is what transpired This Week in PHP Internals. This year, the FrankenPHP project patched a session ID leak, a use-after-free, and a double free, all arising from state not reset between requests. The engine struggles to determine when a request concludes if the same script serves the next one.

The endeavor aims to modify this. Today, AI streamlines software creation while complicating ownership. Scalpels automates the installation of open-source apps into Laravel Cloud or Forge accounts, ensuring data remains within the user's infrastructure. A zero-dollar free plan is available, with new Laravel Cloud accounts receiving ten dollars in credit. Access at scalpels.app.

In corrections from last week, Tim Düsterhus clarified a few points: the CSV extension did not wait for Damian's request, the security release had already occurred, and he suggested waiting before patching servers. Rowan Tommins questioned the proposal of extension methods without parentheses, as they were yet to exist. Two corrections were noted in last week's top story and quick hits.

Brian Nguyen's statement about not deprecating the integer meant the (integer) cast, which PHP had deprecated. Additionally, Sjoerd Langkemper clarified that he proposed the openssl_get_channel_binding, not Brian Nguyen.

This week's top story discusses Kévin Dunglas' proposal for PHP's engine to recognize request endings. In worker mode, one long-running script handles requests consecutively, retaining components such as the Composer autoloader and framework services in memory. Symfony, Laravel, and Yii support this natively, but the engine lacks awareness, leading FrankenPHP to reset each request's leftovers by accessing PHP's internals, which he considers fragile.

Kévin suggested implementing two optional hooks, request end and request begin, executed between requests, allowing extensions to reset their state. Servers not invoking these hooks would remain unchanged. Kévin explained that a scope provides a request with an identity but lacks a clear end. Request begin would initiate the scope, while request end triggers when the response is complete, regardless of the scope's persistence. He noted that user-space and engine-space lifetimes align because the SAPI manages both.

The Bcrypt RFC update addressed the fact that bcrypt only analyzes the initial 72 bytes of a password, leading to two RFCs to rectify the issue. Andrey Andreev introduced the second RFC, the alternative he requested to accommodate time for completion. PASSWORD_BCRYPT_WRAP hashes the password initially, using cSHAKE256 by default or HMAC-SHA512, before running bcrypt on the outcome.

This modification eliminates bcrypt's length and null byte limitations. Kamil Tekiela argued that this approach reduces bcrypt's input space and is susceptible to hash shucking. Andrey countered that a prehash does not diminish bcrypt's security or input space, and that his salts isolate the prehash from the plain hash. Tim Düsterhus requested pseudo-code to resolve the matter, which Andrey incorporated into the RFC on Monday.

Sjoerd Langkemper compared the two RFCs, favoring Sjoerd's due to its streamlined codebase, using the same algorithm as Python's passlib. Both Sjoerd and Andrey agreed on the RFCs' security, but Sjoerd expressed disappointment at having two similar RFCs to vote on separately, fearing an undesirable outcome. Larry Garfield supported Frode Børli's Scope RFC, but expressed concern that a new scope would start with empty superglobals, causing legacy functions to malfunction.

He suggested cloning the parent scope for new scopes or creating a Scoped attribute to automate the process. He also anticipated that developers would manually implement WeakMap to preserve scope-specific state and proposed using Scoped to streamline this process. Rowan Tommins commended the concise RFC, shared his concerns about the WeakMap, and inquired if "context" would be a more suitable term.

Frode Børli maintained the name Scope, acknowledging that the WeakMap pattern might require some getting used to but is not overly complex. He had not yet responded to Larry's query.