Kort gezegd: Wie een PHP-update wil laten installeren, heeft meer nodig dan nieuwe pakketten: beslissend zijn de juiste pakketstand, de herstart van alle PHP-processen en een bewijs daarvan. Precies dat levert onze PHP-patchservice. U ontvangt per server een schriftelijk bewijs dat u intern of aan derden kunt voorleggen.
Waarom een PHP-update alleen vaak niet volstaat
Sinds 21 oktober 2026 zijn er patches voor de PHP2Shell-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619. Het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert direct te updaten. In de praktijk zien wij drie typische struikelblokken.
Ten eerste toont het versienummer niet altijd de werkelijke stand. Distributies en hosters installeren soms backports; dan meldt bijvoorbeeld Plesk nog steeds 8.2.34, terwijl de pakketstand gepatcht is. Ten tweede blijven na de installatie vaak oude PHP-processen doordraaien. Nieuwe bestanden op de schijf beschermen niet zolang de oude workers in het geheugen werken. Ten derde draaien op een server vaak meerdere PHP-versies naast elkaar, en een daarvan wordt vergeten.
PHP-update laten installeren: de verholpen versies
| Tak | Verholpen vanaf | Voorgaande stand | Opmerking |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | controleer bovendien fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | ondersteuning eindigt op 31 december 2026 |
| PHP 8.1 en ouder | geen officiële updates | – | alleen minimale broncode-backports voor 7.4, 8.0, 8.1 |
Bij pakketten uit distributies of van hosters telt niet het getal achter „PHP”, maar de pakketstand die de aanbieder als gepatcht bevestigt. Hoe u dat zelf controleert, leest u onder PHP-versie en patchstand goed controleren.
Hoe helpt PHP SOS concreet?
- Inventarisatie: wij leggen alle PHP-installaties op de server vast, de werkwijze (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) en welke website welke versie gebruikt.
- Update installeren: wij installeren de verholpen versies uit de pakketbron van uw distributie, uw paneel of het officiële project. Voor containers bouwen we samen met u nieuwe images.
- Herstart van alle processen: wij herstarten PHP-FPM, Apache, LiteSpeed of de betreffende workers volledig en controleren dat geen enkel proces ouder is dan de update. Achtergronden staan op PHP-FPM en alle workers herstarten.
- Functiecontrole: wij openen de belangrijkste pagina's en functies, zoals homepage, login, formulieren en kassa, en controleren de foutlogs.
- Bewijs: u ontvangt per server een protocol met versie, pakketstand, tijdstip van de herstart en openstaande punten.
Een typische controlestap na de herstart ziet er zo uit:
# Versie van de PHP-CLI en van het FPM-binaire bestand (pad afhankelijk van het systeem)
php -v
php-fpm8.3 -v
# Starttijd van de FPM-processen: moet na de update liggen
ps -o pid,lstart,cmd -C php-fpm8.3
Bijzondere gevallen: panelen, containers en meerdere PHP-versies
Op servers met Plesk of cPanel komen PHP-versies vaak uit de pakketbronnen van het paneel en niet uit de distributie. Daar controleren we elke geïnstalleerde versie afzonderlijk, ook versies die momenteel aan geen enkele website zijn toegewezen. Ongebruikte, verouderde versies verwijderen we in overleg, zodat ze niet per ongeluk opnieuw worden geactiveerd.
In Docker- en Kubernetes-omgevingen volstaat een update op de host niet. PHP zit in het image, en pas een nieuw gebouwd image met gepatchte basisstand, uitgerold op alle draaiende containers, dicht het lek. We controleren daarbij ook of oudere images in registries of deployments nog worden gebruikt. Details staan onder PHP in Docker-containers patchen.
Bij mod_php draait PHP direct in het Apache-proces. Het PHP-team schat het risico daar het hoogst in. Na de update moet Apache zelf daarom volledig worden herstart; alleen de configuratie opnieuw laden volstaat niet in elk geval.
Wat u van ons krijgt
- een patchprotocol per server: geïnstalleerde pakketten, versies, bron, tijdstip
- het bewijs dat alle PHP-processen zijn herstart
- een lijst van de gecontroleerde websites en functies
- aanwijzingen over systemen die niet gepatcht konden worden, met motivering
- een aanbeveling voor het vervolg, bijvoorbeeld bij PHP 8.2 vanwege het naderende einde van de ondersteuning
Wat wij van u nodig hebben
- Toegang: SSH met beheerdersrechten of paneeltoegang (Plesk, cPanel e.d.)
- Onderhoudsvenster: wanneer een korte herstart mag plaatsvinden
- Aanspreekpunt: voor vragen en voor de goedkeuring na de functiecontrole
- Back-ups: bevestiging dat er een actuele back-up is, of de opdracht er vooraf een te maken
- Aanwijzingen over maatwerk: bijzondere PHP-extensies of configuraties waarmee rekening moet worden gehouden
Bij shared hosting zonder eigen servertoegang kunnen wij zelf niet patchen. We helpen u dan bij uw hoster de juiste vragen te stellen en het antwoord te beoordelen.
Wat we niet beloven
De patchservice dicht het bekende lek. Hij beantwoordt niet of de server vóór de update al is gecompromitteerd, en verwijdert geen binnengebrachte schadelijke software. Wilt u dat weten, dan is de PHP2Shell-spoedhulp met sporenonderzoek de passende opdracht.
Voor PHP 8.1 en ouder zijn er geen officiële updates meer. Hier voeren we overbruggingsmaatregelen door en adviseren we de migratie naar een ondersteunde versie. Een compatibiliteitstoezegging voor uw CMS geven we niet uit het hoofd, maar we controleren die aan de hand van de systeemeisen van de fabrikant.
Veelgestelde vragen
Waarom toont mijn server na de update nog de oude PHP-versie?
Daar kunnen twee redenen voor zijn. Ofwel heeft de distributie een backport geïnstalleerd, waardoor het versienummer gelijk blijft terwijl de pakketstand gepatcht is. Ofwel draaien oude PHP-processen nog in het geheugen en moeten die worden herstart.
Welke PHP-versies dichten PHP2Shell?
Het lek is verholpen in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, gepubliceerd op 21 oktober 2026. Bij distributiepakketten telt de pakketstand die de aanbieder als gepatcht bevestigt.
Kan de update mijn website platleggen?
Een update binnen dezelfde hoofdversie, bijvoorbeeld van 8.3.35 naar 8.3.36, is in de regel onkritiek. Een korte herstart van de PHP-processen is wel nodig. Wij stemmen het tijdvenster met u af en controleren daarna de pagina's.
Is met de patch alles afgehandeld?
Voor het lek zelf wel, zodra alle processen zijn herstart. Of er vóór de patch al iemand is binnengedrongen, laat de patch niet zien. Daarvoor is een aparte controle nodig.