Securing Your Own Root Server and vServer

In short: Anyone who manages a root server or vServer themselves must also secure it themselves after PHP2Shell: bring PHP packages to a fixed release, restart all PHP processes and verify the result. The data center operator generally looks after hardware, virtualization and network only. After that, it is worth hardening the server permanently.

Your responsibility with your own server

With an unmanaged root server or vServer, you rent computing power, not care. Operating system, web server, PHP, database, firewall, backups and monitoring are in your hands. For management and owners, that means: if nobody in-house or at a service provider has explicitly taken on these tasks, nobody does them.

PHP2Shell makes this visible. The two vulnerabilities CVE-2026-109618 and CVE-2026-109619 are in PHP itself and allow code execution without logging in. On 21 October 2026 the PHP project released the versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The BSI (German Federal Office for Information Security) recommends an immediate update and, if that is not possible, taking the web server off the network temporarily.

Securing a vServer: check inventory and package state

First get an overview of which PHP versions are installed and where they come from. Many servers use additional package sources alongside the distribution's packages. The following commands only read. Package names are examples.

# Debian/Ubuntu: installed PHP packages and their origin
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'

# Which PHP binaries exist at all?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null

The version number alone is not enough. Distributions often ship security fixes as a backport, in which case the displayed number stays older. The package's changelog is decisive.

# Debian/Ubuntu (package name as an example)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# RHEL family (package name as an example)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'

A detailed guide is under Checking the PHP version and patch level.

Apply the update and renew all processes

Apply the updates through the package manager and then restart every service that loads PHP. Depending on the setup, that is PHP-FPM, Apache with mod_php, LiteSpeed or an application server. New files on disk are not enough as long as old processes keep running in memory.

# Find services with PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Show processes with their start time
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: detect programs with outdated libraries (if installed)
needrestart -r l

Every relevant process should have been started after the update. The tool needrestart is helpful on Debian systems, as it shows services with outdated libraries. Details on the restart are in Restarting PHP-FPM and all workers.

For a first search for traces, a few checks are suitable that change nothing. Look for PHP files that were newly created or changed in web directories since 17 October 2026, for unknown entries in the crontabs of all users, for new system users and SSH keys, and for processes of the web server user that hold outgoing connections.

# PHP files changed since 17 October 2026 (path as an example)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Network connections with the associated process
ss -tupn

None of these checks proves a break-in on its own, and an empty result does not prove the opposite. But they show whether a deeper investigation is needed. Work on copies of the logs and do not modify suspicious files until the state has been preserved. If you find something, an orderly investigation is the safe route. In that case, do not simply shut the server down and do not rebuild it immediately, because that loses traces that matter for assessing reporting obligations and for a possible criminal complaint.

Hardening the server permanently

After the acute patch comes basic security. It does not prevent every vulnerability, but it limits the damage and shortens the response time next time. These points have proven their worth:

• Access: SSH with keys only, no direct root login, administration interfaces reachable only from known networks.
• Firewall: open only the ports that are really needed, restrict the web server's outgoing connections.
• PHP configuration: disable dangerous functions, open_basedir per website, separate pools and users per application.
• File permissions: the web server must not be able to write program code, upload directories do not execute PHP.
• Updates: apply security updates automatically, and plan the restart and verification as a fixed step.
• Backups: backups following the 3-2-1 rule, at least one copy outside the server and protected against modification.
• Logs: collect logs centrally and keep them long enough.

What a reliable backup looks like is described in Backups following the 3-2-1 rule. The BSI's IT-Grundschutz is a suitable framework for companies.

When a managed server is the better choice

Your own server is worthwhile if someone reliably takes over the maintenance: following updates, assessing situations like PHP2Shell, being able to react at night. If that capacity is missing, either a managed server or a fixed maintenance contract makes sense. In both cases it is important to put the responsibilities in writing. More under Managed server: clarifying responsibility.

How does PHP SOS help?

• We record all PHP installations, package sources and services on your server and assess the actual patch level.
• We apply updates, restart all processes and document the result.
• We check the server for traces of a compromise and preserve logs for later analysis.
• As part of our server hardening, we set up access, firewall, PHP pools and permissions properly.
• On request, we take over ongoing maintenance through a security maintenance contract.

Frequently asked questions

Sources

• php.net: Security announcements
• PHP 8 ChangeLog
• php.net: Supported versions
• BSI IT-Grundschutz (IT baseline protection)