PHP dicht twee kritieke lekken nadat wereldwijd websites offline werden gehaald

PHP heeft een patch uitgebracht om twee kritieke kwetsbaarheden te dichten. De makers adviseren gebruikers om direct een update uit te voeren. Uit voorzorg en in afwachting van de patch waren vanmiddag wereldwijd veel websites offline gegaan, waaronder die van de Tweede Kamer, ziekenhuizen, Schiphol en Tweakers.

Wat is PHP?

PHP is een veelzijdige scriptingtaal die dynamische webpagina's kan aanmaken. Wereldwijd gebruikt 69,3 procent van alle websites PHP. PHP vormt de basis voor het veelgebruikte WordPress en zit ook in Joomla, Drupal, Magento en andere websoftware.

PHP heeft de patch uitgebracht voor PHP-versies 8.2 tot en met 8.5. De kwetsbaarheid zit in alle PHP-versies vanaf 5.4, die in 2012 uitkwam. Momenteel ondersteunt PHP alleen actief versie 8.2 en hoger. Websites die oudere versies van PHP gebruiken, kunnen gedwongen worden om te upgraden naar een nieuwere versie, wat technisch complex kan zijn.

Bepaalde functies van oudere PHP-versies hebben compatibiliteitsproblemen met nieuwe versies van de programmeertaal. Webontwikkelaars hebben al eerder gezegd dat upgraden een lastig proces kan zijn. Daardoor kunnen websites die een oudere PHP-versie gebruiken na de uitgave van de patch toch langer uit de lucht blijven. Zeker een kwart van alle websites die PHP gebruiken heeft een oudere versie van de programmeertaal.

Tweakers publiceerde een uitgebreid achtergrondverhaal over de kwetsbaarheden en de gevolgen.

Gevolgen nog onbekend

De Amerikaanse PHP Foundation zegt tegen het persbureau ANP dat er 'geen signalen' zijn dat kwaadwillenden de kwetsbaarheid momenteel misbruiken, aldus de NOS. Cloudflare spreekt dat tegen en heeft de eerste cyberaanvallen via PHP-meldingen al gemeld in een bericht op X. Of die aanvallen ook succesvol zijn, is niet bekend. Tweakers ziet ook in zijn logs dat er in de loop van de middag meer dan honderd keer op de kwetsbaarheid werd gescand.

PHP scoort de ernst van de kwetsbaarheid met een 9,2 op een schaal van 1 tot 10. Dat hoge cijfer is gebaseerd op de ernst van de kwetsbaarheid en hoe makkelijk die te misbruiken is.

Impact voelbaar

69,3 procent van alle websites wereldwijd gebruikt PHP als programmeertaal, dus websites namen massaal voorzorgsmaatregelen. Daardoor waren de gevolgen onmiddellijk voelbaar. Naar verwachting worden die voorzorgsmaatregelen snel opgeheven, maar veel diensten zijn op het moment van schrijven nog onbereikbaar.

Zo zijn verificatiediensten zoals DigiD niet bruikbaar. Ook websites van ziekenhuizen zoals het Jeroen Bosch Ziekenhuis zijn niet toegankelijk. Daardoor zijn online patiëntendossiers niet in te zien. Verder werd de Schiphol-app offline gehaald, waardoor reizigers geen actuele vluchtgegevens konden zien. Verschillende overheidswebsites van de provincies zijn ook niet bereikbaar. Daardoor kunnen burgers bijvoorbeeld commissievergaderingen zoals een debat niet volgen. Nationale nieuwswebsites zoals RTL Nieuws en Tweakers waren tijdelijk offline.

Update, 16.25 uur – Er stond foutief dat PHP tot en met versie 8.4 gepatcht zou worden. Dat moet 8.5 zijn en het artikel is daarop aangepast.

Reacties (101)

[Sjeefr]

