Het PHP-beveiligingslek van oktober 2026 uitgelegd

Wat er is gebeurd

Er zijn twee fouten gevonden in PHP zelf (CVE-2026-109618 en CVE-2026-109619). Met een speciaal gemaakt verzoek kan een aanvaller zonder in te loggen eigen code uitvoeren op de server van een website. In de praktijk kan dat betekenen dat hij de server overneemt: hij past de website aan, steelt gegevens of gebruikt de server om anderen aan te vallen.

Wie er risico loopt

• Elke website die op PHP draait, welke PHP-versie ook, tot hij is bijgewerkt naar een versie met de beveiligingsupdate. Dat geldt voor de meeste websites met WordPress, Joomla, Drupal, Magento en PrestaShop.
• Niet je website zelf als die is gemaakt met een kant-en-klaar websiteplatform dat geen PHP gebruikt, zoals Shopify, Wix of Squarespace. Andere systemen die je gebruikt, kunnen nog wel kwetsbaar zijn.
• Ook andere software: sommige apparaten, intranetten en bedrijfsapplicaties bevatten PHP. Het NCSC houdt een lijst bij van producten die kwetsbaar zijn.

Twijfel je over je website? Zo controleer je het. Of doe onze gratis check.

Wat je nu moet doen

Het NCSC adviseert, in deze volgorde:

1. Werk PHP bij naar een versie met de beveiligingsupdate. Meestal doet je hostingpartij, webbouwer of webbureau dit.
2. Lukt bijwerken nog niet? Pas dan de tijdelijke beveiligingsmaatregelen van het PHP-project toe.
3. Lukt geen van beide? Overweeg dan de website offline te halen tot het is opgelost.
4. Controleer op sporen van een inbraak, zeker als het bijwerken even duurde.
5. Let op updates van de makers van andere software en apparaten die je gebruikt.

In welke PHP-versies het lek is gedicht

• PHP 8.5: gedicht in 8.5.12 en nieuwer
• PHP 8.4: gedicht in 8.4.27 en nieuwer
• PHP 8.3: gedicht in 8.3.36 en nieuwer
• PHP 8.2: gedicht in 8.2.35 en nieuwer

PHP 8.1 en ouder krijgen helemaal geen beveiligingsupdates meer. Websites op die versies moeten overstappen op een ondersteunde versie. Dat vraagt meer testwerk dan een gewone update, dus begin vandaag.

Voor ontwikkelaars

Alle manieren om PHP voor websites te draaien zijn kwetsbaar (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed); mod_php heeft het hoogste risico. Kun je niet direct patchen? Op php.net staan tijdelijke maatregelen, waaronder memory_limit=-1 afdwingen in de serverconfiguratie, strengere limieten voor verzoeken en multipart-data, en session.upload_progress.enabled=0. Die verkleinen het risico, maar vervangen het bijwerken niet.