PHP-crisis over landsgrenzen: patchen is nodig, maar paniek?

De kern

Twee kritieke fouten in PHP, de programmeertaal achter veel websites, webapplicaties en beheerinterfaces, veroorzaakten op 21 oktober een internationale patchoperatie. Het Nederlandse en Britse NCSC, de Noorse NSM en de Finse autoriteit Traficom waarschuwden organisaties. Nederlandse en Finse overheidsdiensten haalden uit voorzorg websites of diensten tijdelijk offline. De PHP-ontwikkelaars brachten dezelfde dag beveiligde versies uit.

CVE-2026-109618 en CVE-2026-109619 kunnen onder bepaalde omstandigheden leiden tot uitvoering van opdrachten zonder dat de aanvaller eerst hoeft in te loggen. De eerste waarschuwingen waren zeer urgent. Later onderzoek bracht nuance: misbruik blijkt complexer dan aanvankelijk gevreesd en grootschalige uitbuiting werd op 23 oktober minder waarschijnlijk geacht. Het NCSC kende één buitenlands bericht over mogelijk misbruik, maar kon niet bevestigen dat de aanval was geslaagd.

Die nuance verandert het handelingsadvies niet: installeer de officiële updates. Zij verandert wel de toon. Een kritieke score is geen bewijs dat iedere website is gehackt. Evenmin bewijst de afwezigheid van een alarm dat een systeem schoon is. Goede weerbaarheid combineert snel patchen met inventarisatie, logging, herstel en duidelijke communicatie.

Wat is er gebeurd?

PHP draait op de server en bouwt daar dynamische webpagina’s op, verwerkt formulieren en praat met databases. Bezoekers zien meestal niet dat PHP wordt gebruikt. Ook bekende pakketten zoals WordPress, Drupal, Joomla, Roundcube en Zabbix kunnen ervan afhankelijk zijn. Daarnaast zit PHP in sommige netwerkapparaten, managementportalen en andere producten waarin de gebruiker de onderliggende runtime niet zelf beheert.

De kwetsbaarheden gaan over geheugen en de scheiding tussen opeenvolgende webverzoeken. Bij een fout met geheugentoewijzing kan PHP worden onderbroken terwijl interne gegevens nog niet volledig zijn opgebouwd. Opruimcode kan die ongeldige gegevens vervolgens als betrouwbaar behandelen. Bij de tweede fout kan interne toestand van een verzoek blijven bestaan nadat het bijbehorende geheugen is vrijgegeven. Een volgende aanvraag binnen hetzelfde proces kan die verouderde toestand gebruiken. Onder de juiste omstandigheden kan geheugenbeschadiging uitmonden in uitvoering van code.

PHP publiceerde versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Linuxdistributies en leveranciers met langdurige ondersteuning kunnen eigen versienummers en backports gebruiken. Voor PHP 7.4, 8.0 en 8.1 kwamen minimale broncode-backports beschikbaar, maar deze lijnen worden door het PHP-project niet regulier ondersteund. “Mijn nummer staat niet in het lijstje” is daarom geen betrouwbare conclusie; controleer het pakketadvies van jouw besturingssysteem of leverancier.

Op 26 oktober publiceerde PHP bovendien opnieuw gebouwde Windowspakketten met een gerepareerde Brotli-bibliotheek voor een afzonderlijke kwetsbaarheid, CVE-2026-111497. Wie Windowsbinaries rechtstreeks gebruikt, moet dus ook controleren of de nieuwste build met het achtervoegsel -1 is geïnstalleerd.

Waarom doet dit ertoe?

Een webserver verwerkt vaak persoonsgegevens, sessiecookies, wachtwoordherstel, formulieren en koppelingen met andere diensten. Overname kan vertrouwelijkheid, juistheid én beschikbaarheid raken. Een aanvaller kan gegevens lezen, website-inhoud veranderen of de dienst stilleggen. Een defensieleverancier of vitale organisatie kan daarnaast via een kwetsbaar leveranciersportaal of beheerproduct een vervolgroute naar gevoeliger systemen krijgen.

