PHP 8.2.35

tuyuri

Versions: 8.2.35 8.3.36 8.4.27 8.5.12 Now are available in the php-src github

bombcar

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.

k1kingy

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

tux3

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...

charcircuit

https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0... What everyone is looking for.

ytxm

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

abbbi

debian trixie just rolled updates.

bstsb

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!

magar_fos

C'mon Ondřej..

andix

Does anyone know the ETA on the official php:* docker images? I think they only released patched 8.6 RC containers for now.

cowlevel

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?

baggy_trough

They bundled the fixes with a regular bugfix release, looks like.

janmo

apt-get update + apt-get upgrade fixes it on Debian, but not on Ubuntu for now

dmtroyer

Have we ever seen the "get ready for a security release tomorrow" email before? https://www.php.net/archive/2026.php#2026-10-20-1

nr378

Looks like a co-ordinated disclosure between Wiz, Calif and OpenAI: https://www.php2shell.com/ https://www.wiz.io/blog/php2shell-php-rce https://calif.io/php2shell/ https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live) https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)

nairboon

A bit too early for the announced coordinated release, no?

petecooper

>Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.

dataflow

Is PHP 7 essentially going to be dead and unusable for everyone then? Or will it get fixes?

joecool1029

Gentoo has it updated.

TekMol

Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution? The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?