PHP2Shell: wat het kritieke PHP-lek betekent voor je website of webshop

In het kort

• Wat speelde er? Twee kritieke lekken in PHP zelf, samen PHP2Shell genoemd. Een aanvaller kon daarmee zonder in te loggen code uitvoeren op een server. De details lagen al op straat voordat er een patch was.
• Wat hebben wij gedaan? Vanaf 13:30 hebben we uit voorzorg alle klantomgevingen op PHP offline gehaald. Na de release hebben onze hostingpartners de patches doorgevoerd. Wij testen elke omgeving voordat hij weer online gaat.
• Waar staan we nu? Al onze Magento-webshops, Laravel-applicaties en de websites op Prepr CMS zijn weer online. Onze Craft CMS-websites komen één voor één terug, net als de WordPress-websites. Shopify en Webflow zijn de hele tijd online gebleven.
• Wat moet jij doen? Host je via ons? Dan zetten wij je omgeving weer online zodra die veilig is. Host je zelf, gebruik je een maatwerk Shopify-app of adverteer je online? Lees dan verderop wat je moet regelen.

Tijdlijn

Alle tijden zijn Nederlandse tijd, nieuwste update bovenaan.

Wat was er aan de hand?

Het ging om twee lekken met de codes CVE-2026-109618 en CVE-2026-109619, in de wandelgangen “PHP2Shell” genoemd. Het PHP security team gaf beide de score 9.2 op de CVSS-schaal (Patchstack). Dat is kritiek: een aanvaller kon via deze lekken zonder in te loggen zijn eigen code op een server uitvoeren.

Normaal blijven zulke lekken geheim tot de patch klaarstaat. Dit keer niet. Op 20 oktober lekten de details uit, waarna PHP de release een dag naar voren haalde (Huntress). Er werd al misbruik gemeld voordat er een oplossing was. Op 21 oktober rond 15:35 verscheen de fix (ma.ttias.be).

Waarom raakt dit zoveel websites?

De meeste securitylekken zitten in één plugin of één platform. Dit lek zat een laag dieper, in PHP zelf. Magento, WordPress, Craft CMS en Laravel draaien allemaal op PHP. Het maakt dus niet uit hoe goed de code van je website is: draait de server een kwetsbare PHP-versie, dan is je site kwetsbaar.

Een aanvaller die code op je server kan uitvoeren, kan in principe alles. Denk aan klantgegevens inzien, een skimmer in je checkout plaatsen of de API-sleutels van je koppelingen stelen. Voor een webshop betekent dat niet alleen technische schade, maar ook omzetverlies, mogelijk een meldplicht bij de AP en verlies van vertrouwen.

Welke PHP-versies zijn veilig?

• PHP 8.2 tot en met 8.5: veilig vanaf 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Elke eerdere versie is kwetsbaar (Codeable).
• PHP 7.4, 8.0 en 8.1: geen nieuwe release, wel een losse patch van het PHP security team. Zie dat als noodoplossing.
• PHP 7.3 en ouder: geen patch van PHP zelf. Sommige hostingpartijen patchen oudere versies wel, bijvoorbeeld via CloudLinux. Ook dan blijft overstappen het advies.

Wat hebben wij gedaan?

Om 07:00 ontvingen we de melding van Sansec. Vanaf dat moment zijn we stap voor stap aan de slag gegaan:

1. In kaart gebracht. We hebben uitgezocht welke klantomgevingen op PHP draaien.
2. Afgestemd. We hebben nauw geschakeld met onze hostingpartners en met verschillende partijen over de status van de patch.
3. Uit voorzorg offline gehaald. Vanaf 13:30 hebben we alle klantomgevingen op PHP offline gehaald: Craft CMS- en WordPress-websites, Magento-webshops en Laravel-applicaties. Zo liep geen enkele omgeving risico op het moment dat de details openbaar werden. Al onze klanten hebben daarover bericht gekregen.
4. Gepatcht. Direct na de release zijn onze hostingpartners begonnen met het doorvoeren van de patches.
5. Getest en weer online gezet. Zodra een omgeving is bijgewerkt, testen we alles en zetten we hem weer online.

Waarom hebben we alles offline gehaald?