HTTPS voorkomt dit niet. TLS versleutelt het verkeer tussen browser en server, maar de server moet het verkeer ontsleutelen om het te verwerken. Als juist de PHP-runtime op die server wordt misbruikt, blijft het hangslotje zichtbaar terwijl het eindpunt mogelijk onbetrouwbaar is.

De tijdelijke uitval bij overheden laat een nuttige afweging zien. Beschikbaarheid is belangrijk, maar soms is gecontroleerd offline gaan veiliger dan een onbeheerst risico accepteren. Het doel is niet “altijd online” maar diensten voorspelbaar kunnen beperken, repareren en herstellen.

Wat betekent dit voor jou?

Als gewone bezoeker hoef je niet te onderzoeken welke PHP-versie een website gebruikt. Wees wel alert wanneer een vertrouwde site plotseling om een extra login, download of betaling vraagt. Open de dienst via je eigen bladwijzer of typ het officiële adres zelf. Gebruik unieke wachtwoorden en multifactorauthenticatie, zodat gestolen gegevens niet automatisch toegang tot andere accounts geven.

Beheer je een website, vraag je hoster expliciet of de PHP-runtime en niet alleen WordPress of een plugin is bijgewerkt. Op gedeelde hosting kan de leverancier de runtime beheren; in een eigen server, container of appliance ligt de verantwoordelijkheid anders. Controleer ook testomgevingen, oude subdomeinen en producten met een ingebouwde webinterface.

Installeer geen willekeurig “PHP2Shell-fixscript” uit sociale media. Tijdens een crisis verschijnen behulpzame én onbetrouwbare scripts. Gebruik het officiële PHP-advies, je besturingssysteemleverancier en de productleverancier. Bewaar voor een wijziging relevante logs en configuratie, zodat onderzoek mogelijk blijft.

Wat betekent dit voor je digitale voetafdruk?

Een website bevat vaak meer persoonlijke informatie dan de zichtbare pagina’s: contactformulieren, IP-adressen, accounts, concepten, reserveringen, klantdossiers en authenticatielogs. Een beheerinterface kan bovendien gebruikersnamen, netwerkstructuur en apparaatgegevens verraden. Minder bewaren beperkt de buit.

Back-ups zijn onmisbaar voor herstel, maar vormen extra kopieën van dezelfde voetafdruk. Bewaar ze buiten de webserver, versleutel ze, beperk toegang en test terugzetten. Vergeet ook familie en collega’s niet: een buitgemaakt klantenbestand kan later worden gebruikt voor overtuigende phishing waarin echte namen, afspraken of leveranciers voorkomen.

Een haalbaar stappenplan

ZIEN — vind alle PHP. Inventariseer websites, containers, appliances, beheerschermen, ontwikkel- en herstelomgevingen. Noteer versie, eigenaar, internetblootstelling en leverancier.
RICHTEN — bepaal de veilige doelversie. Gebruik PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of een aantoonbare leverancier-backport. Gebruik op Windows de bijgewerkte build voor de Brotli-fix.
LATEN HANDELEN — maak besluiten expliciet. Wijs aan wie mag patchen, een site offline mag zetten, bewijs bewaart en gebruikers informeert. Vraag leveranciers schriftelijk om productstatus en planning.
TOETSEN — controleer meer dan de homepage. Test inloggen, formulieren, betalingen, achtergrondtaken, monitoring en logtransport. Onderzoek afwijkende processen, bestanden, accounts en uitgaand verkeer.
LEREN — ruim structureel op. Vervang end-of-life runtimes, verwijder vergeten omgevingen en leg vast waarom ontdekking, patching of herstel langer duurde dan gewenst.

Voor de techneuten

Technische oorzaak en dreigingsmodel

