The historical criticism of shared hosting is fair: for most of its history, a compromised site on a shared node could read its neighbours' files, exhaust the whole machine's CPU, and in the worst configurations write to their document roots. All three are solved problems, but solving them costs density, which is why not everyone does.
Three attacks and three answers
1. Reading a neighbour's wp-config.php
The classic. Upload a PHP shell, walk /home, read database credentials from every WordPress install on the box. The answer is per-account filesystem namespaces: each account's PHP process sees a filesystem where /home contains exactly one directory — its own.
# from inside an account's PHP process$ ls /homeacct_8814$ cat /etc/passwd | wc -l9$ ls /home/../homeacct_8814# there is no path out, because the mount namespace has no siblings in it2. Taking the whole node's CPU
A runaway plugin or a crawler hitting an uncached endpoint can consume every core. Each account gets a cgroup v2 slice with a hard CPU quota, a memory limit, and an I/O weight. Exceeding your quota throttles you and nobody else. This is the reason we publish guaranteed vCPU numbers rather than 'up to'.
3. Escalating through a shared PHP-FPM pool
If accounts share a PHP-FPM master, a bug in one worker can leak into another. Every account gets its own PHP-FPM pool, running as its own uid, in its own namespace, with its own opcache. It costs us about 18 MB of RAM per idle account, which is the entire trade-off.
What this does not protect you from
- A vulnerable plugin on your own site. Isolation contains the blast radius to your account — your account is still fully compromised.
- A stolen SFTP or dashboard credential. That is what two-factor is for, and we nag you about it.
- Supply-chain compromise in a plugin update you chose to install.
The honest summary: shared hosting on a properly isolated platform has a security profile very close to a small VPS, and considerably better than a badly maintained VPS that nobody is patching. The isolation is not the weak link — the application usually is.