PHP2Shell: twee kritieke PHP-lekken waar elke webshop nu iets mee moet

Er komt een noodpatch voor PHP aan, en als je een webshop hebt, gaat dit over jou. Niet over "de hosting" in het algemeen, maar over de software waar je Magento, WooCommerce of Shopware letterlijk op draait. Twee kritieke lekken in de kern van PHP zijn te vroeg uitgelekt, de fix volgt met spoed, en de verwachting is dat aanvallers er binnen enkele minuten na die fix op duiken.

Dit stuk legt uit wat er aan de hand is, wat wél en niet bevestigd is, en vooral: wat je nu concreet doet om je webshop te patchen en te wapenen. Geen paniekverhaal, wel een checklist die klopt.

Wat is er aan de hand?

Op 20 oktober 2026 lekten details van twee nog niet gepubliceerde PHP-kwetsbaarheden online, vóór de gecoördineerde disclosure en vóór er een patch bestond. Ze staan inmiddels geregistreerd als CVE-2026-109618 en CVE-2026-109619. Het PHP-securityteam beoordeelt beide als kritiek, met een CVSS v4.0-score van 9.2 (op een schaal tot 10).

Beide zijn remote code execution (RCE): het type lek waarbij een aanvaller jouw server code laat uitvoeren die hij zelf kiest. In de praktijk is dat zo'n beetje het ergste wat er bestaat. Wie code kan uitvoeren op je server, kan een webshell plaatsen, klant- en bestelgegevens uitlezen, een skimmer in je afrekenpagina hangen (Magecart) of je hele winkel platleggen.

Het lek is herdoopt tot "PHP2Shell", naar de naam van een exploit-tool die mee uitlekte. Securitybedrijf watchTowr bevestigt dat de kwetsbaarheden echt zijn en reproduceerde CVE-2026-109618. Sansec, het Nederlandse securitybedrijf dat gespecialiseerd is in Magento, verwacht massale misbruikpogingen binnen ongeveer een kwartier nadat de officiële fix verschijnt — omdat die fix zelf aanvallers precies laat zien waar ze moeten zoeken.

Waarom dit anders is dan een gewone Magento-patch

Dit is het belangrijkste punt om te begrijpen.

De meeste lekken waar je als webshop mee te maken krijgt, zitten in Magento zelf of in een extensie. Die los je op met een patch in je applicatie, en een WAF of een tool als Sansec Shield kan je in de tussentijd beschermen.

Dit lek zit niet in je webshop. Het zit in PHP zelf — de laag eronder, waar je hele shop op draait. Volgens Sansec slaat de aanval toe voordat je applicatiecode en je beveiligingstools überhaupt aan de beurt komen. Het gevolg: je kunt dit niet dichttimmeren met een aanpassing in Magento, een extensie of een WAF-regel. De fix moet op infrastructuurniveau: de PHP-versie op je server moet omhoog.

Dat maakt het ook een kwestie van wie je server beheert. Beheer je dat zelf, dan is dit jouw werk. Zit je bij een hoster of partij als wij, dan is het onze taak om klaar te staan en direct te updaten zodra de patch er is.

Wat betekent dit technisch?

Voor wie dieper wil: wat is een RCE in PHP nou eigenlijk, en waarom is dit een ander beestje dan een lek in een extensie?

PHP zelf is geschreven in C

Je Magento-code is PHP; maar de interpreter die die PHP draait, is een programma in C. C heeft geen automatisch geheugenbeheer, en dáár zit deze klasse bugs: niet in de logica van je webshop, maar in hoe de PHP-engine intern met geheugen omgaat. Een geheugenfout in die C-laag laat een aanvaller data overschrijven die de engine gebruikt om te bepalen welke instructies hij uitvoert. Lukt dat, dan draait de server code van de aanvaller in plaats van die van jou. Dat is remote code execution.

Waarom 9.2?

De CVSS v4.0-score vertelt je het profiel zonder dat de details publiek zijn: aanvalsvector over het netwerk (dus via een gewoon HTTP-request, niet alleen lokaal), lage complexiteit, en volledige impact op vertrouwelijkheid, integriteit én beschikbaarheid. Kortom: op afstand te misbruiken, en als het lukt ligt alles open.

De (nog onbevestigde) oorzaak

Eén rondgaande, niet-geverifieerde analyse wijst naar PHP's session.upload_progress — de functie die de voortgang van een bestandsupload bijhoudt in de sessie. De claim is een use-after-free: de handler bewaart een pointer naar sessiedata, die data wordt tijdens de request weer vrijgegeven, en de pointer wordt dáárna alsnog gebruikt. Zo'n "verweesde" pointer is precies het soort geheugenfout dat tot code-uitvoering kan leiden.

Belangrijk: dit staat niet in een officieel advies, spreekt zichzelf op punten tegen, en de bron die het rondstuurt verspreidt een kant-en-klare exploit-kit over onbeveiligde HTTP. Niet downloaden, niet draaien. Behandel de technische details als gerucht tot php.net het bevestigt.

