Het beveiligingsteam van PHP heeft op woensdag 21 oktober 2026 een spoedupdate uitgebracht voor twee kritieke lekken. De veilige versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, staat in de beveiligingsmelding op php.net van 21 oktober 2026. Via de lekken kan een aanvaller zonder in te loggen code op de server uitvoeren. PHP is de programmeertaal waarop WordPress, WooCommerce, Joomla en veel andere websites draaien, dus dit raakt een groot deel van de websites van kleine bedrijven. Gegevens over de lekken lekten een dag eerder uit, en beveiligingsbedrijven verwachten dat aanvallers snel gaan zoeken naar servers die nog niet bijgewerkt zijn.
Stand van zaken op de avond van 21 oktober 2026: de update is uit, zie de beveiligingsmelding op php.net. Aanvallen in het wild zijn dan nog niet bevestigd: de twee lekken staan niet op de lijst van actief misbruikte lekken van CISA.
Wat er gebeurde
PHP schrijft in de aankondiging van 20 oktober 2026 dat beide lekken een score van 9,2 krijgen op de CVSS-schaal (versie 4.0), die tot 10 loopt. In de beveiligingsmelding van 21 oktober 2026 noemt PHP elke installatie kwetsbaar die webverzoeken afhandelt, via PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP of LiteSpeed. Het risico is volgens PHP het grootst bij mod_php: daar werkt een aanval al voordat de code van de website zelf draait. Voor PHP 8.1 en ouder komt er geen officiële update.
Volgens BleepingComputer van 20 oktober 2026 lekten de lekken die dag uit via een bericht op Hacker News. Beveiligingsbedrijf watchTowr bevestigde dat ze echt zijn en kon er een zelf nabootsen.
Sansec, een bedrijf dat webwinkels beveiligt, schrijft op 21 oktober 2026 dat alle webservers met PHP 5.4 of nieuwer geraakt zijn. PHP noemt zelf geen oudste geraakte versie. Sansec verwachtte massale aanvallen binnen een kwartier na de update, omdat aanvallers dan kunnen zien wat er veranderd is. Het lek zit volgens Sansec in PHP zelf, vóór WordPress of een webwinkel aan de beurt is. Een plugin of een update van je CMS lost het dus niet op.
Wat betekent dit voor jouw website
De eerste vraag is of je site op PHP draait. Bij WordPress, WooCommerce, Joomla, Drupal, Magento en PrestaShop is dat zo. Bij een sitebouwer zoals Wix, Squarespace of Shopify beheer je de server niet zelf; daar is het de taak van de aanbieder en hoef je niets te doen.
Draait je site op PHP, dan hangt de rest af van wie de server beheert:
- Gedeelde hosting of beheerde WordPress-hosting (de meeste kleine bedrijven). Je host installeert de update, niet jij. Kijk op de statuspagina of in de mail van je host of je site al op een van de veilige versies draait, of op een reparatie van de host zelf. Staat er niets, vraag het dan.
- Een eigen VPS of server. Installeer een veilige versie uit de beveiligingsmelding van 21 oktober 2026 zodra je pakketbron hem heeft, en herstart daarna PHP-FPM of de webserver. Haal je PHP uit de sury-pakketbron voor Debian, kijk dan of apt-get update geen waarschuwing met EXPKEYSIG geeft. Op een Debian 12-server die wij beheren bleef apt op 21 oktober 2026 daardoor op een oude versie staan: de ondertekeningssleutel van de bron was verlopen. Het nieuwe pakket debsuryorg-archive-keyring loste dat op, daarna kwam 8.3.36 gewoon binnen.
- Een webbouwer of bureau beheert je site. Vraag of zij dit direct oppakken en wanneer.
Kijk ook welke PHP-versie je site gebruikt. In WordPress staat dat onder Hulpmiddelen, Sitediagnose, tabblad Info, onderdeel Server. Alleen PHP 8.2, 8.3, 8.4 en 8.5 krijgen nog beveiligingsupdates, staat op de pagina met ondersteunde versies van php.net. PHP 8.1 en ouder krijgen geen officiële oplossing, en 8.1 is sinds 31 december 2025 niet meer ondersteund. Dat is geen kleine groep: volgens de statistieken van WordPress.org, opgevraagd op 21 oktober 2026, draait 36,4 procent van de WordPress-sites op PHP 8.1 of ouder, waarvan 16,1 procent op PHP 7.4. Zit jouw site daarbij, vraag je host dan om een overstap naar 8.3 of nieuwer, of om een eigen oplossing voor jouw versie. Test na zo’n overstap of je formulieren en je webwinkel nog werken, want oude plugins doen het op een nieuwe PHP-versie niet altijd.
Plugins verwijderen helpt niet tegen een lek in PHP zelf. Zorg wel voor een recente backup, voor het geval een overstap misgaat.
Kijk na het bijwerken of er onbekende beheerders of bestanden op je site staan. Hoe je dat in WordPress doet, lees je in ons stuk over de hack bij UpdraftPlus.
Wat FWRD hiermee doet
Een FWRD-site draait niet op PHP: de sites en het platform zijn gebouwd in TypeScript en Astro, en er staat geen PHP-code in. Wie een FWRD-site heeft, hoeft dus niets bij te werken. Wat het verder betekent om niet op WordPress te draaien, staat op de vergelijking met WordPress. Wil je weten hoe je eigen site ervoor staat, doe dan de gratis websitecheck.
Wil je weten waar jouw site staat?
Doe de gratis diagnose. Je ziet meteen wat je site nodig heeft om beter gevonden te worden.
Bronnen
- PHP.net: Upcoming Critical PHP Security Release, 20 oktober 2026
- PHP.net: Security advisory, critical remote code execution vulnerabilities, 21 oktober 2026
- CISA: Known Exploited Vulnerabilities Catalog, opgevraagd 21 oktober 2026
- PHP.net: ondersteunde versies, opgevraagd 21 oktober 2026
- WordPress.org: PHP-versies van WordPress-sites, opgevraagd 21 oktober 2026
- BleepingComputer: PHP warns admins of two critical flaws, emergency patches coming tomorrow, 20 oktober 2026
- Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619, 21 oktober 2026
- Tweakers: PHP waarschuwt voor twee ernstige bugs die makkelijk uit te buiten lijken, 21 oktober 2026
Geschreven met AI door FWRD. Bronnen en cijfers staan in de tekst gelinkt.