Twee kritieke PHP-lekken: waarom tijdig updaten vaak belangrijker is dan de patch zelf

Vandaag om 16:00 uur (14:00 UTC) brengt het PHP-team een spoedupdate uit voor twee kritieke kwetsbaarheden: CVE-2026-109618 en CVE-2026-109619. Beide zijn beoordeeld met een CVSS v4.0-score van 9.2 en maken het mogelijk om op afstand code uit te voeren op een server, zonder dat daarvoor een geldig account nodig is. Omdat details van de lekken al vóór de geplande disclosure uitlekten - inclusief een proof-of-concept die inmiddels rondgaat onder de naam "php2shell" - is de release een dag naar voren gehaald.

Dit is precies het soort moment waarop het verschil tussen bedrijven die snel reageren en bedrijven die weken achterlopen met updates, zichtbaar wordt. Niet de techniek achter de kwetsbaarheid is dan het belangrijkst - het is hoe snel u de patch daadwerkelijk toepast.

Waarom tijdig updaten de kern is, niet een bijzaak

PHP draait onder een groot deel van het web: WordPress, veel maatwerkwebsites en talloze bedrijfsapplicaties leunen erop. Een kwetsbaarheid in de PHP-core zelf is niet iets dat u met wat extra code in uw eigen website oplost - de fix moet op het niveau van de serversoftware komen. Zodra zo'n lek bekend is, race je tegen de klok:

• Scanners zijn razendsnel. Binnen uren na een publieke CVE beginnen geautomatiseerde scans het internet af te zoeken naar servers die nog niet gepatcht zijn.
• Een leak voor de officiële release is extra risico. Omdat de details van CVE-2026-109618 en CVE-2026-109619 al circuleren vóórdat de patch beschikbaar was, hebben aanvallers een voorsprong die ze normaal niet zouden hebben.
• "Het draait toch gewoon" is geen beveiligingsstrategie. Een kwetsbare server valt pas op als er al iets misgaat - meestal te laat.

Dit geldt niet alleen voor deze PHP-bugs. Vrijwel elk groot beveiligingsincident van de afgelopen jaren - van kwetsbare WordPress-plugins tot lekken in bekende serversoftware - had één ding gemeen: er was al een patch beschikbaar, maar die was nog niet toegepast. De kwetsbaarheid zelf is het probleem van de softwareleverancier; hoe snel u de oplossing uitrolt, is uw eigen verantwoordelijkheid.

Wat we weten over deze twee kwetsbaarheden

• Waar het om gaat: twee kritieke fouten in de PHP-core die remote code execution mogelijk maken - een aanvaller kan code laten uitvoeren met de rechten van het PHP-proces, puur via het netwerk en zonder in te loggen.
• Ernst: CVSS v4.0 9.2. Voor het lekken circuleerden ook berichten over een score van 10.0, maar 9.2 is de correcte waarde.
• Welke versies: de kwetsbaarheid zelf is aanwezig vanaf PHP 5, dus ook in alle versies daarna. Een patch is in ieder geval te verwachten voor PHP 8.0 en hoger; dat is de ondergrens die met zekerheid wordt gefixt. Niet uitgesloten is dat ook PHP 7 - hoewel die versie al enige tijd end-of-life en dus niet meer ondersteund is - alsnog een patch krijgt, gezien de ernst van het lek. Dat is overigens ook meteen een les op zich: wie nog op een uitgefaseerde PHP-versie draait, staat sowieso al met een been buiten de deur, patch of geen patch.
• Actief misbruikt? Op dit moment zijn er geen gemelde actieve aanvallen bekend en staat het lek niet in de CISA KEV-lijst, maar de gelekte proof-of-concept verandert dat beeld snel zodra de details breder bekend worden.

Updaten vanaf 16:00, maar wat doet u tot die tijd?

Zodra de patch beschikbaar is, is de meest voor de hand liggende stap simpel: update zo snel mogelijk naar de gepatchte PHP-versie. Voor de meeste websites op gangbare hosting of een beheerde server gaat dat via de hostingpartij of een geautomatiseerde update; bij eigen serverbeheer is het een handmatige actie die vandaag nog op de planning moet staan - niet "volgende week wel een keer".

In de tussentijd, tot de update er is of is doorgevoerd, is het een reële afweging om een kwetsbare site tijdelijk offline te zetten of achter extra beveiliging (zoals een WAF) te plaatsen, zeker voor een website die:

• gevoelige klantgegevens verwerkt of een loginomgeving heeft;
• op een oudere of niet meer ondersteunde PHP-versie draait;
• door de aard van het lek, de hoge ernst en de voorsprong die aanvallers nu al hebben, een aantrekkelijk doelwit is.

Dat voelt als een zware maatregel, maar een paar uur offline tijd weegt in vrijwel alle gevallen niet op tegen een gehackte website, gestolen data of een server die wordt ingezet voor verdere aanvallen. Een korte onderbreking is te plannen en te communiceren; herstel na een inbraak is dat niet.

Als het toch misgaat

Is een website toch gecompromitteerd - via dit lek of een ander - dan is snelheid opnieuw de bepalende factor. Hoe langer een malafide script of achterdeurtje blijft staan, hoe groter de schade: verspreiding naar andere bestanden, misbruik voor spam of verdere aanvallen, en reputatieschade zodra zoekmachines of bezoekers de site als onveilig markeren.

Voor WordPress-sites die gehackt zijn of waarbij malware is aangetroffen, biedt Mark ICT WordPress herstel: we ruimen de besmetting op, dichten het gat waar de aanvaller doorheen kwam en zorgen dat de site weer schoon en bijgewerkt online staat.

Niet achter de feiten aan blijven lopen

Het echte probleem bij incidenten als deze is zelden de kwetsbaarheid zelf - die hoort nu eenmaal bij software. Het probleem is dat updates te laat of helemaal niet worden toegepast, omdat niemand het signaleert of omdat het "er wel eens bij komt". Wilt u dat dit soort kritieke updates bij uw website of server niet van toeval afhangt? Neem contact op om te bespreken hoe we het updateproces en de beveiliging van uw omgeving structureel kunnen borgen.