php2shell: wat betekent dit voor jouw website?

Waarom raakt php2shell jouw website nu?

Met “php2shell” wordt de recente onrust rond twee ernstige PHP-kwetsbaarheden bedoeld. PHP draait volgens W3Techs nog altijd op ruim driekwart van de websites waarvan de servertaal bekend is. Voor jou als ondernemer is dit dus geen ver-van-je-bed-show, maar een risico dat direct raakt aan je website, formulieren en eventuele klantdata. In dit artikel zet ik uiteen wat er precies is gebeurd, hoe de bekendmaking zo uit de hand liep en wat je nu moet controleren.

Wat is er precies misgegaan bij PHP?

In gewone taal: er zaten twee ernstige beveiligingslekken in de kern van PHP, CVE-2026-109618 en CVE-2026-109619, waarmee een aanvaller onder specifieke omstandigheden code op de server kan uitvoeren of gevoelig geheugen kan uitlezen. Zonder wachtwoord, zonder account. Dat heet remote code execution: iemand draait dan opdrachten uit op jouw omgeving.

Het eerste lek ontstaat als een verzoek tegen de geheugenlimiet aanloopt op precies het verkeerde moment: PHP laat dan halfgemaakte interne gegevens achter en behandelt die later als geldig. Het tweede zorgt dat gegevens van het ene verzoek herbruikbaar zijn door het volgende op dezelfde werker. Het klinkt technisch, maar de uitkomst is simpel: de normale bescherming van de runtime valt weg. Beide lekken scoren 9,2 op 10 (kritiek) op de CVSS-schaal en raken, volgens onderzoek van Wiz, bijna elke PHP-release sinds versie 5.4.

Waarom liep de aanpak al sinds 2024 vast?

De eerste sporen verschenen tijdens een externe beveiligingsaudit die de PHP Foundation in 2024 liet afnemen, met geld van de Sovereign Tech Agency — de eerste audit in jaren. Uitvoerder Quarkslab meldde onder meer issues in het geheugenbeheer, en daar zagen ontwikkelaars het begin van het probleem achter de eerste lek. Een exploit leek theoretisch en er was geen concreet aanvalspad, dus het probleem verhing niet.

Toen de urgentie in 2026 duidelijk werd, bleek de fix lastig. Er lagen drie mogelijke oplossingen: één brak met bestaande code, één introduceerde een risico dat websites plat kan leggen, en één dwong duizenden extensies tot aanpassingen. Een klein team dat op consensus werkt, durft in zo’n situatie niet te kiezen. De Foundation noemt het later bij de naam: “we doen niet alsof — de vertraging was een structurele misser”. Voor jou betekent dit: een kwetsbaarheid kan lang “onder water” blijven, terwijl de kans op misbruik meegroeit.

Hoe werd het lek in 2026 opnieuw ontdekt?

Eind augustus 2026 melde onderzoeker Ryan Austin van beveiligingsbedrijf Calif via het OpenAI-programma Patch the Planet dat hij het onderliggende geheugenprobleem kan uitbaten tot code-uitvoering op afstand, met het model GPT-5.6 Sol als assistor. OpenAI maakte diezelfde dag melding van dezelfde hoofdoorzaak. Daarna demonstreerde Wiz extra aanvalsvectoren, waaronder het puur uitlezen van het geheugen van de webserver — met wachtwoorden en toegangscodes van bezoekers die net een formulier invulden. Als meerdere partijen onafhankelijk op hetzelfde patroon uitkomen, is de kans klein dat het om een randgeval gaat. Cloudflare bouwde begin oktober al beschermende WAF-regels, ruim vóór de publieke bekendmaking.

Waarom was de bekendmaking zo chaotisch?

Hier ging het op meerdere niveaus mis. CVSS is het systeem waarmee de ernst van een lek wordt ingeschaald (eerste CVSS-documentatie). Handig, maar niet feilloos. De tijdlijn:

  • tuesday 20 oktober, rond kwart vijf ’s middags: de twee CVE-identificatoren lekten op online fora — een Hacker News-post werd verwijderd, screenshots bleven rondslingeren — met bovendien een verkeerde score van 10,0 in plaats van 9,2. Beveiligingsbedrijf watchTowr bevestigde het lek en reproducteerde het.
  • 20 oktober ’s avonds (jaja deels Nederlandse tijd): PHP publiceerde een versnelde pre-announcement als reactie op het lek, en schoof de release op van 22 naar 21 oktober. CERT-EU riep organisaties al op zich voor te bereiden op spoedpatching.
  • 21 oktober in de nacht/middag: Cloudflare zei al tegen vroege aanvallen te kijken (CTO Dane Knecht, 07:43 UTC). Chainguard publiceerde al om 07:41 UTC — ruim zes uur vóór de release — patched container-images, en brak daarmee het embargo. De beveiligingsadvisories op GitHub gingen om 13:34 UTC online, 26 minuten vóór de geplande tijd. Rond 13:30 UTC stonden de releases 8.2.35, 8.3.36, 8.4.27 en 8.5.12 online — eerder dan gepland. In diezelfde ochtend verscheen per ongeluk een demo-video van een werkende aanval door Calif.