Waarom je WAF of extensie dit niet redt

Als de oorzaak inderdaad in het verwerken van de upload (de multipart-POST) of de sessie-handler zit, dan slaat de bug toe terwijl PHP het request zelf aan het inlezen is — nog vóór één regel Magento-code draait. Je applicatiebeveiliging staat op dat moment letterlijk nog niet aan. Een WAF zou in theorie alle multipart-POST's kunnen blokkeren, maar dan sloop je ook elke normale bestandsupload, en volgens dezelfde analyse zit een tweede route juist in de multipart-parser. Daarom: de enige echte fix is de PHP-update.

SAPI: welke servers lopen risico

PHP draait via een "SAPI" — de koppeling tussen de webserver en de PHP-engine. De internet-gerichte varianten (php-fpm achter nginx, mod_php onder Apache, oudere php-cgi) verwerken requests van buiten en zijn dus de blootgestelde kant. De command-line variant (php CLI, voor cronjobs en scripts) krijgt geen requests van bezoekers en is vrijwel zeker niet de ingang. Vandaar de regel: patch wat vanaf internet bereikbaar is eerst.

Wat een aanvaller wint op een webshop

PHP draait meestal als de webserver-gebruiker (www-data). Wie code kan uitvoeren als die gebruiker, kan bij Magento zo bij app/etc/env.php — met je databasegegevens én de crypt key waarmee wachtwoorden en tokens versleuteld zijn. Vanaf daar: klant- en bestelgegevens, een webshell voor blijvende toegang, of een skimmer in je checkout-template die stilletjes creditcardgegevens aftapt. Dat laatste is precies het scenario waar Sansec dagelijks op jaagt, en de reden dat zij zo'n alarm slaan.

Een voorzorgsmaatregel (geen fix)

Dezelfde onbevestigde analyse suggereert dat session.upload_progress.enabled = Off in je php.ini één mogelijke route dichtzet. Dat is een omkeerbare, laag-risico instelling die je defensief alvast kunt zetten — maar zie het als een extra slot, níet als dé oplossing. De oplossing blijft de officiële PHP-update.

Wat is bevestigd — en wat (nog) niet

Eerlijk zijn over wat we op 21 oktober wél en niet zeker weten hoort erbij. De situatie is volop in beweging.

Bevestigd:

• Twee aparte CVE's: CVE-2026-109618 en CVE-2026-109619.
• Beide zijn RCE, beide CVSS v4.0 9.2 (kritiek).
• De details lekten op 20 oktober, vóór de patch.
• watchTowr heeft de kwetsbaarheid gereproduceerd.
• De PHP-securityrelease stond gepland voor 21 oktober 2026, 14:00 UTC (16:00 Nederlandse tijd), met de kanttekening dat PHP eerder kan uitbrengen als er misbruik opduikt.

Nog niet officieel bevestigd (op moment van schrijven):

• Welke PHP-versies precies kwetsbaar zijn. Onbevestigde rapporten noemen "PHP 5 en hoger", maar dat komt uit de banner van de exploit-tool, niet uit een officieel advies.
• Welke versies de fix krijgen. De verwachting is dat alleen de nog ondersteunde 8.x-takken een patch krijgen. Rondgaande (nog te verifiëren) versienummers zijn 8.2.35, 8.3.36, 8.4.27 en 8.5.12.
• De exacte technische oorzaak en of authenticatie nodig is.
• Misbruik in het wild — tot nu toe niet gerapporteerd.

De enige bron die telt voor de definitieve versienummers is php.net. Controleer die vóór je iets doet op basis van cijfers die je elders ziet.

Draait jouw webshop risico?

Vrijwel zeker ja, als je een PHP-webshop hebt. Magento, Adobe Commerce, WooCommerce (WordPress) en Shopware draaien allemaal op PHP. De vraag is niet óf je PHP gebruikt, maar welke versie en wie 'm beheert.

Extra aandacht voor twee groepen:

1. Webshops op een verouderde PHP-versie. Officieel ondersteunt PHP alleen nog 8.2 en hoger. Draai je nog op 8.1, 8.0, 7.x of ouder, dan krijg je waarschijnlijk helemaal geen fix. Een shop die stil blijft staan, wordt vanzelf een doelwit. Dit lek maakt dat pijnlijk concreet.
2. Oudere Magento 2- en Magento 1-shops. Een oude Magento-versie dwingt je vaak op een oude PHP-versie. Zit je daar vast, dan kun je deze patch niet eens draaien zonder eerst je Magento te upgraden. Dubbel risico.

Wat je nu moet doen — de checklist

1. Breng in kaart waar PHP draait

