Meerdere PHP-versies op één server: patch elke versie afzonderlijk

Kort gezegd: Draaien er meerdere PHP-versies op een server, dan moet na PHP2Shell elke versie afzonderlijk worden gecontroleerd, bijgewerkt en herstart. Typische bronnen zijn het besturingssysteem, hostingpanelen zoals Plesk of cPanel, externe bronnen zoals sury.org of Remi, CloudLinux, LiteSpeed en zelf gecompileerde versies. Pas een volledige lijst op basis van pakketten, bestanden en draaiende processen toont of echt geen enkele versie over het hoofd is gezien.

De vergeten versie

Een server die al enkele jaren draait, verzamelt PHP-versies zoals een zolder oude meubels. Het paneel bracht drie takken mee, voor een klant kwam een oudere versie uit een externe bron erbij, het besturingssysteem heeft zijn eigen. Elk daarvan is ooit om een goede reden geïnstalleerd. Alleen weet nu niemand meer welke nog nodig is.

Na PHP2Shell is dat juist een probleem. De correcties verschenen op 21 oktober 2026 voor PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Elke installatie op de server ontvangt ze echter langs haar eigen weg, van haar eigen pakketbeheerder en op haar eigen tijd. Voor PHP 8.1 en ouder bestaan alleen minimale bronbackports. Wie alleen de hoofdversie bijwerkt, laat de andere open.

Waar de vele versies vandaan komen

Het onderstaande overzicht noemt typische bronnen en voorbeeldpaden. De exacte paden verschillen per versie en distributie.

Vooral verraderlijk zijn sury.org-pakketten, omdat ze dezelfde paden gebruiken als de distributie. Of een php8.3 uit Debian of uit sury.org komt, toont pas de pakketbron. De bijzonderheden beschrijven de artikelen De sury.org-repository en De Remi-repository. Hoe Plesk zijn versies beheert, beschrijft de pagina Plesk-server: PHP-versies controleren en patchen.

Alle PHP-installaties vinden

Een betrouwbare lijst ontstaat uit drie invalshoeken. De opdrachten zijn uitsluitend lezend en kunnen afhankelijk van de server enige tijd draaien.

# 1. Pakketten: wat de pakketbeheerder kent
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Bestanden: uitvoerbare PHP-binaries, ook buiten de pakketbeheerder
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Processen: wat er nu werkelijk draait, met starttijd
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Vergelijk de drie lijsten. Een bestand zonder pakket wijst op een zelf gecompileerde of handmatig gekopieerde versie. Een proces zonder bijpassend bestand kan wijzen op een verwijderde maar nog draaiende installatie. Controleer bij Apache bovendien of een PHP-module is geladen, bijvoorbeeld met apache2ctl -M of httpd -M. Containers en Kubernetes-pods verschijnen in deze lijsten slechts gedeeltelijk en vragen om een eigen controle van de images.

Elke versie afzonderlijk patchen

Heeft elke installatie een regel in uw lijst, dan volgt voor elke dezelfde procedure:

1. Verantwoordelijkheid vaststellen: Komt de patch van de distributie, van het paneel, uit een externe bron of van uzelf?
2. Stand beoordelen: officiële gecorrigeerde versie, bevestigde backport, onopgehelderd of open.
3. Bijwerken: langs de weg van de betreffende bron, niet langs een andere.
4. Herstarten: de service van deze versie, niet alleen de hoofdservice. Bij mod_php de webserver. Details staan onder PHP-FPM en alle workers herstarten.
5. Controleren: starttijd van de processen vergelijken met het tijdstip van de update.
6. Documenteren: versie, pakketstand, bewijs, herstarttijd.

Voor versies waarvoor geen patch bestaat, gelden tot de migratie de overbruggingsmaatregelen van php.net. Stel die voor elke versie apart in, want elke installatie heeft haar eigen php.ini en haar eigen pools.

Welke versie gebruikt de opdrachtregel, welke de container?

Twee gebieden vallen bij het zoeken bijzonder vaak door de mazen. Het eerste is de opdrachtregel. Onder Debian en Ubuntu bepaalt het alternatievensysteem welke binary achter de opdracht php zit. update-alternatives --display php toont welke versies geregistreerd zijn en welke momenteel geldt. Cronjobs die een vast pad zoals /usr/bin/php7.4 aanroepen, omzeilen deze instelling echter. Daarom loont een blik in de crontabs van alle gebruikers en in de configuratie van panelen die eigen cronjobs aanmaken.

Het tweede gebied zijn containers. Een Docker-container op de server brengt zijn eigen PHP-versie mee, die in geen enkele pakketlijst van de host voorkomt. docker ps toont draaiende containers; of er PHP in zit en in welke versie, onthult een blik in de image of een php -v in de container. De patch gebeurt daar niet op de host, maar door de image opnieuw te bouwen en de container te vervangen.

Minder is veiliger

De beste controle is die welke men niet hoeft te doen. Elke geïnstalleerde PHP-versie verdubbelt de inspanning bij het volgende lek. Na PHP2Shell loont daarom een duidelijke regel: elke versie op de server heeft een doel en een verantwoordelijke nodig. Wat die niet heeft, wordt eerst gedeactiveerd en na een observatieperiode verwijderd. Meer daarover in het artikel Oude PHP-versies in het hostingpaneel uitschakelen.

Hoe helpt PHP SOS concreet?

• Wij maken voor uw servers een volledige lijst van alle PHP-installaties op basis van pakketten, bestanden, processen en containers.
• Wij stellen per versie herkomst, verantwoordelijkheid en patchstand vast.
• In het kader van de PHP-patchservice werken wij elke versie bij, herstarten wij elke service en onderbouwen wij de stand.
• Samen met u bepalen wij welke versies blijven, en verwijderen wij de overige gecontroleerd.

Veelgestelde vragen

Bronnen

• php.net: beveiligingsmeldingen
• php.net: ondersteunde versies
• Red Hat Security Bulletin RHSB-2026-013