Updated PHP version released to GitHub

Advisories with the details are public:

https://github.com/php/php-src/security/advisories/GHSA-w8hw...

https://github.com/php/php-src/security/advisories/GHSA-6wmf...

Click the associated tag:

> This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Glorious. Today of all days it would genuinely give me pause for caution.

edit: yeah, really not feeling that: https://github.com/php/php-src/compare/php-8.2.34..php-8.2.3...

Hopefully just a mistake? But looks like a botched release at the least

Does anyone know how long it takes for the ondrej/php repo to be patched usually?

i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!

Versions: 8.2.35 8.3.36 8.4.27 8.5.12

Now are available in the php-src github

debian trixie just rolled updates.

So they've added malloc fail checks and tests for malloc fail throughout.

Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?

https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0...

What everyone is looking for.

C'mon Ondřej..

What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619)

1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching.

2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first.

3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php.

4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request.

5. Lower max_input_nesting_level and post_max_size, per the advisory.

6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.

[dead]

[dead]