Waar ik vooral benieuwd naar ben, maar tot op heden nog niet heb kunnen vinden: Wat moeten mensen doen die hun website laten hosten die geen VPS hebben, maar gewoon betalen voor server ruimte? Stel je hebt een website die al 2 jaar niet bijgewerkt is.. Lijkt mij niet dat elke hosting-boer opeens jouw Wordpress website gaat bijwerken, maar dat je handmatig iets moet doen om de juiste PHP versie te gebruiken?

Het lek is nog redelijk nieuw, dus voor nu heb ik mijn websites maar gewoon platgegooid totdat er meer info bekend is

[Noxious]

In dat geval is de hostingpartij verantwoordelijk voor het doorvoeren van de update; maar als jou website niet met de nieuwe versie overweg kan dan mag je zelf aan de slag.

[rwwtrains]

Over het algemeen kennen WordPress, drupal en andere cms weinig problemen met dit soort "kleine" updates.

[harrald]

Mits ze wel altijd zijn bijgehouden met updates en niet op een php versie draaien ouder dan 8.2. En dit zijn er nog heel veel!

[imqqmi]

Daarnaast zijn er nog veel php servers die op intranetwerken draaien, ook al lopen deze niet direct gevaar, maar als men ergens anders door binnenkomt hebben ze wel mogelijkheden verder te escaleren.

[olafmol]

dat is het hele idee van self-managed/un-managed, dat je het zelf doet. Als je de boel daar zelf niet update krijg je vroeg of laat natuurlijk wel "bezoek"

[marcel20091]

inloggen op je hosting en indien mogelijk daar je php versie ophogen . in directadmin is daarvoor veelal een mogelijkheid.

mocht je die oplossing niet hebben dan overleggen met je hosting provider

[PatrickH89]

Hostingboer gaat daar veel meer last van krijgen dan zijn klanten, dus nood om te updaten is er nu toch wel.

[IskaRiot]

Hangt wat af van je hosting, of zij de php binaries updaten of dat onder jouwe verantwoordelijkheid valt.

Indien zij de binaries beheren wordt het pas een hoop werk als je site op een oudere php versie draait dan 8.2, dan mag je site ook een php update krijgen om naar een recentere versie te gaan om te voorkomen dat die breekt.

Edit: Nog even melden dat je zelf moet instellen om je site op php >=8.2 te laten draaien als dat nog niet het geval is. De hosting zal dit niet aanpassen.

[Reactie gewijzigd door IskaRiot op 21 oktober 2026 16:31]

[chocochoco]

Website 2 jaar niet bijwerken incl niet kijken naar updates en welke php versie je hebt is natuurlijk sowieso vrij kansloos, want in 2 jaar heb je dan een hele berg aan gemiste kritische patches gemist.

Zelf weten welke php versie je hebt, en weten hoe het zit met je plugins, thema en algemene wordpress updates is wel het minste wat je mag verwachten als je zelf je website regelt.. Eigenlijk voor elke website, want met kwetsbaarheden heb je mogelijk niet enkel jezelf..

[Triblade_8472]

Ik heb zo'n oude site draaien\overgenomen. Je kan zelf de PHP versie bepalen. Deze loopt achter terwijl er een nieuwe site opgezet wordt.

Nu wordt het dus kiezen of delen. Blijven we op een kwetsbare versie draaien of gaat er een brakke site online. (of blijven we offline)

Wanneer er gepatched is ga ik kijken of ik naar de gepatchte versie kan met de oude site, zonder grote issues. Anders dan gaat de brakke site maar online. Het is in mijn geval toch puur informatief en geen spannende dingen verder.

Hoe dan ook.
Elke hoster die ik ken werkt automatisch Wordpress sites bij. Zo niet, zoek snel een andere hoster! Of zet de functie aan. Als je geen tijd hebt om het bij te houden, dan moet het automatisch.
En de PHP versie moet je jaarlijks ofzo ff checken en zelf ophogen. Goed testen of alles nog werkt, maar dat zal wel. Dit is voor zover ik het ken bij een aantal hosters een simpele toggle. (9/10 panels zijn DirectAdmin. Zoek naar "PHP Settings" onder "Account Manager".)

