Samenvatting: Op 21 oktober 2026 verscheen een noodrelease van PHP die twee kritieke lekken dicht (CVE-2026-109618 en CVE-2026-109619, samen bekend als PHP2Shell). Beide laten een aanvaller zonder inloggen code uitvoeren op de server. Er zijn publieke proof-of-concepts en meldingen van misbruik. Het NCSC waarschuwt en nam eigen sites uit voorzorg offline. In dit artikel lees je wat er gebeurde, welke risico’s je loopt, welke stappen je als MKB-bedrijf nu zet en hoe MonkeySoft kan helpen.
De meeste beveiligingsnieuws gaat over een product: Exchange, SharePoint, een firewall. Dit keer zit het lek in de taal waarop een groot deel van het web draait. WordPress, Joomla, Drupal, Laravel, webshops en maatwerk bedrijfssoftware: ze draaien allemaal op PHP. Als de basis een gat heeft, helpt het niet dat je eigen applicatie netjes is bijgewerkt.
1. Wat gebeurde er?
Het gaat om twee kwetsbaarheden in PHP zelf, niet in een plugin of CMS. Beide hebben een CVSS v4.0-score van 9,2 en zijn te misbruiken zonder authenticatie.
De twee kwetsbaarheden
- CVE-2026-109618: een probleem waarbij PHP geen geheugen meer heeft terwijl een verzoek nog wordt opgebouwd. Daardoor blijven interne gegevens half ingericht achter, en de opruimstap behandelt die later alsof ze in orde zijn.
- CVE-2026-109619: een probleem met resterende toestand. Gegevens leven langer dan het geheugen waarnaar ze verwijzen, waardoor een volgend verzoek op hetzelfde PHP-proces met restanten kan werken.
Je hoeft de techniek niet te doorgronden. De kern: een aanvaller stuurt een verzoek naar een webserver en kan in het ergste geval eigen code laten draaien. Volgens beveiligingsonderzoekers van Datadog is de aanval te reproduceren met een ongeauthenticeerd HTTP POST-verzoek.
De tijdlijn
- 20 oktober: details lekken op sociale media, nog voor de geplande bekendmaking op 22 oktober.
- 21 oktober: PHP brengt gepatchte versies uit. Volgens onderzoeksbureau watchTowr zijn er vanaf die dag aanvallen waargenomen.
- 23 oktober: het NCSC meldt dat het eerste signalen van succesvol misbruik onderzoekt, en dat proof-of-concepts bekend zijn.
- 26 oktober: volgens watchTowr voegt het Amerikaanse CISA CVE-2026-109618 toe aan de catalogus met actief misbruikte kwetsbaarheden.
Welke versies zijn gepatcht?
De fixes zitten in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Alles daaronder binnen dezelfde tak is kwetsbaar. Voor PHP 7.4, 8.0 en 8.1 komt geen officiële release. Er bestaan minimale broncode-patches, en sommige Linux-distributies en leveranciers van langdurige ondersteuning leveren eigen gepatchte pakketten. Oudere takken, zoals PHP 7.3 en lager, krijgen niets. Het CERT-EU-advies geeft hetzelfde beeld van de ernst.
2. Waarom is dit belangrijk?
Drie redenen maken dit anders dan de gemiddelde kwetsbaarheid.
Het raakt elke PHP-website
De lekken gelden voor elke manier waarop PHP webverkeer afhandelt: PHP-FPM, Apache met mod_php, php-cgi, LiteSpeed en FrankenPHP. Het risico is volgens watchTowr en mysites.guru het hoogst bij Apache met mod_php, omdat een aanval daar kan slagen voordat jouw applicatiecode ook maar draait. Een inlogscherm of beveiligingsplugin in je CMS ziet daar niets van.
Je eigen updatebeleid helpt maar half
Je kunt WordPress, plugins en je eigen code perfect bijhouden en toch kwetsbaar zijn, omdat PHP door je hostingpartij wordt beheerd. De meeste websitebeheerders kunnen alleen kiezen uit versies die de host heeft geïnstalleerd. Bij een gedeelde omgeving ben je afhankelijk van hun tempo.
De tijd tussen patch en misbruik is kort
Het NCSC waarschuwt dat AI het misbruik kan versnellen. Dat past bij wat we eerder zagen bij autonome AI-aanvallen: aanvallers scannen breed en schakelen razendsnel zodra er een proof-of-concept is. Wachten op een teken van misbruik is dan te laat. Het NCSC adviseert daarom de updates nu te installeren, en kwetsbare systemen offline te houden tot ze zijn gepatcht.
Dat het NCSC zelf zijn website uit voorzorg offline haalde, zegt genoeg over de ernst. Meerdere andere organisaties, onder andere overheden, deden hetzelfde.
3. Wat zijn de risico’s?
Code-uitvoering op een webserver is geen klein incident. Wat een aanvaller daarmee kan, hangt af van waar die server in je netwerk staat en wat erop draait.
Mogelijke gevolgen
- Overname van de webserver. De aanvaller plaatst een webshell en houdt toegang, ook nadat je later patcht.
- Datadiefstal. Databasewachtwoorden, API-sleutels en klantgegevens staan vaak in configuratiebestanden op dezelfde server.
- Doorbouwen naar binnen. Staat de webserver in hetzelfde netwerk als je kantoor- of bedrijfssystemen, dan is het een opstap naar meer.
- Misbruik van je reputatie. Phishingpagina’s, spam of malware die via jouw domein worden verspreid.
- Ransomware. Een gekaapte server is een bekend beginpunt. Lees ook onze gids over ransomwarebescherming voor het MKB.
AVG en Cyberbeveiligingswet
Raken persoonsgegevens in verkeerde handen, dan kan een meldplicht datalek bij de Autoriteit Persoonsgegevens gelden. Dat geldt ook als je webshop of klantportaal door een lek in je hostingomgeving is geraakt. Voor organisaties die onder de Cyberbeveiligingswet vallen, of die leverancier zijn van zulke organisaties, is tijdig patchen onderdeel van de zorgplicht. We legden dat eerder uit in ons artikel over de registratieplicht en de gevolgen voor MKB-toeleveranciers. Een klant die vraagt hoe snel jij kritieke lekken oplost, vraagt in feite naar dit scenario.
Waarom dit lek zich lastig laat afvangen
Volgens de maintainers is er geen configuratie-instelling die het probleem volledig verhelpt. Er zijn tijdelijke maatregelen die bepaalde aanvalsroutes blokkeren, maar die zijn geen vervanger voor een update. Sommige veelgedeelde firewallregels veroorzaakten bovendien storingen, zoals editors in WordPress en Joomla die niet meer konden opslaan. Een haastige noodmaatregel kan dus ook schade doen.
4. Wat moet een MKB-bedrijf doen?
Begin met overzicht, daarna patchen, daarna controleren. In die volgorde.
Stap 1: Breng in kaart waar PHP draait
Maak een lijst van alles wat op PHP draait en bereikbaar is vanaf internet:
- Je bedrijfswebsite en eventuele landingspagina’s.
- De webshop.
- Klantportalen en maatwerk bedrijfssoftware.
- Interne tools die toevallig via internet bereikbaar zijn.
- Websites die een externe partij voor je beheert.
Vergeet vergeten systemen niet: oude testsites, een campagnewebsite van twee jaar terug. Juist die worden zelden bijgewerkt.
Stap 2: Controleer de PHP-versie die echt draait
Kijk niet alleen op de commandoregel. Die kan een andere PHP-build tonen dan de versie die je website bedient. Vraag je hostingpartij welke versie actief is en of het gepatchte pakket is geïnstalleerd. Bij distributies kan de fix zijn doorgevoerd zonder het versienummer te wijzigen. Vraag dan om de changelog of beveiligingsmelding.
Stap 3: Update en herstart
Installeer een gepatchte versie en herstart alle PHP-processen. Zonder herstart blijft de oude code in het geheugen draaien. Draai je zelf een server, dan valt dit onder je eigen patchproces. Bij Plesk geeft de leverancier eigen instructies voor de meegeleverde PHP-versie, zie het Plesk-artikel.
Stap 4: Kun je niet direct patchen? Beperk de blootstelling
- Haal het systeem tijdelijk van internet of beperk toegang tot bekende IP-adressen.
- Zet een WAF ervoor, maar zorg dat de server niet ook direct via IP bereikbaar blijft.
- Gebruik de tijdelijke maatregelen die PHP beschrijft alleen als noodoplossing, en test of je site nog werkt.
Stap 5: Controleer op inbraak
Omdat er sinds 20 oktober is misbruikt, is patchen alleen niet genoeg. Controleer of er al iets is gebeurd.
- Zoek in de logs naar ongebruikelijke POST-verzoeken sinds 20 oktober.
- Kijk naar nieuwe of gewijzigde bestanden in webmappen, vooral PHP-bestanden op plekken waar ze niet horen.
- Controleer op onbekende gebruikers, geplande taken en uitgaand verkeer.
- Wissel databasewachtwoorden en API-sleutels als je twijfelt.
Het patchen van een gehackte server haalt een webshell niet weg. Dat zagen we ook bij het SharePoint-lek waar patchen niet genoeg was: wie al binnen is, blijft binnen tot je de sleutels roteert en de toegang opruimt.
Stap 6: Plan de upgrade van verouderde PHP-versies
Draai je PHP 8.1 of ouder, dan krijg je geen officiële fix en loopt ondersteuning af of is die al weg. Ook PHP 8.2 krijgt volgens mysites.guru nog maar tot 31 december 2026 beveiligingsupdates. Plan de overstap naar een ondersteunde tak, en reserveer tijd om je applicatie te testen. Oude maatwerksoftware heeft hier soms werk nodig.
Stap 7: Leg het vast
Noteer wat je hebt gecontroleerd, wanneer je hebt gepatcht en wie dat deed. Voor audits, klantvragenlijsten en een eventuele melding aan de toezichthouder is dat bewijs waardevol.
Veelgemaakte fouten
- Alleen WordPress of plugins updaten. Het lek zit onder je CMS. Die updates lossen het niet op.
- Aannemen dat de host het wel regelt. Vraag het na. Je hebt een bevestiging nodig, geen aanname.
- Vertrouwen op een WAF alleen. Bereikbaar via IP betekent dat de WAF kan worden omzeild.
- Niet herstarten na de update. De oude versie blijft actief tot de processen opnieuw starten.
- Patchen zonder te controleren. Misbruik is al waargenomen, dus kijk ook achterom.
- Vergeten websites. Oude sites van een vorige marketingcampagne zijn een geliefd doelwit.
5. Hoe kan MonkeySoft hierbij helpen?
MonkeySoft bouwt en beheert zelf PHP-omgevingen, waaronder Laravel-toepassingen en WordPress-websites. Daardoor kennen we de praktijk van dit soort noodupdates van binnenuit.
- Inventarisatie en snelle controle. We brengen samen met je in kaart welke systemen op PHP draaien, welke versie echt actief is en wat nu direct moet gebeuren.
- Websitebeheer met updates en monitoring. Via onze dienst WordPress-websites en ons platform SitesMonkey houden we updates, back-ups en beveiligingsmonitoring bij, zodat je niet zelf hoeft uit te zoeken of een noodrelease is doorgevoerd.
- Maatwerk software op een ondersteunde basis. Draait je bedrijfssoftware op verouderde PHP, dan helpen we bij de upgrade. Meer over onze aanpak lees je bij maatwerk software en in ons artikel over Laravel en FilamentPHP voor bedrijfssoftware.
- Herstel en continuïteit. Is er toch iets misgegaan, dan helpt een goede back-upstrategie je snel weer online. Zie onze gids over back-up en continuïteit.
Een kanttekening: MonkeySoft voert zelf geen penetratietests uit. Wil je een onafhankelijke toets op je omgeving, dan werken we samen met betrouwbare externe partijen en pakken we de bevindingen daarna op.
Veelgestelde vragen over PHP2Shell
Welke PHP-versies zijn veilig na PHP2Shell?
De gepatchte versies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Zit je op een lagere uitgave binnen dezelfde tak, dan ben je kwetsbaar. Voor PHP 8.1 en ouder is er geen officiële update. Daar heb je een pakket van je distributie of leverancier nodig, of een upgrade naar een ondersteunde tak.
Beschermt een WAF of een beveiligingsplugin mij?
Niet volledig. De maintainers stellen dat alleen een update het probleem echt oplost. Een WAF kan een tijdelijke extra drempel zijn, maar een server die direct via het IP-adres bereikbaar is, omzeilt die laag. Een plugin in je CMS helpt niet als de aanval plaatsvindt voordat de applicatiecode draait.
Hoe weet ik welke PHP-versie mijn website gebruikt?
Vraag het aan je hostingpartij of kijk in het beheerpaneel. Let op: de versie op de commandoregel kan afwijken van de versie die je website bedient. Distributies voeren soms een fix door zonder het versienummer te wijzigen, dus controleer ook de changelog of de beveiligingsmelding van je leverancier.
Moet ik na het updaten nog iets doen?
Ja. Herstart alle PHP-processen zodat de nieuwe versie echt wordt gebruikt. Controleer daarna je logs op vreemde verzoeken sinds 20 oktober en kijk of er onverwachte bestanden of gebruikers zijn bijgekomen.
Wat als mijn systeem op PHP 7.4 of 8.0 draait?
Dan is dit het moment om een upgrade te plannen. Voor die takken bestaan alleen broncode-patches, geen officiële binaire releases. Draait de omgeving onder een beheerde dienst, vraag dan wanneer de leverancier een gepatchte versie levert en hoe lang ze die nog ondersteunen.
Wat je deze week moet onthouden
PHP2Shell is een zeldzaam geval: een kritiek lek in de runtime onder bijna elke PHP-website, met publieke proof-of-concepts en waargenomen misbruik. Zorg dat je weet waar PHP draait, controleer de versie die echt actief is, update en herstart, en kijk daarna of er al iemand binnen is geweest. Verouderde PHP-versies zijn vanaf nu een zichtbaar risico dat je op de planning moet zetten.
Wil je weten of jouw websites en bedrijfssoftware veilig zijn? Neem contact op met MonkeySoft voor een vrijblijvend gesprek. Kijk ook op onze pagina over Microsoft Cloud als je je bredere IT-omgeving wilt laten doorlichten.
Bronnen: Datadog Security Labs | watchTowr: CVE-2026-109618 FAQ | CERT-EU advisory 2026-018 | Dutch IT Channel over de NCSC-waarschuwing | mysites.guru