Exploitatie was al in gang gezet vóórdat de patches beschikbaar waren: naast Cloudflare melde Aikido om 09:18 UTC exploitatie in het wild. Een volledige tijdlijn heeft CybelAngel op een rij gezet, en Radware vatte het technisch samen. Wie alleen op nieuwtjes vertrouwde, wist aan het einde van 21 oktober nog niet wat veilig was en wat niet. Het is precies waarom je bij dit soort meldingen ook naar je eigen hostingomgeving moet kijken.

Wat betekent dit risico voor jouw hosting en applicatie?

Niet elke opstelling loopt even veel risico. Apache met mod_php is het riskantst: een aanval kan daar nog vóór je applicatiecode draait worden aangeroepen, met een werkende exploit op standaardinstellingen. Ook PHP-FPM, php-cgi, FrankenPHP en LiteSpeed verwerken webverzoeken en moesten gepatcht worden. Bij gedeelde hosting schermt een hoster veel af met isolatie en WAF-regels; bij een eigen VPS of server ligt die verantwoordelijkheid dichter bij jou. OWASP wijst al langer op verouderde componenten en foutieve configuratie als structurele risico’s; dit lek laat zien dat dat ook geldt voor de taalruntime zelf.

Welke stappen moet je nu zelf controleren?

  1. Controleer welke PHP-versie je site gebruikt.
    In je hostingpaneel of via je developer kun je dat meestal zien. Op PHP Supported Versions vind je welke versies nog ondersteund worden. Is de versie end-of-life, dan is dat een probleem, ook als de site nog “gewoon werkt”.

  2. Vraag je hoster of runtime-updates al zijn doorgevoerd.
    Wacht niet tot je iets leest in een nieuwsbericht. Vraag expliciet of jouw omgeving gepatcht is. De vaste versies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Het NCSC adviseert de updates met spoed (advisory 2026-0443). Er bestaan tijdelijke maatregelen, maar die beperken alleen specifieke aanvalspaden: updaten is de enige complete oplossing.

  3. Zoek verouderde installaties op.
    Denk aan oude testomgevingen, subdomeinen, oude contactformulieren en vergeten microsites. Juist daar staan vaak oude versies live.

  4. Controleer plugins, thema’s en CMS-versies.
    Een PHP-lek staat niet op zichzelf. Verouderde WordPress-plugins of thema’s vergroten de kans op misbruik.

  5. Loop contactformulieren en legacy-sites na.
    Dit zijn vaak de plekken waar aanvallers beginnen te testen. Zeker als daar uploadmogelijkheden of verouderde code in zit.

  6. Maak een back-up en test herstel.
    Een back-up die nooit getest is, is vooral een gerust gevoel. In onze kennisbank leest hoe je een back-up herstelt.

Persoonlijk adviseer ik om dit soort controles niet ad hoc te doen, maar als vaste maandelijkse routine. Het nadeel is dat je er discipline voor nodig hebt, en daar ontbreekt het in het MKB vaak aan.

Hoe helpt RDS-Online je om veilig te blijven?

Bij beheerde hosting nemen wij een deel van die zorg uit handen. We volgen runtime-updates, houden beveiligingsmaatregelen actueel en kijken mee als er een brede kwetsbaarheid speelt. Dat betekent niet dat je nooit meer hoeft te controleren. Wel dat je niet zelf elk technisch detail hoeft te volgen om veilig te blijven. Als er iets met jouw omgeving aan de hand is, kun je op support rekenen voor controle, uitleg en praktische vervolgstappen.

Wil je weten of jouw website veilig draait?

De kern is simpel: php2shell laat zien hoe snel een kwetsbaarheid in PHP veel websites raakt, zeker als versies oud zijn of updates blijven liggen. Controleer je PHP-versie, vraag je hoster naar patches en kijk ook naar oude formulieren, plugins en testomgevingen. Mocht je er niet helemaal uitkomen, neem dan gerust contact op. Dan kijken we samen of jouw website goed staat afgesteld. 🚀

Bronnen