[mphilipp]

Lijkt mij niet dat elke hosting-boer opeens jouw Wordpress website gaat bijwerken, maar dat je handmatig iets moet doen om de juiste PHP versie te gebruiken?

Mijn host provider (Cloud86) heeft pro-actief ModSecurity rules uitgerold op alle servers en alle PHP installaties van de klanten. Dit in afwachting van de patch. Die gaan ze niet voor iedereen uitrollen, want iedereen kan op een andere release zitten en misschien moet je zelf nog iets aanpassen aan je site omdat ie de nieuwe versie niet trekt.

We are currently deploying new ModSecurity rules to all Shared, Managed WordPress, and Managed VPS servers to block exploitation attempts. Please note that these rules are a mitigation to reduce immediate risk, not a complete fix. We will deploy the new PHP versions, which address the underlying vulnerabilities, once they are made available later today.

Momenteel zijn ze bezig de patch beschikbaar te maken op alle servers. Kijken wanneer ie voor mij beschikbaar is.

[The Glitch]

Yes! Tweakers weer terug in de lucht, dus dan zal de patch er doorgevoerd zijn!


Heeft iemand -enig- idee hoe snel dit via Debian verspreid gaat worden? Want dan weet ik wanneer ik mijn servers bij kan werken - die staan nu fysiek uit

[DLabs]

Kan je zelf doen.. PHP pakketen zijn niet aan Debian verbonden.

[Reactie gewijzigd door DLabs op 21 oktober 2026 16:20]

[ETH0.1]

Hij bedoelt via een apt-get update, dat is afhankelijk van debian zelf
op Ubuntu is het nog niet beschikbaar

[Memori]

Via de Sury-source was het om 15:37 al beschikbaar: https://packages.sury.org/php

[The Third Man]

Die was er wel al: https://ubuntu.com/security/notices/USN-8948-1 , 15:40 live gekomen

[TheDevilOnLine]

Wij maken gebruik van https://packages.sury.org/php/ en daar zijn de updates al live

[fluffy1]

Het zit al in de debian-security repo. Ik heb hier net de update geïnstalleerd.

https://tracker.debian.org/news/1813677/accepted-php84-8427-1deb13u1-source-into-stable-security/

[To_Tall]

Waarom staan ze fysiek uit? je kan ze beter afsluiten dat er op de porten waar PHP achter draait niet routeerbaar zijn naar je server..

Of hoop je dat bij aanzetten van de server jij genoeg tijd hebt om je server te updaten voor je aangevallen wordt?

[The Glitch]

Omdat ik er fysiek bij kan en op dat moment fysiek uitzetten gewoon geen probleem was en en lekker vlot geregeld was. Tegen dat ik ze dus aanzet, zet ik even e.e.a. uit zodat ik ze wel kan bijwerken inderdaad.

Niet alles is van levensbelang dat het aan moet blijven "voor het aanblijven"

[Reactie gewijzigd door The Glitch op 21 oktober 2026 17:21]

[Brummetje]

Sury bied ze al direct aan, zojuist al onze Debian machines geupdate

[giantgiantus]

Het valt me op dat het in Nederland heel groot nieuws is, maar grote buitenlandse media outlets er amper aandacht aan besteden. Hoe is dat te verklaren?

[RobinNL]

Albert Heijn misschien, die vorige week voor de zekerheid de stekker eruit trok om erger te voorkomen?

Is een gokje hoor.

[giantgiantus]

Ja kan ik me voorstellen. Maar het is wel echt apart. Zowel buitenlandse nieuwssites en techsites hebben het maar heel beperkt online staan.

[MrTeamMate]

Denk dat het goed aansluit op het Ahold verhaal.

