Kort sagt: Efter PHP-uppdateringen måste ni starta om PHP-FPM och alla andra tjänster som laddar PHP. Nya filer på hårddisken räcker inte så länge gamla PHP-processer körs i minnet. Först efter omstarten arbetar servern med den rättade koden från PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller leverantörens backport.
Varför ni måste starta om PHP-FPM
En paketuppdatering ersätter filerna på hårddisken. Processer som redan körs har dock redan laddat den gamla programkoden i minnet och arbetar vidare med den. PHP-FPM, Apache med mod_php eller LiteSpeed håller ofta sina workers vid liv i flera dagar.
För PHP2Shell är det särskilt viktigt. Sårbarheten CVE-2026-109619 hänger just på tillstånd som blir kvar mellan förfrågningar i samma worker. En worker med gammal kod förblir sårbar, oavsett vilken version som ligger på disken. Enligt php.net ska därför alla workers och processer startas om.
Vissa pakethanterare startar om tjänster automatiskt vid uppdatering, andra inte. Förlita er inte på det, utan kontrollera resultatet.
En typisk bild från vardagen: Pakethanteringen meddelar ”PHP uppdaterat”, övervakningen visar inga fel, webbplatsen fungerar. Ändå betjänar de gamla workers fortfarande varje förfrågan, eftersom ingen har startat om tjänsten. Utifrån går detta tillstånd inte att se. Därför hör kontrollen av processernas starttider till varje uppdatering.
Vilka tjänster laddar PHP?
| Driftläge | Vad som startas om | Typiskt kommando (namn varierar mellan distributioner) |
|---|---|---|
| PHP-FPM | varje FPM-tjänst, per installerad version | systemctl restart php8.3-fpm eller systemctl restart php-fpm |
| Apache med mod_php | Apache | systemctl restart apache2 eller systemctl restart httpd |
| php-cgi | den anropande webbservern resp. FastCGI-wrappern | beroende på miljö |
| LiteSpeed | LiteSpeed och lsphp-processerna | via LiteSpeed-administrationen eller dess tjänst |
| FrankenPHP | FrankenPHP-tjänsten eller containern | systemctl restart frankenphp eller skapa containern på nytt |
| Docker, Kubernetes | skapa containrar på nytt från ny image | se Patcha PHP i Docker-containrar |
Vid mod_php gäller: Uppdateringen berör Apache självt, eftersom PHP finns i varje Apache-process. Varför det här driftläget är särskilt känsligt står under Varför mod_php bär den högsta risken. För LiteSpeed finns detaljer på sidan LiteSpeed och LSAPI.
Starta om PHP-FPM: kommandona
Först hittar ni alla PHP-tjänster på servern. Plesk, cPanel och andra gränssnitt har egna PHP-tjänster med egna namn; listan visar dem också.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Starta därefter om varje funnen PHP-tjänst, inte bara den första:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # om en andra gren är installerad
sudo systemctl restart apache2 # vid mod_php; RHEL-familjen: httpd
Vi rekommenderar restart i stället för reload. Vid reload blir huvudprocessen kvar; det är avsett för konfigurationsändringar. Efter en säkerhetsuppdatering vill ni vara säkra på att varje process är ny.
Har ni dessutom satt övergångsåtgärder som session.upload_progress.enabled=0 eller fasta minnesgränser verkar även de först efter omstarten. En omstart klarar båda i ett steg.
Kontrollera att ingen gammal worker längre körs
Jämför processernas starttid med tidpunkten för uppdateringen. Alla kommandon är rent läsande.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # raden ”Active: … since …”
needrestart -r l # Debian/Ubuntu, om installerat
Om en process är äldre än uppdateringen har den inte omfattats. Vanliga orsaker är en bortglömd andra PHP-gren, en egen pooltjänst från en hostingpanel eller en container som bara har startats om i stället för att skapas från den nya imagen. Om rätt version körs visar sidan Kontrollera PHP-version och patchstatus rätt.
Dokumentera omstarten
Anteckna för varje server tidpunkten för uppdateringen och omstarten. Det ögonblicket skiljer den tid då servern var sårbar från tiden därefter. För en senare spårkontroll, för försäkringsgivare och för en möjlig anmälan enligt GDPR är det den viktigaste referenspunkten. Spara dessutom serverloggarna från och med den 20 oktober, som facktidningarna rekommenderar.
På servrar med många webbplatser lönar sig en kort tabell: server, tjänst, PHP-version, paketversion, tidpunkt för omstarten och personen som startade om. Så syns luckor i täckningen snabbt, till exempel en pool som förbisågs eller ett testsystem som ingen hade på sin lista.
Hur hjälper PHP SOS konkret?
Inom ramen för PHP-patchtjänsten tar vi över uppdatering och omstart som ett sammanhängande förlopp:
- Fastställa tjänster: Vi hittar alla processer som laddar PHP, även från hostingpaneler och containrar.
- Starta om kontrollerat, i samråd med er vid en lämplig tidpunkt och med hänsyn till pågående beställningar eller formulär.
- Kontrollera efteråt att ingen process är äldre än uppdateringen och att webbplatsen svarar normalt.
- Protokollföra: versioner, paketstatus och omstartstider per server.
Vanliga frågor
Räcker systemctl reload i stället för restart?
För PHP2Shell rekommenderar vi restart. En reload startar visserligen oftast om workers, men huvudprocessen kan fortsätta köra. Med restart säkerställer ni att ingen process med gammal kod blir kvar. Mot det korta avbrottet står ett tydligt belägg.
Måste jag starta om hela servern efter PHP-uppdateringen?
I regel inte. Det räcker att starta om alla tjänster som laddar PHP: PHP-FPM, Apache vid mod_php, LiteSpeed, FrankenPHP eller de berörda containrarna. En omstart av hela servern är den enkla varianten om ni är osäkra på vilka tjänster som använder PHP.
Startar mitt webbhotell om PHP automatiskt efter uppdateringen?
Det beror på leverantören. Fråga konkret om alla PHP-processer har startats om efter patchen och låt er bekräfta det skriftligen.