Kort sagt: Plesk PHP-handlern avgör hur PHP körs för en webbplats: som FPM-applikation med gemensam pool, som Dedicated FPM med en egen pool per webbplats, som FastCGI-applikation eller som Apache-modul (mod_php). Ur säkerhetssynpunkt är Dedicated FPM under Linux oftast det bästa valet, Apache-modulen det sämsta. Plesk betecknar den själv som föråldrad respektive osäker, och vid PHP2Shell ser PHP-teamet den högsta risken just vid mod_php.
Varför handlern är mer än en prestandafråga
I Plesk väljer ni för varje webbplats en PHP-version och en handler. Många behandlar handlern som en detalj för prestanda och minne. Den avgör dock också hur starkt webbplatserna är åtskilda från varandra, var säkerhetsinställningar får verkan och vilka processer som måste startas om efter en uppdatering.
Efter PHP2Shell blir det valet konkret. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 berör alla vanliga driftlägen, men PHP-teamet bedömer risken som högst vid mod_php. Den som på sin Plesk-server fortfarande driver domäner med Apache-modulen bör ändra det nu. Hur ni kontrollerar och patchar versioner beskrivs på sidan Plesk-server: kontrollera och patcha PHP-versioner; här handlar det om valet av driftläge.
Plesk PHP-handlers i översikt
Översikten nedan bygger på Plesk-dokumentationen för Plesk Obsidian, kompletterad med säkerhetsperspektivet. Under Linux kan FPM-handlers enligt Plesk levereras antingen via Apache eller nginx, FastCGI alltid via Apache.
| Handler | Levereras via | Isolering | Rekommendation enligt Plesk | Säkerhetsperspektiv |
|---|---|---|---|---|
| Dedicated FPM application | Apache eller nginx | egen pool per webbplats | Linux med delad hosting | bästa åtskillnaden, egna värden per pool |
| FPM application | Apache eller nginx | gemensam pool per PHP-version | dedikerade Linux-servrar | en felaktig webbplats kan störa andra med samma version |
| FastCGI application | Apache (Linux) | permanenta processer, god åtskillnad | Windows-servrar | stabil, under Linux oftast ersatt av FPM |
| Apache module (mod_php) | Apache | PHP i webbserverprocessen | rekommenderas inte | högsta PHP2Shell-risken enligt PHP-teamet |
| CGI application | Apache | ny process per förfrågan | rekommenderas inte | föråldrad |
Bakgrunden till själva driftlägena förklaras på sidorna PHP-FPM förklarat och Varför mod_php bär den högsta risken.
Gemensam eller egen pool?
Skillnaden mellan FPM och Dedicated FPM underskattas ofta. Med den vanliga FPM-handlern delar enligt Plesk alla webbplatser med samma PHP-version en processpool. Det sparar minne, men betyder också: en webbplats som orsakar problem kan dra med sig alla andra med samma version, och den gemensamma cachen delas.
Dedicated FPM ger varje webbplats en egen pool. Enligt Plesk förbättrar det isolering och prestanda, men kostar mer minne. Ur säkerhetssynpunkt är den egna poolen grunden för att kunna sätta inställningar som open_basedir, minnesgränser eller uppladdningsgränser separat per webbplats. Hur ni konsekvent skiljer åt pooler beskrivs i inlägget Isolera PHP-FPM-pooler per webbplats.
nginx eller Apache: .htaccess-fällan
Väljer ni en handler som levereras via nginx ändras något grundläggande: enligt Plesk ignorerar dessa handlers filen .htaccess. Det som står där får inte längre någon verkan.
Det är en säkerhetsfråga. Många applikationer och administratörer lägger skyddsregler i .htaccess, till exempel ett förbud mot att köra PHP-filer i uppladdningsmappar eller spärrar för konfigurationsfiler. Efter ett byte till nginx är dessa regler tyst satta ur spel. Kontrollera därför före bytet vilka skyddsregler som står i .htaccess och överför dem till domänens nginx-konfiguration.
Ett handlerbyte är en ändring av säkerhetskonfigurationen. Testa därefter specifikt om spärrade sökvägar fortfarande är spärrade, och inte bara om startsidan laddas.
Kontrollera och ställ om handlern
Först skaffar ni er en överblick över vilka domäner som använder vilken handler. Kommandona är rent läsande.
# Alla registrerade handlers med ID, version och typ
plesk bin php_handler --list
# Domäner som använder en viss handler (ID ur listan)
plesk bin php_handler --get-usage -id <handler-id>
# Körs PHP i Apache-processen? (Debian/Ubuntu: apache2ctl, RHEL-familjen: httpd)
apache2ctl -M 2>/dev/null | grep -i php
För omställningen går ni fram domän för domän:
- Fånga upp skyddsreglerna ur
.htaccess, om den nya handlern levereras via nginx. - Sätt övergångsvärden mot PHP2Shell, till exempel
session.upload_progress.enabled=0, för den nya handlern. Vid FPM hör de somphp_admin_valuehemma i poolens ytterligare direktiv, vid FastCGI gäller andra vägar. - Byt handler i domänens PHP-inställningar, helst först på en kopia.
- Testa funktionerna och kontrollera att domänen betjänas av processer med aktuell kod.
- Används Apache-modulen inte längre av någon domän, inaktivera handlern.
I vilken ordning ska ni ställa om?
På en vuxen Plesk-server går det sällan att ställa om allt på en dag. En ordning efter risk hjälper till att använda den knappa tiden förnuftigt:
- Först domäner med Apache-modulen, för där är risken från PHP2Shell enligt PHP-teamet högst och Plesk avråder ändå.
- Därefter domäner med känsliga data, till exempel butiker, kundportaler eller formulär med hälso- eller avtalsdata. Här lönar sig den egna poolen särskilt.
- Sedan domäner på gamla PHP-versioner, som ändå måste ställas om. Handler och version kan bytas tillsammans i ett underhållsfönster.
- Sist byte från gemensam till egen pool för övriga domäner, om serverns minne tillåter det.
Kontrollera minnesbelastningen före det sista steget. Plesk påpekar att Dedicated FPM kräver mer minne och råder till övervakning vid många webbplatser. En server som växlar ut minne efter omställningen blir långsam, och ont om minne är just vid PHP2Shell inget bra tillstånd.
Hur hjälper PHP SOS konkret?
- Vi kartlägger vilka domäner på er Plesk-server som använder vilken handler och markerar domäner med Apache-modul.
- Vi ställer om till Dedicated FPM och överför skyddsregler från
.htaccesstill nginx-konfigurationen där det behövs. - Vi sätter övergångsvärden och gränser per pool och kontrollerar att de gäller i webbkontexten.
- Inom ramen för serverhärdningen inaktiverar vi föråldrade handlers och dokumenterar konfigurationen.
Vanliga frågor
Vilken PHP-handler rekommenderar Plesk?
Enligt Plesk-dokumentationen är FPM den rekommenderade handlern på dedikerade Linux-servrar, Dedicated FPM på Linux-servrar för delad hosting och FastCGI på Windows-servrar. Apache-modulen, CGI och ISAPI betecknar Plesk som starkt föråldrade respektive osäkra.
Varför är handlern Apache-modul särskilt kritisk efter PHP2Shell?
Handlern motsvarar mod_php. PHP-teamet bedömer risken från PHP2Shell som högst vid mod_php, eftersom en exploit har visats där innan någon applikationskod körs. Dessutom avråder Plesk självt från den handlern.
Vad ändras om PHP levereras via nginx i stället för Apache?
Enligt Plesk ignorerar handlers som levereras via nginx filen .htaccess. Säkerhetsregler som står där, till exempel spärrar för PHP i uppladdningsmappar, gäller då inte längre och måste överföras till nginx-regler.
Måste jag starta om PHP efter ett handlerbyte?
Kontrollera efter bytet vilka PHP-processer som körs för domänen och sedan när. Vid Dedicated FPM får domänen en egen pool. En gammal process med föråldrad kod bör därefter inte längre arbeta för domänen.
Är Dedicated FPM alltid det bästa valet?
För isoleringen ja, eftersom varje webbplats får en egen pool. Priset är ett högre minnesbehov. Plesk råder till att övervaka servrar med många webbplatser.