PHP2Shell: het kritieke lek in PHP en wat je nu moet doen

De update is er. Op woensdag 21 oktober bracht het PHP-team nieuwe versies uit die twee kritieke lekken dichten. In het nieuws gaan ze rond onder de naam PHP2Shell. Beide lekken krijgen een ernstscore van 9,2 op 10. Iemand van buitenaf kan er, zonder in te loggen, eigen code mee laten draaien op de server van je website. In het slechtste geval neemt hij zo je site over of komt hij aan de gegevens die erop staan.

Het PHP-team is duidelijk: bijwerken is de enige veilige oplossing, en dat liefst meteen.

Wat moet je nu doen?

1. Zoek uit wie je website beheert. Meestal is dat je webbouwer, een bureau of je hostingpartij.
2. Stuur die vandaag nog een bericht. Je kan dit gewoon kopiëren: "Draait mijn website al op de PHP-update van 21 oktober? Kan je me laten weten welke PHP-versie er nu op staat?"
3. Kijk het versienummer na dat je terugkrijgt. Hieronder lees je welke versie je minstens nodig hebt.
4. Lukt bijwerken niet vandaag? Laat je site dan tijdelijk offline halen tot het wel gebeurd is. Dat is precies wat Smartschool vandaag gedaan heeft.

Welke PHP-versie heb je nodig?

Het eerste getal van je PHP-versie bepaalt naar welke update je moet. Je site is in orde vanaf:

• PHP 8.5: versie 8.5.12
• PHP 8.4: versie 8.4.27
• PHP 8.3: versie 8.3.36
• PHP 8.2: versie 8.2.35

Staat er PHP 8.1 of ouder op je site? Dan krijg je geen officiële update van het PHP-team, want die versies worden niet meer ondersteund. Sommige hostingpartijen voorzien zelf nog een oplossing, maar reken daar niet op. Een overstap naar een nieuwere versie is dan nodig, en daar hoort meestal ook wat testwerk bij.

Ook PHP 8.2 kan niet lang meer mee. Die versie krijgt na 31 december 2026 geen beveiligingsupdates meer, dus plan die overstap best nu al in.

Waarom zijn Smartschool en andere sites offline?

Uit voorzorg. Smartschool, DPG Media (met onder meer Tweakers) en in Nederland DigiD hebben hun systemen vandaag tijdelijk uitgezet tot alles bijgewerkt is. Ze zijn dus niet gehackt. Bij een lek van deze ernst nemen grote organisaties liever geen enkel risico.

Beveiligingsbedrijf Cloudflare ziet wel al pogingen om het lek te misbruiken. Het Centrum voor Cybersecurity België zag op het moment van schrijven nog geen aanvallen op Belgische websites. Paniek is dus niet nodig, wachten is wel een slecht idee.

Nu de details van het lek publiek zijn, gaan aanvallers op zoek naar sites die nog niet bijgewerkt zijn. Hoe sneller jouw site de update krijgt, hoe kleiner de kans dat hij ertussen zit.

Draait je site op WordPress? Dan moet je iets doen

Draait je site op WordPress, WooCommerce, Drupal, Joomla, Laravel of Statamic? Dan draait hij op PHP, en dan moet de update er bij jou ook op. Een update van WordPress zelf of van je plugins volstaat hier niet. Het lek zit in PHP, de programmeertaal eronder, en die wordt apart bijgewerkt op de server.

Gebruik je Shopify, Wix of Squarespace? Dan beheert dat platform zelf de servers en hoef je niets te doen.

Zelf PHP bijwerken op je server

Dan nog dit, wat technischer:

• Werk PHP bij via de pakketten van je Linux-distributie. Die hebben de patches vooraf gekregen. Gebruik je de repository van Remi (rpms.remirepo.net), dan komt daar vandaag geen update en stap je best over op de pakketten van je distributie.
• Herstart daarna PHP-FPM of Apache, anders draaien je workers nog op de oude versie. Controleer met php -v en via een phpinfo()-pagina of de webserver echt de nieuwe versie gebruikt.
• Het risico is het grootst bij Apache met mod_php, maar ook PHP-FPM, php-cgi, FrankenPHP en LiteSpeed zijn kwetsbaar. De lekken zijn bekend als CVE-2026-109618 en CVE-2026-109619.

Kan je niet meteen bijwerken?

Dan kan je in afwachting een paar instellingen aanpassen. Het PHP-team zegt er zelf bij dat die het risico verkleinen, maar je server niet veilig maken. Ze zijn een noodoplossing voor een paar uur, geen vervanging van de update.

; Haalt het geheugenlimiet weg waarmee CVE-2026-109618 uit te lokken is.
memory_limit = -1

; Laag houden. 8M als je site geen uploads nodig heeft, anders 32M.
post_max_size = 8M
upload_max_filesize = 6M

; Blokkeert de bekende aanvalsroute van CVE-2026-109619.
session.upload_progress.enabled = 0

; Enkel op PHP 8.5.
fatal_error_backtraces = 0

Waar je op moet letten:

• Zet dit in php.ini, in je FPM-pool of in de configuratie van Apache, zodat het geldt voordat het verzoek ingelezen wordt. Via ini_set() of een .user.ini werkt het niet.
• Zorg dat een applicatie de memory_limit niet zelf terug kan zetten. In een FPM-pool doe je dat met php_admin_value[memory_limit] = -1. Kijk ook na of geen enkele pool, map of applicatie er toch weer een limiet op zet.
• Zonder geheugenlimiet kan één verzoek de hele server vol laten lopen. Leg daarom een grens op het niveau van de container of de cgroup, liefst zo dat alleen het betrokken proces gestopt wordt. Gebruik daar geen RLIMIT_AS of RLIMIT_DATA voor, want die kunnen het lek net uitlokken.
• Herstart daarna alle PHP-workers.

De volledige uitleg staat in de security advisory van het PHP-team.

Twijfel je?

Weet je niet wie je site beheert, krijg je geen duidelijk antwoord, of draait je site op een oude PHP-versie? Stuur me een bericht of bel me op 0479 15 42 14. Dan kijk ik met je na op welke versie je site draait en wat er moet gebeuren.