Plesk-server: kontrollera och patcha PHP-versioner

Kort sagt: En PHP-uppdatering i Plesk är först klar när varje installerad PHP-version har en åtgärdad version, alla PHP-FPM-tjänster har startats om och ni kan styrka det med paketstatus och processernas starttid. Versionsnumret som visas i panelen räcker inte som underlag, eftersom backports ofta lämnar det oförändrat.

Vad PHP2Shell innebär på Plesk-servrar

PHP2Shell är namnet på två kritiska sårbarheter i själva PHP (CVE-2026-109618 och CVE-2026-109619, vardera CVSS v4.0 9,2). De gör det möjligt för angripare att köra kod på servern utan inloggning. Bland annat PHP-FPM och Apache med mod_php berörs, alltså just de driftlägen som Plesk ställer in för webbplatser.

Den 21 oktober 2026 publicerade PHP-projektet de åtgärdade versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre. Plesk-servrar har en särskild egenhet: här körs ofta flera PHP-versioner sida vid sida, delvis från Plesk självt och delvis från operativsystemet. Var och en av dem måste kontrolleras för sig.

Plesk PHP-uppdatering: kartlägg först beståndet

Innan ni uppdaterar något skaffar ni en lista över alla PHP-hanterare och de domäner som använder dem. Det går via panelen (Verktyg och inställningar, PHP-inställningar) eller på kommandoraden. Följande kommandon ändrar ingenting, de läser bara.

# Alla registrerade PHP-hanterare med version och sökväg
plesk bin php_handler --list

# Version för varje PHP-version som Plesk har installerat (sökväg som exempel)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done

Anteckna för varje hanterare: version, driftläge (FPM, FastCGI, Apache-modul) och antalet domäner. Hanterare utan domän är ingen frikänning. De kan tilldelas senare eller köras på testunderdomäner.

Kontrollera paketstatus i stället för visningen

Plesk visar det versionsnummer som PHP självt rapporterar. Om Plesk eller distributionen levererar rättningen som backport kan det fortfarande stå till exempel 8.2.34 trots att korrigeringen finns med. Omvänt kan ett nummer som ser aktuellt ut vilseleda om ett paket ännu inte har uppdaterats. Det avgörande är den installerade paketstatusen och leverantörens skriftliga bekräftelse.

# Debian/Ubuntu (paketnamn som exempel)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (paketnamn som exempel)
rpm -qa | grep -E 'plesk-php|^php' | sort

Jämför paketversionerna med uppgifterna i Plesks ändringsloggar och anvisningarna från er distribution. Om det inte tydligt framgår där att CVE-2026-109618 och CVE-2026-109619 är åtgärdade frågar ni leverantören. En mall för det finns under Fråga webbhotellet om patchstatus.

Installera uppdateringen och starta om alla worker-processer

Själva uppdateringen går via Plesk-installeraren eller systemets pakethantering. Därefter kommer det steg som oftast saknas: omstarten. Varje PHP-version har under Plesk en egen FPM-tjänst. Starta om alla, inte bara den som hör till huvuddomänen.

# Lista alla PHP-FPM-tjänster (tjänstenamn som exempel)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Starta om per tjänst, t.ex.:
systemctl restart plesk-php84-fpm

# Kontrollera starttiden för de PHP-processer som körs
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

Om en domän körs med Apache och mod_php startar ni om Apache helt. Ligger en PHP-process starttid före uppdateringen är den ännu inte förnyad. Mer om det här steget finns under Starta om PHP-FPM och alla worker-processer.

Tillfälligt skydd om uppdateringen ännu saknas

Om det för en version ännu inte finns någon patch rekommenderar php.net tillfälliga åtgärder. De är inget fullständigt skydd. Under Plesk lägger ni värden som applikationer inte får skriva över som php_admin_value i domänens extra FPM-direktiv eller serveromfattande i php.ini för respektive version.

; Exempel på extra PHP-FPM-direktiv i Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

Med uppladdningar är enligt php.net post_max_size = 32M avsett, med upload_max_filesize under det värdet. På PHP 8.5 tillkommer fatal_error_backtraces=0. Minnesbegränsningen via memory_limit=-1 bör bara användas tillsammans med en gräns på container- eller cgroup-nivå. Därefter följer åter en omstart av alla worker-processer. Detaljer finns under Omedelbara åtgärder utan patch. BSI (den tyska förbundsmyndigheten för informationssäkerhet) rekommenderar att webbservrar tillfälligt kopplas bort från nätet om uppdateringen inte kan göras direkt.

Efter patchen: säkra loggar och kontrollera spår

En patch stänger sårbarheten för framtiden. Den tar inte bort skadlig kod som fördes in tidigare och bevisar inte att ingenting har hänt. Spara därför webbserverloggarna från och med den 20 oktober 2026. Plesk lägger dem per domän i katalogen logs; korta inte lagringstiden i det här läget.

Håll utkik efter nya eller ändrade PHP-filer i uppladdningskataloger, okända schemalagda uppgifter och nya administratörskonton. Publicerade, bekräftade Indicators of Compromise finns hittills inte; identifieringen bygger på beteendeanalys. Om ni hittar något avvikande ska ni inte arbeta vidare på egen hand utan först säkra tillståndet.

Hur hjälper PHP SOS konkret?

• Vi kartlägger alla PHP-hanterare på er Plesk-server, kopplar dem till domäner och kontrollerar den faktiska paketstatusen per version.
• Inom ramen för vår PHP-patchtjänst installerar vi uppdateringar, startar om alla tjänster och dokumenterar processernas starttider som underlag.
• Där en patch saknas sätter vi de tillfälliga åtgärderna enligt php.net serveromfattande och så att de inte kan skrivas över.
• Vi säkrar loggar och söker efter spår av ett intrång, vid fynd tillsammans med Incident Response.
• Därefter härdar vi servern långsiktigt och tar bort PHP-versioner som inte behövs.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• php.net: versioner som stöds
• BSI