Flera PHP-versioner på en server: patcha var och en för sig

Kort sagt: Körs flera PHP-versioner på en server måste efter PHP2Shell varje version kontrolleras, uppdateras och startas om för sig. Typiska källor är operativsystemet, hostingpaneler som Plesk eller cPanel, tredjepartskällor som sury.org eller Remi, CloudLinux, LiteSpeed och egenkompilerade versioner. Först en fullständig lista över paket, filer och körande processer visar om verkligen ingen version har förbisetts.

Den bortglömda versionen

En server som har varit i drift i några år samlar på sig PHP-versioner som en vind samlar gamla möbler. Panelen levererade tre grenar, för en kund tillkom en äldre version från en tredjepartskälla, operativsystemet har sin egen. Var och en installerades en gång av goda skäl. Men i dag vet ingen längre vilka som fortfarande behövs.

Efter PHP2Shell är just det ett problem. Rättningarna kom den 21 oktober 2026 för PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Varje installation på servern får dem dock på sin egen väg, från sin egen paketansvarige och vid sin egen tidpunkt. För PHP 8.1 och äldre finns bara minimala backports i källkoden. Den som bara uppdaterar huvudversionen lämnar de andra öppna.

Varifrån de många versionerna kommer

Översikten nedan nämner typiska källor och exempelsökvägar. De exakta sökvägarna skiljer sig åt per version och distribution.

Särskilt lömska är sury.org-paket, eftersom de använder samma sökvägar som distributionen. Om ett php8.3 kommer från Debian eller från sury.org visar först paketkällan. Särdragen beskrivs i inläggen sury.org-repositoryt och Remi-repositoryt. Hur Plesk hanterar sina versioner beskrivs på sidan Plesk-server: kontrollera och patcha PHP-versioner.

Hitta alla PHP-installationer

En tillförlitlig lista uppstår ur tre synvinklar. Kommandona är rent läsande och kan, beroende på server, köra en stund.

# 1. Paket: det som pakethanteraren känner till
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: körbara PHP-binärer, även utanför pakethanteringen
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: det som verkligen körs just nu, med starttid
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Stäm av de tre listorna mot varandra. En fil utan paket tyder på en egenkompilerad eller manuellt kopierad version. En process utan motsvarande fil kan peka på en raderad men fortfarande körande installation. Kontrollera vid Apache dessutom om en PHP-modul är laddad, till exempel med apache2ctl -M eller httpd -M. Containrar och Kubernetes-poddar syns bara delvis i dessa listor och kräver en egen granskning av imagerna.

Patcha varje version för sig

När varje installation har en rad i er lista följer samma förlopp för var och en:

1. Klarlägg ansvaret: Kommer patchen från distributionen, från panelen, från en tredjepartskälla eller från er själva?
2. Bedöm nivån: officiell rättad version, bekräftad backport, oklart eller öppet.
3. Uppdatera: på den aktuella källans väg, inte på någon annan.
4. Starta om: tjänsten för just den versionen, inte bara huvudtjänsten. Vid mod_php webbservern. Detaljer finns under Starta om PHP-FPM och alla workers.
5. Kontrollera: jämför processernas starttid med uppdateringstidpunkten.
6. Dokumentera: version, paketnivå, bevis, omstartstid.

För versioner utan patch gäller php.net:s övergångsåtgärder fram till migreringen. Sätt in dem separat för varje version, eftersom varje installation har sin egen php.ini och sina egna pooler.

Vilken version använder kommandoraden, vilken containern?

Två områden faller särskilt ofta mellan stolarna vid sökningen. Det första är kommandoraden. Under Debian och Ubuntu avgör alternativsystemet vilken binär som ligger bakom kommandot php. update-alternatives --display php visar vilka versioner som är registrerade och vilken som gäller just nu. Cronjobb som anropar en fast sökväg som /usr/bin/php7.4 kringgår dock den inställningen. Därför lönar det sig att titta i alla användares crontabs och i konfigurationen för paneler som skapar egna cronjobb.

Det andra området är containrar. En Docker-container på servern har med sig sin egen PHP-version, som inte syns i någon paketlista på värden. docker ps visar körande containrar; om PHP finns i dem och i vilken version framgår av imagen eller av ett php -v i containern. Patchen sker där inte på värden, utan genom att imagen byggs om och containern byts ut.

Färre är säkrare

Den bästa kontrollen är den man slipper göra. Varje installerad PHP-version fördubblar arbetet vid nästa sårbarhet. Efter PHP2Shell lönar det sig därför med en tydlig regel: varje version på servern behöver ett syfte och en ansvarig. Det som saknar det inaktiveras först och tas bort efter en observationstid. Mer om det i inlägget Stäng av gamla PHP-versioner i hostingpanelen.

Hur hjälper PHP SOS konkret?

• Vi tar fram en fullständig lista över alla PHP-installationer på era servrar utifrån paket, filer, processer och containrar.
• Vi klarlägger för varje version ursprung, ansvar och patchnivå.
• Inom ramen för PHP-patchtjänsten uppdaterar vi varje version, startar om varje tjänst och styrker nivån.
• Tillsammans med er avgör vi vilka versioner som ska finnas kvar och tar bort resten kontrollerat.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• php.net: versioner som stöds
• Red Hat Security Bulletin RHSB-2026-013