PHP 8.2.35

Hetzner's control panels are PHP. And they're totally unresponsive. Perhaps people storming to manage their services or submit support requests.

Maybe Hetzner know a company that can help out with extra computer resource...? /s

Useless. My fault for paying peanuts

[dead]

[flagged]

[flagged]

For anyone who can't patch their PHP for some reason, here is a proxy that eliminates the threat for you -- it's open source, you can add it to your servers:

https://news.ycombinator.com/item?id=50181752

https://github.com/Qbix/proxy -- open source MIT licensed, I made github actions compile it as a Cosmopolitan binary so it can work across many operating systems (thanks Justine)

I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)

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.

C'mon Ondřej..

PHP is done.

If you're tired of having to upgrade Wordpress, point your agent at this tutorial:

https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...

So-- if PHP's sourcecode was unavailable (closed source), would this ever have been found? Probably not. Maybe it is safer to be closed source.

Does anyone use PHP anymore? I assumed it was abandonware

Can't we fingerprint the code in github and elsewhere and tell AI labs to not do security reviews on the code unless (A) someone is a legitimate security researcher or (B) someone is the owner of the code.

Yeah it sucks, but the alternative could be worse.