In short: If you want to harden your server for PHP, you make sure that a single vulnerability does not open up the whole server. We separate websites from each other, configure PHP and the web server securely, restrict permissions and access, and document every change. That keeps the damage smaller if something does happen.
Why hardening has become more important after PHP2Shell
PHP2Shell has shown how quickly a vulnerability in PHP itself becomes a problem for all websites on a server. With CVE-2026-109618 and CVE-2026-109619, attackers can execute code without logging in. The patch closes this door. Hardening answers a different question: what can someone do who gets in anyway, through this vulnerability or the next one?
On an unhardened server, all websites often run under the same user, PHP is allowed to execute system commands, and credentials are readable by all processes. A break-in through a small side site then reaches all the way to the online shop. Good hardening separates these areas. It is not a one-off action but a baseline state that has to be maintained with every new website and every version change.
Hardening a server for PHP: what we adjust in practice
Isolation per website
Each website gets its own system user and its own PHP-FPM pool. With open_basedir and suitable file permissions, an application sees only its own directory. More at open_basedir and isolation per website.
Secure PHP configuration
We set the php.ini and the pool configuration so that applications cannot override security-relevant values themselves. An excerpt of how this can look in an FPM pool:
; set values firmly in the FPM pool, not changeable via ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Which functions can additionally be blocked depends on the application. Notes are available at Configuring php.ini securely and Using disable_functions properly.
File permissions and write access
The web server may only write where necessary, for example in the upload folder. In upload directories, the execution of PHP is blocked. Program code is owned by a different user than the one PHP runs as. The principles are explained in File permissions on the web server.
Access, services and logs
SSH with keys only, admin interfaces with two-factor authentication, unneeded services and ports closed. Logs are retained and protected so that they still exist after an incident. We check backups for restorability.
Web server and security headers
The web server itself is part of hardening too: hide version information, switch off directory listings, block access to configuration, backup and version-control files, and add extra protection for admin areas, for instance with an IP allowlist. Security headers such as Content-Security-Policy or HSTS protect the visitors of your website in the browser.
What we often find during the inventory
Many weaknesses repeat from server to server. Typical ones are several websites under a shared user, publicly reachable database interfaces, old test installations in subfolders, forgotten PHP versions alongside the current one, and backups that sit in the web directory and can be downloaded. Logging of logins is also frequently missing altogether, or logs are deleted after a few days.
None of these points is spectacular on its own. Together, though, they decide whether a break-in stays limited to one website or affects the whole server.
How does PHP SOS help?
- Inventory: We record the operating system, web server, PHP versions, websites, users, open services and existing backups.
- Action plan: You receive a prioritised list with the effort and possible effects for each item. You decide what gets implemented.
- Implementation in steps: We change configurations by arrangement, test the websites after each step and record how each change can be rolled back.
- Verification: After implementation, we check the effect, for example whether a website really can no longer read other directories.
- Handover: You receive documentation of the new state that your hosting provider or agency can also follow.
What you get and what we need
You get a hardening report with the starting situation, the measures implemented, points deliberately left open together with the reason, and a recommendation for regular review. Changes to configuration files are documented in a traceable way.
From you we need:
- root or administrator access to the server and, for panels, panel access as well
- a list of the applications and their particularities, for example uploads, interfaces, cron jobs
- a technical contact person who can confirm functions after changes
- maintenance windows for restarts
- a current backup or the order to create one beforehand
What we do not promise
Hardening does not make a server invulnerable. It reduces the attack surface and limits damage, but it replaces neither updates nor monitoring. An unpatched PHP version remains vulnerable, no matter how well everything else is configured. That is why we combine hardening with the PHP patch service and afterwards recommend ongoing support through a security maintenance contract.
With shared hosting, much cannot be configured because the hosting provider dictates the configuration. In that case we show what is possible within your package and where a move to your own or a managed server would make sense.
Frequently asked questions
What does it mean to harden a server?
Hardening means switching off or restricting everything that is not needed for operation. This includes unnecessary services, overly broad permissions, open ports and insecure default settings. The goal is that a single mistake does not open up the whole server.
Would hardening have prevented PHP2Shell?
No, only a patch helps against a vulnerability in PHP itself. Hardening does, however, limit what an attacker can reach after a successful break-in, for example whether they can get at other websites or credentials.
Will hardening break my website?
The risk exists if settings are changed without testing. We make changes step by step, check the functions after each step and record how each change can be rolled back.
How often should the hardening be reviewed?
At the latest after major updates, a change of PHP version or new applications on the server. A regular check as part of ongoing maintenance makes sense.