Plesk-server: kontrollér og patch PHP-versioner

Kort sagt: En Plesk PHP-opdatering er først afsluttet, når hver installeret PHP-version er på en rettet status, alle PHP-FPM-tjenester er genstartet, og I kan dokumentere det med pakkestatus og processernes starttidspunkt. Versionsnummeret i panelet er ikke nok alene, fordi backports ofte lader det stå uændret.

Hvad PHP2Shell betyder for Plesk-servere

PHP2Shell betegner to kritiske sårbarheder i PHP selv (CVE-2026-109618 og CVE-2026-109619, hver CVSS v4.0 9,2). De gør det muligt for angribere at udføre kode på serveren uden login. Berørt er bl.a. PHP-FPM og Apache med mod_php, altså netop de driftsformer, som Plesk opsætter til websites.

Den 21.10.2026 udgav PHP-projektet de rettede versioner 8.5.12, 8.4.27, 8.3.36 og 8.2.35. For PHP 8.1 og ældre findes der ikke længere officielle opdateringer. Plesk-servere har en særlig egenskab: Her kører ofte flere PHP-versioner ved siden af hinanden, dels fra Plesk selv, dels fra operativsystemet. Hver af dem skal kontrolleres for sig.

Plesk PHP-opdatering: kortlæg først beholdningen

Før I opdaterer noget, skaffer I en liste over alle PHP-handlere og de domæner, der bruger dem. Det kan ske via panelet (Værktøjer og indstillinger, PHP-indstillinger) eller via kommandolinjen. Følgende kommandoer ændrer intet, de læser kun.

# Alle registrerede PHP-handlere med version og sti
plesk bin php_handler --list

# Version af hver PHP-version installeret af Plesk (sti som eksempel)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done

Notér for hver handler: version, driftsform (FPM, FastCGI, Apache-modul) og antallet af domæner. Handlere uden domæne er ingen afblæsning. De kan senere blive tildelt eller køre på test-subdomæner.

Kontrollér pakkestatus i stedet for visningen

Plesk viser det versionsnummer, som PHP selv melder. Leverer Plesk eller distributionen rettelsen som backport, kan der stadig stå f.eks. 8.2.34, selv om rettelsen er med. Omvendt kan et nummer, der ser aktuelt ud, vildlede, hvis en pakke endnu ikke er fulgt med. Afgørende er den installerede pakkestatus og udbyderens skriftlige bekræftelse.

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

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

Sammenlign pakkeversionerne med oplysningerne i Plesk-ændringsloggene og med henvisningerne fra jeres distribution. Er det dér ikke entydigt dokumenteret, at CVE-2026-109618 og CVE-2026-109619 er rettet, så spørg udbyderen. En skabelon hertil finder I under Spørg hostingudbyderen om patch-status.

Indspil opdateringen og genstart alle workere

Selve opdateringen kører via Plesk-installeren eller systemets pakkehåndtering. Derefter følger det trin, der oftest mangler: genstarten. Hver PHP-version har under Plesk sin egen FPM-tjeneste. Genstart dem alle, ikke kun hoveddomænets.

# List alle PHP-FPM-tjenester (tjenestenavne som eksempel)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Genstart pr. tjeneste, f.eks.:
systemctl restart plesk-php84-fpm

# Kontrollér starttidspunktet for de kørende PHP-processer
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

Kører et domæne med Apache og mod_php, genstarter I Apache fuldstændigt. Ligger en PHP-proces' starttidspunkt før opdateringen, er den endnu ikke fornyet. Mere om dette trin står under Genstart PHP-FPM og alle workere.

Midlertidig beskyttelse, hvis opdateringen endnu mangler

Findes der for en version endnu ingen patch, anbefaler php.net midlertidige foranstaltninger. De er ingen fuldstændig beskyttelse. Under Plesk sætter I værdier, som applikationer ikke må overskrive, som php_admin_value i domænets ekstra FPM-direktiver eller serverdækkende i php.ini for den pågældende version.

; Eksempel på ekstra PHP-FPM-direktiver 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 uploads er der ifølge php.net foreslået post_max_size = 32M, og upload_max_filesize skal ligge under. På PHP 8.5 kommer fatal_error_backtraces=0 til. Hukommelsesbegrænsningen via memory_limit=-1 bør kun anvendes sammen med en grænse på container- eller cgroup-niveau. Bagefter følger igen en genstart af alle workere. Enkeltheder står under Akutforanstaltninger uden patch. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler at tage webservere midlertidigt af nettet, hvis opdateringen ikke kan gennemføres med det samme.

Efter patchen: sikr logs og undersøg spor

En patch lukker sårbarheden for fremtiden. Den fjerner ikke skadelig software, som er smuttet ind tidligere, og dokumenterer ikke, at intet er sket. Gem derfor webserverens logs fra og med 20.10.2026. Plesk lægger dem pr. domæne i mappen logs; forkort ikke opbevaringen i denne situation.

Vær opmærksom på nye eller ændrede PHP-filer i upload-mapper, ukendte planlagte opgaver og nye administratorkonti. Offentliggjorte, bekræftede Indicators of Compromise findes hidtil ikke; detektionen bygger på adfærdsanalyse. Finder I noget påfaldende, så arbejd ikke videre på egen hånd, men sikr først tilstanden.

Hvordan hjælper PHP SOS konkret?

• Vi kortlægger alle PHP-handlere på jeres Plesk-server, tildeler domæner og kontrollerer den faktiske pakkestatus pr. version.
• Som led i vores PHP-patch-service indspiller vi opdateringer, genstarter alle tjenester og dokumenterer processernes starttidspunkter som bevis.
• Hvor en patch mangler, sætter vi de midlertidige foranstaltninger efter php.net serverdækkende og således, at de ikke kan overskrives.
• Vi sikrer logs og leder efter spor af et kompromis, ved fund sammen med incident response.
• Derefter hærder vi serveren varigt og fjerner PHP-versioner, der ikke er brug for.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• php.net: Understøttede versioner
• BSI