Kort sagt: Efter PHP-opdateringen skal I genstarte PHP-FPM og alle andre tjenester, der indlæser PHP. Nye filer på harddisken er ikke nok, så længe gamle PHP-processer kører i hukommelsen. Først efter genstarten arbejder serveren med den rettede kode fra PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller jeres udbyders backport.
Hvorfor I skal genstarte PHP-FPM
En pakkeopdatering erstatter filerne på harddisken. Processer, der allerede kører, har dog allerede indlæst den gamle programkode i hukommelsen og arbejder videre med den. PHP-FPM, Apache med mod_php eller LiteSpeed holder ofte deres workers i live i dagevis.
For PHP2Shell er det særligt vigtigt. Sårbarheden CVE-2026-109619 hænger netop på tilstand, der består mellem forespørgsler i samme worker. En worker med gammel kode forbliver sårbar, uanset hvilken version der ligger på disken. Ifølge php.net skal alle workers og processer derfor genstartes.
Nogle pakkehåndteringer genstarter tjenester automatisk ved opdateringen, andre gør ikke. Stol ikke på det, men kontrollér resultatet.
Et typisk billede fra hverdagen: Pakkehåndteringen melder »PHP opdateret«, monitoreringen viser ingen fejl, websitet kører. Alligevel betjener de gamle workers fortsat hver forespørgsel, fordi ingen har genstartet tjenesten. Udefra kan denne tilstand ikke genkendes. Derfor hører kontrollen af processernes starttidspunkter med til enhver opdatering.
Hvilke tjenester indlæser PHP?
| Driftsform | Hvad der skal genstartes | Typisk kommando (navne afhænger af distributionen) |
|---|---|---|
| PHP-FPM | hver FPM-tjeneste, pr. installeret 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 kaldende webserver eller FastCGI-wrapperen | afhængigt af opsætningen |
| LiteSpeed | LiteSpeed og lsphp-processerne | via LiteSpeed-administrationen eller dens tjeneste |
| FrankenPHP | FrankenPHP-tjenesten eller containeren | systemctl restart frankenphp eller opret containeren påny |
| Docker, Kubernetes | opret containere påny fra nyt image | se Patch PHP i Docker-containere |
Ved mod_php gælder: Opdateringen berører selve Apache, fordi PHP sidder i hver Apache-proces. Hvorfor denne driftsform er særligt kritisk, står under Hvorfor mod_php bærer den højeste risiko. For LiteSpeed finder I enkeltheder på siden LiteSpeed og LSAPI.
Genstart PHP-FPM: kommandoerne
Først finder I alle PHP-tjenester på serveren. Plesk, cPanel og andre grænseflader medbringer egne PHP-tjenester med egne navne; listen viser dem med.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Derefter genstarter I hver fundet PHP-tjeneste, ikke kun den første:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # hvis en anden gren er installeret
sudo systemctl restart apache2 # ved mod_php; RHEL-familien: httpd
Vi anbefaler restart frem for reload. Ved reload består hovedprocessen; det er tænkt til konfigurationsændringer. Efter en sikkerhedsopdatering vil I være sikre på, at hver proces er ny.
Har I desuden sat midlertidige foranstaltninger som session.upload_progress.enabled=0 eller faste hukommelsesgrænser, virker disse ligeledes først efter genstarten. En genstart klarer begge dele i ét trin.
Kontrollér, at ingen gammel worker kører længere
Sammenhold processernes starttidspunkt med tidspunktet for opdateringen. Alle kommandoer er rent læsende.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # linjen „Active: … since …“
needrestart -r l # Debian/Ubuntu, hvis installeret
Hvis en proces er ældre end opdateringen, blev den ikke fanget. Hyppige årsager er en glemt anden PHP-gren, en egen pool-tjeneste fra et hostingpanel eller en container, der kun blev genstartet i stedet for oprettet påny fra det nye image. Om den rigtige version kører, viser siden Kontrollér PHP-version og rettelsesstatus korrekt.
Dokumentér genstarten
Notér for hver server tidspunktet for opdateringen og genstarten. Dette øjeblik adskiller den tid, hvor serveren var sårbar, fra tiden bagefter. Til en senere sporkontrol, til forsikringsselskabet og til en mulig anmeldelse efter GDPR er det det vigtigste holdepunkt. Gem desuden serverlogs fra og med 20. oktober, som fagpressen anbefaler.
På servere med mange websites er en kort tabel umagen værd: server, tjeneste, PHP-version, pakkeversion, tidspunkt for genstarten og den person, der har genstartet. Så opdages huller i dækningen hurtigt, f.eks. en pool, der blev overset, eller et testsystem, som ingen havde på sedlen.
Hvordan hjælper PHP SOS konkret?
Som led i PHP-patch-servicen overtager vi opdatering og genstart som et sammenhængende forløb:
- Finde tjenester: Vi finder alle processer, der indlæser PHP, også fra hostingpaneler og containere.
- Genstarte kontrolleret, efter aftale med jer på et passende tidspunkt og med øje for løbende bestillinger eller formularer.
- Efterkontrollere, at ingen proces er ældre end opdateringen, og at websitet svarer normalt.
- Protokollere: versioner, pakkestatus og genstartstidspunkter pr. server.
Ofte stillede spørgsmål
Er systemctl reload nok i stedet for restart?
Til PHP2Shell anbefaler vi restart. En reload genstarter nok som regel workers, men hovedprocessen kan køre videre. Med restart sikrer I, at ingen proces med gammel kode bliver tilbage. Over for den korte afbrydelse står et klart bevis.
Skal jeg genstarte hele serveren efter PHP-opdateringen?
Som regel ikke. Det er nok at genstarte alle tjenester, der indlæser PHP: PHP-FPM, Apache ved mod_php, LiteSpeed, FrankenPHP eller de berørte containere. En genstart af hele serveren er den enkle variant, hvis I er usikre på, hvilke tjenester der bruger PHP.
Genstarter min hostingudbyder PHP automatisk efter opdateringen?
Det afhænger af udbyderen. Spørg konkret, om alle PHP-processer er genstartet efter rettelsen, og få det bekræftet skriftligt.