De PHP Foundation classificeert beide fouten als kritieke unauthenticated RCE met CVSS v4.0 9,2. CVE-2026-109618 betreft onveilige afhandeling van een out-of-memorysituatie tijdens request cleanup. CVE-2026-109619 betreft requestgebonden globale toestand die een vrijgegeven backing store kan overleven en door een later verzoek in dezelfde worker wordt gebruikt. PHP noemt onder meer PHP-FPM, mod_php, php-cgi, FrankenPHP en LiteSpeed als potentieel geraakt; het aangetoonde risico was het hoogst bij mod_php.

Het dreigingsmodel begint bij een internetbereikbaar proces dat webverzoeken met PHP afhandelt. Een geslaagde keten kan code uitvoeren met de rechten van de PHP-worker. De uiteindelijke impact hangt af van procesrechten, secrets, schrijfbare paden, netwerksegmentatie en bereikbare databases. Er is geen publieke basis om iedere storing of onbekend bestand aan deze CVE’s toe te schrijven.

De actuele attributiestatus is eenvoudig: er is geen actor genoemd. Het NCSC meldde op 23 oktober één onbevestigd buitenlands signaal van mogelijk misbruik en achtte grootschalige exploitatie minder waarschijnlijk dan eerst gedacht. Dat is een operationele beoordeling, geen bewijs van afwezigheid.

Technisch uitgewerkte oplossing

Discovery. Combineer pakketbeheer, SBOM’s, containerregistries, runtime-telemetrie en leverancierinventaris. Zoek niet alleen naar php-processen; appliances en producten kunnen de runtime verbergen.
Patch. Gebruik officiële packages en valideer repository, digitale handtekening of package provenance. Herstart alle workers en controleer de actieve runtime via een beheerde methode. Een bijgewerkt bestand op schijf bewijst niet dat oude processen weg zijn.
Tijdelijke mitigatie. Volg uitsluitend het PHP-advies. Genoemde instellingen beperken specifieke paden maar zijn geen volledige oplossing. Leg iedere wijziging en terugdraaiactie vast; verkeerde geheugen- of uploadlimieten kunnen beschikbaarheid schaden.
Containment. Laat de webworker met minimale rechten draaien, maak applicatiecode waar mogelijk read-only, scheid databases en beheersegmenten en beperk uitgaand verkeer. Een reverse proxy of WAF kan volumebeperking en detectie toevoegen, maar vervangt de patch niet.
Detectie. Correlleer web-, PHP-, proces-, bestands-, identity-, DNS- en egresslogs. Let op nieuwe processen onder het webaccount, onverwachte child-processen, gewijzigde opstartmechanismen, onbekende accounts en netwerkverbindingen. Een requestpatroon alleen bewijst geen RCE.
Herstel. Bij bevestigde code-uitvoering: isoleer, behoud forensisch bewijs, herbouw vanaf vertrouwde images, roteer databasesleutels, API-tokens, salts, beheerderssessies en certificaten die bereikbaar waren. Controleer gekoppelde systemen op vervolgactiviteit.

Test het terugvalplan op applicatieniveau. Controleer niet alleen een HTTP 200-respons, maar ook queueworkers, cronjobs, uploads, sessies, caching, TLS-terminatie, databaseverbindingen en observability. Houd een aantoonbaar schone vorige release beschikbaar, maar rol niet terug naar een kwetsbare runtime.

De belangrijkste acties

Vraag hoster en leveranciers om aantoonbare productstatus.
Patch alle internetgerichte PHP-runtimes en herstart workers.
Bewaar logs voordat je mogelijk bewijs overschrijft.
Controleer appliances en vergeten omgevingen afzonderlijk.
Herbouw en roteer geheimen wanneer code-uitvoering niet kan worden uitgesloten.

Wat weten we nog niet?

Of het gemelde buitenlandse exploit-signaal daadwerkelijk succesvol was.
Hoeveel embedded producten nog wachten op een leveranciersupdate.
Welke organisaties door ontbrekende inventaris niet weten dat zij PHP gebruiken.
Hoeveel aanvallers de complexe aanvalsketen betrouwbaar kunnen operationaliseren.

Bronnen

Dit artikel bevat uitsluitend verdedigende informatie en geen exploitrecept.