Flere PHP-versioner på én server: Patch hver enkelt for sig

Kort sagt: Kører der flere PHP-versioner på en server, skal hver enkelt efter PHP2Shell kontrolleres, opdateres og genstartes for sig. Typiske kilder er operativsystemet, hostingpaneler som Plesk eller cPanel, tredjepartskilder som sury.org eller Remi, CloudLinux, LiteSpeed og selvkompilerede versioner. Først en fuldstændig liste over pakker, filer og kørende processer viser, om der virkelig ikke er overset nogen version.

Den glemte version

En server, der har kørt i nogle år, samler PHP-versioner, som et loft samler gamle møbler. Panelet medbragte tre grene, til en kunde kom en ældre version fra en tredjepartskilde, operativsystemet har sin egen. Hver af dem blev engang installeret af en god grund. Bare ved ingen i dag længere, hvilke der stadig bruges.

Efter PHP2Shell er netop det et problem. Rettelserne udkom den 21. oktober 2026 til PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Men hver installation på serveren får dem ad sin egen vej, fra sin egen pakkevedligeholder og på sit eget tidspunkt. Til PHP 8.1 og ældre findes der kun minimale kilde-backports. Den, der kun opdaterer hovedversionen, lader de andre stå åbne.

Hvor de mange versioner kommer fra

Følgende oversigt nævner typiske kilder og eksempelstier. De nøjagtige stier er forskellige efter version og distribution.

Særligt lumske er sury.org-pakker, fordi de bruger de samme stier som distributionen. Om en php8.3 stammer fra Debian eller fra sury.org, viser først pakkekilden. Særlighederne beskriver indlæggene sury.org-repositoryet og Remi-repositoryet. Hvordan Plesk administrerer sine versioner, beskriver siden Plesk-server: Kontrollér og patch PHP-versioner.

Find alle PHP-installationer

En pålidelig liste opstår ud fra tre synsvinkler. Kommandoerne er rent læsende og kan køre et stykke tid afhængigt af serveren.

# 1. Pakker: hvad pakkehåndteringen kender
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. Filer: eksekverbare PHP-binaries, også uden for pakkehåndteringen
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. Processer: hvad der virkelig kører lige nu, med starttidspunkt
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Afstem de tre lister. En fil uden pakke tyder på en selvkompileret eller manuelt kopieret version. En proces uden tilhørende fil kan pege på en slettet, men stadig kørende installation. Kontrollér ved Apache desuden, om der er indlæst et PHP-modul, f.eks. med apache2ctl -M eller httpd -M. Containere og Kubernetes-pods optræder kun delvist på disse lister og kræver en egen kontrol af imagene.

Patch hver version for sig

Har hver installation en linje på jeres liste, følger det samme forløb for hver enkelt:

1. Afklar ansvaret: Kommer patchen fra distributionen, fra panelet, fra en tredjepartskilde eller fra jer selv?
2. Vurdér status: officiel rettet version, bekræftet backport, uafklaret eller åben.
3. Opdatér: ad den pågældende kildes vej, ikke ad en anden.
4. Genstart: tjenesten for denne version, ikke kun hovedtjenesten. Ved mod_php webserveren. Enkeltheder står under Genstart PHP-FPM og alle workers.
5. Kontrollér: sammenlign processernes starttidspunkt med tidspunktet for opdateringen.
6. Dokumentér: version, pakkestatus, bevis, genstartstidspunkt.

For versioner, hvortil der ikke findes nogen patch, gælder php.net's overgangsforanstaltninger frem til migreringen. Sæt dem for hver version for sig, for hver installation har sin egen php.ini og sine egne pools.

Hvilken version bruger kommandolinjen, og hvilken containeren?

To områder falder særligt ofte igennem rastret ved søgningen. Det første er kommandolinjen. Under Debian og Ubuntu afgør alternativsystemet, hvilken binary der gemmer sig bag kommandoen php. update-alternatives --display php viser, hvilke versioner der er registreret, og hvilken der gælder lige nu. Cronjobs, der kalder en fast sti som /usr/bin/php7.4, omgår dog denne indstilling. Derfor er det værd at kigge i alle brugeres crontabs og i konfigurationen af paneler, der selv opretter cronjobs.

Det andet område er containere. En Docker-container på serveren medbringer sin egen PHP-version, som ikke optræder på nogen pakkeliste på værten. docker ps viser kørende containere; om der er PHP deri og i hvilken version, afslører et kig i imaget eller et php -v i containeren. Patchen sker dér ikke på værten, men ved at bygge imaget om og udskifte containeren.

Færre er sikrere

Den bedste kontrol er den, man ikke behøver at foretage. Hver installeret PHP-version fordobler arbejdet ved den næste sårbarhed. Efter PHP2Shell er en klar regel derfor umagen værd: Hver version på serveren har brug for et formål og en ansvarlig. Det, der ikke har nogen, deaktiveres først og fjernes efter en observationstid. Mere herom i indlægget Slå gamle PHP-versioner fra i hostingpanelet.

Hvordan hjælper PHP SOS konkret?

• Vi udarbejder for jeres servere en fuldstændig liste over alle PHP-installationer ud fra pakker, filer, processer og containere.
• Vi afklarer pr. version oprindelse, ansvar og patchstatus.
• Som led i PHP-patchservice opdaterer vi hver version, genstarter hver tjeneste og dokumenterer statussen.
• Sammen med jer fastlægger vi, hvilke versioner der bliver, og fjerner de øvrige kontrolleret.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• php.net: Understøttede versioner
• Red Hat Security Bulletin RHSB-2026-013