De gemiddelde Nederlander zal een artikel als dit gigantische snel klikken nu.

[laminaatplaat]

Op NPO Radio 1 werd deze vraag net ook gesteld door de presentator en daar werd als mogelijke redenen genoemd dat het door het nieuws werd opgepikt als item met een aantal bedrijven die offline gingen en dat dit een sneeuwbal effect zou kunnen zijn. Daarnaast zou de situatie bij Albert Heijn mensen ook geprimed kunnen hebben om op zo iets actie te ondernemen.

[gumtree]

Het was net vrij uitgebreid op het Oostenrijkse 16.00 uur journaal. Ook enkele grotere Oostenrijkse sites liggen plat, bijv. de ÖAMTC (oostenrijkse anwb)

[olafmol]

massa-hysterie (al zijn er her en der ook andere landen waar er sites offline zijn gehaald)

[Reactie gewijzigd door olafmol op 21 oktober 2026 16:23]

[Matanza]

US ligt nog te slapen. Azië is al aan het slapen.
In België is het ook best groot nieuws geworden. wel pas tegen 15u ...

Toevoeging:
Nu ze in de US ook wakker geworden zijn, komen daar ook meldingen vanaf oa NSA etc

[Reactie gewijzigd door Matanza op 21 oktober 2026 17:02]

[Tha Deo]

Ik onderhoud een website voor een stichting. Wordpress, php 7.4. Updaten php kan niet, want de website werkt dan niet meer. Het theme ondersteund het niet.

Wat kan ik doen (met het behouden van php 7.4, dus niet upgraden) om risico op aanvallen, etc. zoveel mogelijk te beperken?

NB ik snap de noodzaak tot updaten naar 8.5. Maar daar gaat langere tijd in zitten. Ik zoek dus een quick fix om risico’s nu zoveel mogelijk te beperken.

[pe0mot]

PHP7.4 updaten, niet naar 7.5 maar naar 7.4.x (versie van vandaag).

8.4.27 dus. Kun je vaak niet zelf in je Cpanel. Moet je hoster dus doen.

[Reactie gewijzigd door pe0mot op 21 oktober 2026 16:36]

[StroopStorm]

7.4 heeft toch helemaal geen security patch gekregen hiervoor?

[Brummetje]

Je haalt nu PHP 7.4 en 8.4 door elkaar 7.4 gaat geen update krijgen.

@Tha Deo ik zou een AI aan het werk zetten om heel eerlijk te zijn en de website gewoon minimaal PHP 8.2 gereed maken. Kan me niet voorstellen dat er iets opstaat wat niet geupgrade zou kunnen worden.

[Capsman]

php 7.4 is niet meer ondersteund, dus je moet toch echt je PHP versie bijwerken.

Vanwege de hoge impact heeft het PHP-team de fix wel gebackport naar de 7.4 release. Als je die echt echt echt nodig hebt, kun je die proberen zelf te compileren. Zie: https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619

Ik zou de gelegenheid aangrijpen om de site een keer goed bij te werken, anders blijf je met deze rommel zitten.

[RoestVrijStaal]

Ik zoek dus een quick fix om risico’s nu zoveel mogelijk te beperken.

Wat dacht je van "Never waste a good crisis"?

Dit is het moment om te onderstrepen dat er echt resources vrijgemaakt moeten worden om de website bij de tijd te brengen. Dat het nu extra (geld) kost komt door de vele afstel.

[Crack_david]

Is er meer nieuws over hoe Wordpress dit door gaat voeren? Aangezien het halve internet op Wordpress draait

[Kallik]

En wat verwacht je dat WordPress hieraan gaat doen? Dat is als vragen wanneer Tweakers een oplossing gaat bieden voor een beveiligingslek in Chrome.

[To_Tall]

dat heeft niets met wordpress te maken natuurlijk, Wordpress maakt gebruik van PHP.. Maar jij als beheerder van de server zal PHP moeten updaten..