Offline gaan kost omzet en vindbaarheid. Dat realiseren we ons. Maar bij een lek waarvan de details al op straat lagen en waarbij misbruik werd gemeld, woog dat voor ons niet op tegen het risico op een overgenomen server of gelekte klantdata. Een website die een middag of avond dicht is, is een stuk goedkoper dan een datalek met klant- en betaalgegevens.

Een onderhoudspagina was geen optie. PHP verwerkt een binnenkomend verzoek al voordat je CMS aan de beurt is. De onderhoudsmodus van Magento of WordPress beschermt je daarom niet. Afschermen moest op serverniveau.

Waar staan we nu?

• Craft CMS: sinds 19:00 komen onze Craft CMS-websites één voor één weer online.
• Magento: alle webshops op PHP 8.2 of hoger waren rond 18:20 weer online, die op oudere versies rond 20:40.
• Laravel: alle applicaties waren om 21:30 weer online.
• Prepr CMS: de websites op Prepr waren om 20:00 weer online.
• WordPress: deze komen stap voor stap terug. Voor oudere PHP-versies worden extra patches uitgerold, waardoor het herstel van sommige websites langer kan duren.
• Shopify en Webflow: deze platformen draaien niet op PHP en zijn de hele tijd online gebleven.

De tijdlijn bovenaan houden we bij tot alle omgevingen weer online zijn.

Wat moet jij doen?

Host je via ons?

Dan zetten wij je omgeving weer online zodra die gepatcht en getest is. Draait je website op PHP 8.1 of ouder? Dan is een upgrade naar PHP 8.3 of nieuwer niet langer uit te stellen. Versie 8.2 krijgt eind 2026 al geen updates meer, die kun je dus beter overslaan. Een patch voor een oude versie is een pleister, geen oplossing.

Adverteer je online?

Stem met je marketingpartner af of je campagnes, zoals Google Ads of Meta, gepauzeerd moeten blijven tot je website weer online is. Zo geef je geen budget uit aan bezoekers die op een offline website terechtkomen.

Gebruik je een maatwerk Shopify-app of koppeling?

Shopify zelf is veilig. Draait een app of koppeling van je winkel op een eigen PHP-server? Dan is die server wél kwetsbaar. Shopify waarschuwt app-ontwikkelaars daar zelf voor, omdat zo’n server vaak de sleutels tot je winkel bevat. Vraag je developer om die server te patchen en daarna de sleutels te vervangen.

Host je zelf of bij een andere partij?

Neem dan contact op met je hostingprovider om af te stemmen wat verstandig is. Loop daarnaast deze punten na:

1. Check je PHP-versie. Zie de lijst hierboven. Weet je niet op welke versie je draait? Vraag het na bij je hostingpartij of developer.
2. Check elke server, niet alleen je website. Denk ook aan je testomgeving, achtergrondprocessen, een losse WordPress-site, een intranet of een eigen tool. Elke kwetsbare server is een ingang.
3. Vervang je sleutels en wachtwoorden ná de update. Draaide je server op een kwetsbare versie? Ga er dan van uit dat API-sleutels, tokens van koppelingen en andere geheimen zijn ingezien. Vervang ze pas als de server gepatcht is. Een nieuwe sleutel op een kwetsbare server kan op dezelfde manier worden gestolen.
4. Gepatcht is niet automatisch schoon. Laat na de update een malwarescan draaien en controleer op onbekende bestanden, nieuwe admin-accounts, afwijkend gedrag in je checkout en ongebruikelijk verkeer op je koppelingen.

Is je server nog niet gepatcht? Haal de site dan offline op serverniveau of laat alleen leesverzoeken toe. Een WAF zoals Cloudflare of het blokkeren van uploads via formulieren verkleint het risico, maar maakt je server niet veilig (Sansec). Alleen de update lost het lek op.

Security is geen eenmalige actie

PHP2Shell was geen bug in je website. Het was een herinnering dat je website op een stack draait die onderhoud vraagt. Wie PHP-versies, updates en monitoring structureel regelt, hoeft bij een lek als dit niet te improviseren.

Bronnen: Patchstack, Sansec, Huntress, Vincent Schmalbach, ma.ttias.be, Codeable, Help Net Security, Shopify. Laatste update: 21 oktober 2026, avond.