Security advisory: Critical remote code execution vulnerabilities, update now (php.net)

It seems the published exploit can be easily prevented by filtering out multipart post requests. So people actively watching the situation can already prevent that issue by filtering those.

There are so many keeping old php versions alive for compatibility with whatever software

https://ubuntu.com/security/CVE-2026-109618

  $ docker pull php:8.4.27
  8.4.27: Pulling from library/php
  no matching manifest for linux/arm64/v8 in the manifest list entries
  
  $ docker pull --platform linux/amd64 php:8.4.27
  8.4.27: Pulling from library/php
  no matching manifest for linux/amd64 in the manifest list entries

Seriously though. I don’t know what’s best. Taking everything down or not.. I just run a small time SaaS.

This is something of a fallacy. "The Industry" cannot learn.

But laws and regulations can require better security.

As in the history of seatbelts in vehicles, tech tool stacks are insecure by design and no one is ever really held accountable... until the cost is deemed too high.

It's evident that we have not reached that limit yet.

The vulnerability and patch are both very complex, and the maintainers did an incredible job on this one. We tested the patch extensively and it's holding up well.

We've made these images free and will keep them that way.

why it would be a thing, beyond "serious problem"?

Measuring “worst” is hard.

What else do you expect them to do? Pray?

Switching something off is far preferably over being hacked.

We don't really need it anymore now that we have LLMs.

But created my own based on it since it feels sketchy running someone else's exploit poc ya know. Ran it first in a vm before running it against a production site.

Not only 10 years of no more security updates. But hosting static content is cheap, performant and sustainable. Bot literally (you can move the content anywhere, using any kind of server) and in energy sense.

While I understand it is not for everyone to write markdown files and run build commands, I strongly urge anyone with a WordPress or drupal site to give the various jamstacks, or static site builders and guis a test run.

When a PoC drops before that timeline is up (like now!) the attackers get a head start because they have less work to do - just figure out how to use it to their payload, start spraying it out.

Meanwhile maintainers don't want release an incomplete or misunderstood fix. Otherwise they'd risk people updating and believing that they're safe when they're not. Even a fragment of misinformation from an official channel will spread like wildfire. So when you demand fixes NOW you're demanding something that may not be completely understood.

So (I'm sure we'll find out but) I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job, and not risk us having to come back tomorrow for a fix to the fix.

LLMs gives attackers the advantage for a while, and it means we'll have to tighten the secrecy around even the rumour of a vulnerability.

https://www.php.net/downloads.php?source=Y

It's really up.

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

Users on the Free plan have access to the Cloudflare Free Managed Ruleset, a subset of the Cloudflare Managed Ruleset.

https://developers.cloudflare.com/waf/get-started/

Vulnerable but perhaps with no impact. If you've setup your web server well, the vulnerable PHP process is sandboxed, at least to some degree, and an attacker executing their own code within the compromised PHP process can't move laterally through your internal networks, write files to disk, read files from disk, etc because you've locked down the PHP process.

In 2026, perhaps it's possible to:

1. Use systemd socket activation with Accept=yes [1] and strict sandboxing applied to a systemd service that executes the PHP interpreter. The result being each incoming request is dealt with inside an isolated PHP process spawned specifically to handle the request. Compromise of a PHP process doesn't impact any other concurrent requests, or any future requests, except through defined sandbox interfaces such as access to a database server socket.

2. For each user of the web application (perhaps including an 'anonymous' user too if anonymous users have access to dynamic content), if using PostgreSQL, create a role in PostgreSQL for each web application user. Then use row-level-security permissions and security barrier views within the database, and have the PHP process accept credentials from the user which are then needed to be passed through to PostgreSQL to login as that individual user.

It's not without some significant downsides:

1. It's complex and you might be the only person in the world trying to use PHP in this secure way. And if you're going this far, for a complex web application, it'd be best to split it into smaller web applications each with their own systemd service defining specific sandboxing constraints. E.g. microservice architecture where "login", "file upload", "user administration" are all separated with different sandboxing constraints applied to each.

2. Performance will suffer and you'll need more resources--for spawning new PHP processes from scratch for each request (although this is already the case with php-fpm which is most widely used), and for dealing with row-level-security in PostgreSQL (see e.g. LEAKPROOF functions).

The more common pattern I've come across on public websites in recent times that might mirror some of the above is client-side JavaScript dynamic rendering with API calls to a GraphQL database exposed on the Internet (using e.g. field-level access control). The user isolation problem is essentially pushed from PHP+PostgreSQL to a GraphQL implementation.

[1] https://www.freedesktop.org/software/systemd/man/latest/syst...

https://emudhra.we-have-a-problem.com/

If the rumors going around are true this will be the worst computer security incident in history.