Kort gezegd: Na de PHP-update moet u PHP-FPM en alle andere diensten die PHP laden herstarten. Nieuwe bestanden op de schijf volstaan niet zolang oude PHP-processen in het geheugen draaien. Pas na de herstart werkt de server met de gecorrigeerde code van PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 of de backport van uw aanbieder.
Waarom u PHP-FPM moet herstarten
Een pakketupdate vervangt de bestanden op de schijf. Processen die al draaien, hebben de oude programmacode echter al in het geheugen geladen en werken daarmee door. PHP-FPM, Apache met mod_php of LiteSpeed houden hun workers vaak dagenlang in leven.
Voor PHP2Shell is dat bijzonder belangrijk. De kwetsbaarheid CVE-2026-109619 hangt juist aan toestand die tussen verzoeken in dezelfde worker blijft bestaan. Een worker met oude code blijft kwetsbaar, welke versie er ook op de schijf staat. Volgens php.net moeten daarom alle workers en processen worden herstart.
Sommige pakketbeheerders herstarten diensten bij de update automatisch, andere niet. Verlaat u er niet op, maar controleer het resultaat.
Een typisch beeld uit de dagelijkse praktijk: de pakketbeheerder meldt „PHP bijgewerkt”, de monitoring toont geen fouten, de website draait. Toch bedienen de oude workers elk verzoek verder, omdat niemand de dienst heeft herstart. Van buitenaf is deze toestand niet te herkennen. Daarom hoort de controle van de starttijden van processen bij elke update.
Welke diensten laden PHP?
| Werkwijze | Wat herstarten | Typische opdracht (namen verschillen per distributie) |
|---|---|---|
| PHP-FPM | elke FPM-dienst, per geïnstalleerde versie | systemctl restart php8.3-fpm of systemctl restart php-fpm |
| Apache met mod_php | Apache | systemctl restart apache2 of systemctl restart httpd |
| php-cgi | de aanroepende webserver of FastCGI-wrapper | afhankelijk van de opstelling |
| LiteSpeed | LiteSpeed en de lsphp-processen | via het LiteSpeed-beheer of de bijbehorende dienst |
| FrankenPHP | de FrankenPHP-dienst of container | systemctl restart frankenphp of container opnieuw aanmaken |
| Docker, Kubernetes | containers opnieuw aanmaken uit een nieuw image | zie PHP in Docker-containers patchen |
Bij mod_php geldt: de update betreft Apache zelf, omdat PHP in elk Apache-proces zit. Waarom deze werkwijze bijzonder gevoelig is, staat onder Waarom mod_php het hoogste risico draagt. Voor LiteSpeed vindt u details op de pagina LiteSpeed en LSAPI.
PHP-FPM herstarten: de opdrachten
Zoek eerst alle PHP-diensten op de server. Plesk, cPanel en andere interfaces brengen eigen PHP-diensten met eigen namen mee; de lijst toont ze mee.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Herstart dan elke gevonden PHP-dienst, niet alleen de eerste:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # als er een tweede tak is geïnstalleerd
sudo systemctl restart apache2 # bij mod_php; RHEL-familie: httpd
Wij adviseren restart in plaats van reload. Bij een reload blijft het hoofdproces bestaan; dat is bedoeld voor configuratiewijzigingen. Na een beveiligingsupdate wilt u zeker weten dat elk proces nieuw is.
Hebt u daarnaast overbruggingsmaatregelen ingesteld zoals session.upload_progress.enabled=0 of vaste geheugengrenzen, dan werken die eveneens pas na de herstart. Een herstart regelt beide in één stap.
Controleren dat er geen oude worker meer draait
Vergelijk de starttijd van de processen met het tijdstip van de update. Alle opdrachten zijn puur lezend.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # regel “Active: … since …”
needrestart -r l # Debian/Ubuntu, indien geïnstalleerd
Is een proces ouder dan de update, dan is het niet meegenomen. Veelvoorkomende oorzaken zijn een vergeten tweede PHP-tak, een eigen pooldienst uit een hostingpaneel of een container die alleen is herstart in plaats van aangemaakt uit het nieuwe image. Of de juiste versie draait, toont de pagina PHP-versie en patchstand goed controleren.
Herstart documenteren
Noteer voor elke server het tijdstip van de update en van de herstart. Dit moment scheidt de tijd waarin de server kwetsbaar was van de tijd daarna. Voor een latere sporencontrole, voor verzekeraars en voor een mogelijke melding op grond van de AVG is dat het belangrijkste referentiepunt. Bewaar bovendien de serverlogs vanaf 20 oktober, zoals de vakpers adviseert.
Op servers met veel websites loont een korte tabel: server, dienst, PHP-versie, pakketversie, tijdstip van de herstart en de persoon die heeft herstart. Zo vallen hiaten in de dekking snel op, bijvoorbeeld een pool die is gemist of een testsysteem dat niemand op het lijstje had.
Hoe helpt PHP SOS concreet?
In het kader van de PHP-patchservice nemen wij update en herstart over als samenhangend verloop:
- Diensten vaststellen: wij vinden alle processen die PHP laden, ook uit hostingpanelen en containers.
- Gecontroleerd herstarten, in overleg met u op een passend moment en met oog voor lopende bestellingen of formulieren.
- Nacontrole dat geen enkel proces ouder is dan de update en de website normaal antwoordt.
- Protocolleren: versies, pakketstanden en herstarttijden per server.
Veelgestelde vragen
Volstaat systemctl reload in plaats van restart?
Voor PHP2Shell adviseren wij restart. Een reload herstart de workers meestal wel, maar het hoofdproces kan doorlopen. Met restart weet u zeker dat er geen proces met oude code overblijft. Tegenover de korte onderbreking staat een duidelijk bewijs.
Moet ik na de PHP-update de hele server herstarten?
In de regel niet. Het volstaat alle diensten te herstarten die PHP laden: PHP-FPM, Apache bij mod_php, LiteSpeed, FrankenPHP of de getroffen containers. Een herstart van de hele server is de eenvoudige variant als u niet zeker weet welke diensten PHP gebruiken.
Herstart mijn hoster PHP na de update automatisch?
Dat hangt van de aanbieder af. Vraag concreet of na de patch alle PHP-processen zijn herstart, en laat u dat schriftelijk bevestigen.