Comment by dhx

> Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.

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