Werk je in Docker.. Dan kan ik je zeggen de officiële container is al geupdate.
Werk je met alternatieve containers dan zal je of zelf binnen de container de update moeten uitvoeren of hopen dat de beheerder snel met een nieuwe versie komt.

[NaliXL]

Vreemd genoeg gaf docker exec -it <hash> php --version by mij na zojuist een pull the hebben gedaan nog PHP 8.3.35. Volgens php.net zou dat 8.3.36 moeten zijn. Vreemd.

[pietje63]

Ik heb mijn Synology webstation eerder vandaag uit gezet. Mis wel een aantal tools nu. Ben wel benieuwd of Synology snel met updates komt. Ik zal (gelukkig) niet de enige zijn, dus reken er wel op

[PatrickH89]

Heb je die rechtstreeks aan het internet gehangen (bijv port-forward)? Anders lijkt het risico me toch niet zo groot dat je alles uit moet gooien.

[Itsacon]

Eerste alinea zegt dat er updates zijn voor "versies 8.2 tot en met 8.4". Dit moet zijn "versies 8.2 tot en met 8.5".

[iCore]

Klopt, wou ik ook net aangeven

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Source: https://www.php.net/index.php#2026-10-20-1

[MWSAH]

Wel mooi, die Claude-made melding op Tweakers toen de site down was. Doe dan in ieder geval je best het niet Claude-generiek te laten lijken.

[Rub3s]

Lekker boeiend. Snelheid is belangrijker.

[Sander-D]

Ik wacht nog op bijgewerkte Docker containers. Dan kan ik mijn eigen spullen opnieuw bouwen en kan ik weer live.

[HollowGamer]

Ik wil toch even rechtzetten, waar ik al bang voor was. Deze kwetsbaarheid was dus wat ik begreep al bekend bij PHP. Dat deze vervolgens vroegtijdig gelekt wordt, is iets wat onderzocht moet worden. Het is wel opvallend dat dit de vorige keer ook gebeurde bij andere lekken, o.a. iets met Linux/Citrix?

Het stoort mij ook dat er nu een stortvloed van managers gaat komen, vooral in (semi-)overheid, die nu gaan roepen PHP te vervangen. Ik heb .NET, Javascript en zelfs Java al zien langskomen, en Rust zal waarschijnlijk het ideaal plaatje zijn, met de meeste kosten..

Het herschrijven brengt echt geen voordelen mee. Ubuntu (Canonical) heeft dit gedaan met sudo en hun bash/gnu utilities: sudo-rs heeft ernstige exploits gehad, en de naar rust geschreven utilities lieten opeens ander gedrag zien. Met dus corruptie en fouten ter gevolg. Is het beter toekomstperspectief gezien? Misschien, maar je hebt nu ook een grote deel buitenspel gezet die helemaal niet bekend zijn met rust, en geen idee hebben wat AI schrijft. Trek hier je parallel met PHP.

Daarnaast om de VVD'er uit te hangen: het herschrijven kost ontzettend veel geld (met of zonder behulp van AI). Ga DigiD maar eens opnieuw schrijven of alle website vervangen, waarna een zelfde exploits wordt gevonden in een 'rust' powered webengine.

Er is niets mis met PHP. Sterker nog, PHP8 is juist een flinke upgrade geweest, en pushed nog meer slechte zaken uit de engine. Niet omdat je die nog moest gebruiken, maar omdat software niet word bijgehouden. Dat zelfde ga je ook krijgen met Rust en Javascript/node. Windows is een voorbeeld hierin. Veel is oud, maar er is genoeg software wat prima draait met moderne oplossingen.

Er zijn te veel managers en bestuurders in Nederland, veelal zonder kennis. Daar maak ik mij het meeste zorgen over. Die mogen voor mij wel door AI vervangen worden, developers niet.