Niet alleen je productie-webshop. Ook je staging- en testomgevingen, oude shops die nog "even online" staan, en los draaiende servers. Elke PHP-installatie die vanaf internet bereikbaar is, is een ingang. Vergeet control panels (cPanel, Plesk) en Windows-servers met php.exe niet.

2. Zet een onderhoudsvenster klaar — nú, niet straks

De winst zit in snelheid. Zorg dat je (of je partij) klaarstaat om te patchen op het moment dat de fix verschijnt, niet pas de dag erna. Patch vanaf internet bereikbare systemen eerst.

3. Patch zodra de officiële versie er is

Update naar de gepatchte PHP-versie zodra php.net die publiceert. Draai je via een distributie (Debian, Ubuntu, RHEL) of een hoster, check dan ook hun backported pakketten — soms komt de fix daar in een ander versienummer, maar met dezelfde oplossing.

4. Zit je op end-of-life PHP? Dan is dit je wake-upcall

Krijg je geen fix meer (8.1 of ouder), dan heb je drie opties, in volgorde van voorkeur:

• Upgrade naar een ondersteunde PHP-versie (8.2+). Vaak betekent dit ook je Magento of WooCommerce meenemen.
• Tijdelijk offline halen of achter een VPN of WAF zetten tot de upgrade rond is.
• Niets doen is geen optie — dat is wachten tot je gehackt wordt.

5. Zet detectie aan op "PHP dat rare dingen doet"

Ook als je gepatcht hebt: monitoring is je vangnet. De verwachte manier waarop misbruik zich toont, is PHP dat onverwachte onderliggende processen opstart. Let op processen als php-fpm, php-cgi, httpd of apache2 die ineens dit soort child-processen starten:

• Shells: sh, bash, cmd.exe, powershell.exe
• Interpreters: python, perl
• Download-tools: curl, wget, nc, certutil.exe

En commando-patronen die wijzen op een reverse shell of verkenning: /dev/tcp/, fsockopen, mkfifo, of een webserver die ineens whoami, id of uname -a draait. Heb je geen EDR, dan geeft de gratis tool process-watcher van Florian Roth deze zichtbaarheid op Linux. Zet 'm in observe-modus aan.

6. Vermoed je dat het al mis is?

Isoleer de server, bewaar de webserver- en PHP-logs (overschrijf ze niet), en controleer op: nieuwe of gewijzigde bestanden in je webroot, onbekende webshells, nieuwe cronjobs of scheduled tasks, en nieuwe accounts. Bij een webshop: check je afrekenpagina en templates op ingevoegde scripts (skimmers). Laat bij twijfel een specialist meekijken.

Wat wij voor onze klanten doen

Voor de webshops die wij onderhouden geldt: we volgen de PHP-release op de voet en patchen zodra de fix er is, met voorrang voor shops die vanaf internet bereikbaar zijn. Shops op een verouderde PHP- of Magento-versie trekken we erbij om een route te plannen, want daar is de patch alleen niet genoeg. Hoe we beveiliging voor webshops inrichten, lees je op webshop security.

Heb je een webshop en weet je niet op welke PHP-versie je draait, of wie 'm zou moeten patchen? Dat is precies het soort vraag waar dit mee begint. Weet je het niet, dan is het antwoord vaak "niemand" — en dat is het risico. Neem gerust contact op.

Veelgestelde vragen

Ben ik kwetsbaar als mijn webshop goed beveiligd is?

Deze lekken zitten in PHP zelf, onder je applicatie. Een goed beveiligde Magento, een WAF of een securityplugin helpt hier niet tegen, omdat de aanval toeslaat voordat die laag aan de beurt is. De enige echte oplossing is je PHP-versie updaten.

Welke PHP-versie moet ik hebben?

Zodra de officiële fix er is, de gepatchte versie van je tak (verwacht in de 8.2-, 8.3-, 8.4- of 8.5-reeks). Zit je op 8.1 of ouder, dan krijg je geen fix en is upgraden naar 8.2+ de weg. Controleer de exacte nummers op php.net.

Hoe weet ik op welke PHP-versie ik zit?

Je hoster of je phpinfo() laat het zien, en in Magento kun je php -v op de server draaien. Weet je het niet, dan helpen we je het uit te zoeken.

Moet ik mijn webshop nu offline halen?

Alleen als je op een end-of-life PHP-versie zit die geen fix krijgt en je niet snel kunt upgraden. Voor ondersteunde versies is de beste zet: klaarstaan en patchen zodra de fix er is.

Is session.upload_progress uitzetten voldoende?

Nee. Dat is een voorzorgsmaatregel uit een onbevestigde analyse, geen vervanging voor de patch. Zet het gerust uit als extra slot, maar reken erop dat de PHP-update het echte werk doet.

---

Bronnen: Sansec, Huntress, watchTowr en de officiële securityreleases op php.net. Dit artikel is geschreven op 21 oktober 2026; cijfers over kwetsbare en gepatchte versies worden bevestigd via php.net.