[Reactie gewijzigd door HollowGamer op 21 oktober 2026 17:57]

[StefanJanssen]

100% mee eens. Grote lekken kunnen in elk systeem zitten, overschakelen op iets anders vanwege "security" is niet nodig.

Als je er echt bang voor bent zul je je eigen OS moeten schrjiven. Kost misschien een stuk meer geld en tijd en je hebt dan nog steeds een lek systeem, maar dan ben je wel de enige die dit systeem gebruikt waardoor je waarschijnlijk een minder groot doelwit bent.

[satya]

Ik moet zeggen bij ons draaien de site op Microsoft / asp en daar is zelden (eigenlijk nooit) een security update met een dergelijke patch van toepassing.

[RoestVrijStaal]

Het stoort mij ook dat er nu een stortvloed van managers gaat komen, vooral in (semi-)overheid, die nu gaan roepen PHP te vervangen. Ik heb .NET, Javascript en zelfs Java al zien langskomen, en Rust zal waarschijnlijk het ideaal plaatje zijn, met de meeste kosten..

Het herschrijven brengt echt geen voordelen mee. Ubuntu (Canonical) heeft dit gedaan met sudo en hun bash/gnu utilities: sudo-rs heeft ernstige exploits gehad, en de naar rust geschreven utilities lieten opeens ander gedrag zien. Met dus corruptie en fouten ter gevolg. Is het beter toekomstperspectief gezien? Misschien, maar je hebt nu ook een grote deel buitenspel gezet die helemaal niet bekend zijn met rust, en geen idee hebben wat AI schrijft. Trek hier je parallel met PHP.

Daarnaast om de VVD'er uit te hangen: het herschrijven kost ontzettend veel geld (met of zonder behulp van AI). Ga DigiD maar eens opnieuw schrijven of alle website vervangen, waarna een zelfde exploits wordt gevonden in een 'rust' powered webengine.

Er is niets mis met PHP. Sterker nog, PHP8 is juist een flinke upgrade geweest, en pushed nog meer slechte zaken uit de engine. Niet omdat je die nog moest gebruiken, maar omdat software niet word bijgehouden. Dat zelfde ga je ook kijken met Rust en Javascript/node. Windows is een voorbeeld hierin. Veel is oud, maar er is genoeg software wat prima draait met moderne oplossingen.

Er zijn te veel managers en bestuurders in Nederland, veelal zonder kennis. Daar maak ik mij het meeste zorgen over. Die mogen voor mij wel door AI vervangen worden, developers niet.

Hahaha, heel herkenbaar. Dat moet me denken ten tijde van de Log4Shell dat managers vonden dat alles van Apache (en/of Java) "maar weg moest".

Het probleem is dat PHP zelf met versie 8 veel volwassener is geworden. Maar de meeste ontwikkelaars die het gebruiken niet.
Nog steeds moet ik collega's wijzen op simpele dingen als (return) typehints en zwakke conditie checks (bijv. `if ($amount == 0) {` i.p.v. het correctere `if ($amount <= 0) {` of `if ($inputText == "" ) {` i.p.v. `if (empty($inputText)) {` ).
En dan ben ik de enige in het team die daar op wijst

[HollowGamer]

Dat laatste ben ik ook met je eens. Zelfs als senior developer kan je dat overkomen, maar je hebt eigenlijk geen excuus meer met phpstan, linters en zelfs AI die je code kan reviewen.

Het maakt inderdaad niets uit. Er is ook niet iets met Apache (de webserver mijn voorbeeld). Ik vind nginx/caddy fijner om mee te werken, maar als het hele server rek werkt met onderhoudende Apache servers en een verandering is niet nodig, dan blijf je die gewoon onderhouden. Het lijkt nu dat AI ook gebruikt wordt om snel te gaan switchen, met alle gevolgen van dien.

[Reactie gewijzigd door HollowGamer op 21 oktober 2026 18:00]