PHP2Shell is gepatcht. Het echte werk begint nu.

2026-10-21 · ShoppingPartnerLab Redactie · Security

*21 okt 2026 · @LMC AI*

De patch is uit, maar het gevaar niet

Op 21 oktober 2026 bracht PHP noodupdates uit voor PHP2Shell: twee kritieke lekken in PHP zelf, CVE-2026-109618 en CVE-2026-109619. Beide hebben een CVSS v4.0-score van 9.2. Ze maken het mogelijk om zonder in te loggen code uit te voeren op een server.

De dag ervoor lekten de details uit, nog vóór de gecoördineerde disclosure. Daarop ging een flink deel van het Nederlandse internet uit voorzorg offline: Tweakers, de Tweede Kamer, het NCSC, Security.NL, DigiD en MijnOverheid. Ook mediasites van DPG Media en Roularta en Magento-webshops schakelden hun publieke kant uit.

Inmiddels is de patch er. Toch is het probleem niet voorbij. In dit artikel lees je wat er technisch misging, wat je nu moet doen, waarom het risico na de patch juist toeneemt, en waarom wij als ShoppingPartnerLab denken dat dit pas het begin is.

Wat er technisch misging

Volgens de officiële advisory van het PHP-securityteam gaat het om twee verschillende fouten in de manier waarop PHP verzoeken afhandelt:

CVE-2026-109618: RCE via OOM-corruptie. Als PHP tijdens een verzoek geen geheugen meer krijgt (out of memory), kan de verwerking stoppen terwijl interne requestdata maar half is opgebouwd. Bij het opruimen van het verzoek behandelt PHP die halve data daarna als geldig.
CVE-2026-109619: RCE via verouderde globale state. Interne gegevens van een verzoek kunnen blijven bestaan nadat het bijbehorende geheugen al is vrijgegeven. Een volgend verzoek dat door dezelfde worker wordt afgehandeld, kan die verouderde gegevens gebruiken voordat ze worden gereset.

In beide gevallen gebruikt PHP geheugen dat niet (meer) klopt. Wie kan sturen wat daar terechtkomt, kan code laten uitvoeren als de gebruiker waaronder PHP draait.

Drie dingen maken dit zo ernstig:

Het zit onder de applicatie. De aanval kan plaatsvinden voordat WooCommerce, Magento of Laravel één regel code uitvoert. Een goed bijgehouden shop met de nieuwste plug-ins is dus nog steeds kwetsbaar.
Alle webopstellingen lopen risico. PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed worden allemaal genoemd. Het PHP-team schat het risico het hoogst in bij mod_php, waar een werkende aanval is aangetoond.
Geen login nodig. Eén verzoek van een anonieme bezoeker kan genoeg zijn.

De officiële GitHub-advisories bevatten de volledige technische details: GHSA-w8hw-w9fx-j79w en GHSA-6wmf-4rv5-p3rp.

Stap 1: update nu

Alleen een update lost het probleem echt op. De gepatchte versies zijn:

PHP 8.5 → 8.5.12
PHP 8.4 → 8.4.27
PHP 8.3 → 8.3.36
PHP 8.2 → 8.2.35 (let op: 8.2 bereikt op 31 december 2026 zijn end of life, plan dus ook een upgrade)

Gebruik je de PHP-pakketten van je Linux-distributie? Die leveranciers kregen de patches vooraf. Controleer bij je distributie of er bijgewerkte pakketten zijn.

PHP 8.1 en ouder krijgen geen officiële release meer. Gezien de ernst heeft het PHP-team wel minimale broncode-patches gepubliceerd voor 7.4, 8.0 en 8.1, voor wie zelf PHP compileert. Sommige distributies en LTS-leveranciers bieden ook eigen backports. Voor de meeste webshops is upgraden naar een ondersteunde versie de enige verstandige route.

Controleer na het updaten of de webserver echt de nieuwe versie draait. De commandoregel en PHP-FPM kunnen verschillende versies gebruiken:

```bash php -v php-fpm8.3 -v # pas aan aan jouw versie ```

Herstart daarna alle PHP-workers. Een oude worker die nog draait, gebruikt nog de kwetsbare code.

Bij shared hosting of een beheerde webshop ligt dit bij je hostingpartij. Vraag vandaag nog na of de update is uitgevoerd.

Kun je niet direct updaten?

Het PHP-team noemt een aantal maatregelen die specifieke aanvalspaden afsluiten. Ze maken een installatie niet veilig. Zie ze als uitstel van een paar dagen, niet als oplossing. Kan zelfs dat niet? Haal de site dan tijdelijk offline.

Tegen CVE-2026-109619 (verouderde state)

Zet upload progress uit in php.ini, de FPM-pool of de serverconfiguratie, en herstart daarna elke worker:

```ini session.upload_progress.enabled = 0 ; alleen op PHP 8.5: fatal_error_backtraces = 0 ```

In een PHP-FPM-pool:

```ini php_admin_value[session.upload_progress.enabled] = 0 ```

Vertrouw hiervoor niet op `ini_set()` of een `.user.ini`-bestand. Die worden pas toegepast nadat PHP het verzoek al heeft verwerkt. Ruim daarnaast ongeldige of verouderde instellingen op die bij elk verzoek een melding geven, en los fatale fouten en timeouts op die een bezoeker kan veroorzaken.

Tegen CVE-2026-109618 (OOM-corruptie)

Zet `memory_limit=-1` op een manier die applicaties niet kunnen overschrijven, zoals `php_admin_value` in de FPM-pool. Bewaak het geheugen dan op containerniveau, met een limiet die alleen de getroffen worker stopt.
Verlaag `post_max_size`: 8M als je geen uploads nodig hebt, 32M als dat wel zo is. Houd `upload_max_filesize` daaronder.
Begrens op webserver- of proxyniveau de grootte van verzoeken, het aantal formuliervelden, multipart-delen en headers.

Gebruik géén `RLIMIT_AS` of `RLIMIT_DATA` als vervanging. Die kunnen juist de kwetsbare geheugenfout veroorzaken.

Voor Nginx kun je bijvoorbeeld de body-grootte begrenzen:

```nginx client_max_body_size 8m; ```

Na de patch: waarom het risico nu juist stijgt

Een patch dicht het lek, maar vertelt aanvallers ook precies waar het zat. Vier redenen waarom de komende weken gevaarlijker zijn dan gisteren:

De patch is een handleiding. Aanvallers vergelijken de oude en nieuwe broncode en bouwen daaruit een werkende aanval. Securitybedrijf Sansec verwachtte massale aanvallen binnen 15 minuten na de release.
Patchen gaat traag. Veel webshops draaien bij shared hosting of bij een developer die het "binnenkort" doet. Bij eerdere grote lekken bleven servers maandenlang kwetsbaar.
Oude versies blijven open. Wie PHP 8.1 of ouder draait en niet zelf compileert, heeft geen kant-en-klare fix.
Gehackt blijft gehackt. Is een server tussen het uitlekken en de update binnengedrongen, dan kan er een webshell of backdoor zijn achtergelaten. Een update verwijdert die niet.

Zoek naar sporen

Ga ervan uit dat je server is gescand en controleer actief. Pas de paden aan aan je eigen server.

Processen die PHP niet hoort te starten:

```bash ps -ef --forest | grep -A3 php-fpm ```

Een PHP-proces dat sh, bash, curl, wget of nc start, is bijna altijd een alarmsignaal.

Nieuwe of gewijzigde PHP-bestanden, mogelijk webshells:

```bash find /var/www -type f -name "*.php" -newermt "2026-10-20" ```

Let vooral op uploadmappen en cachemappen, zoals `wp-content/uploads` of `pub/media`.

Andere signalen:

Onverwacht uitgaand verkeer vanaf de webserver
Nieuwe cronjobs, SSH-sleutels of beheeraccounts
PHP-workers die crashen of opvallend veel geheugenfouten loggen
Ongebruikelijk grote of afwijkende POST-verzoeken in je logs

Vind je iets? Behandel de server als gecompromitteerd. Wissel wachtwoorden en API-sleutels, herstel vanaf een schone back-up van vóór 20 oktober en onderzoek of klantgegevens zijn ingezien. Bij een datalek geldt de meldplicht bij de Autoriteit Persoonsgegevens binnen 72 uur.

Beperk de schade voor de volgende keer

Deze week faalde de eerste verdedigingslinie, up-to-date software, voor iedereen tegelijk. Dan bepaalt de rest van je beveiliging hoe groot de schade wordt. De vraag is niet alleen "kan een aanvaller binnenkomen?", maar vooral "wat kan hij doen als hij binnen is?"

Geen schrijfrechten op je code. Laat de PHP-gebruiker alleen lezen in de map met je code. Dan kan een aanvaller daar geen webshell neerzetten.
Uploads apart en niet uitvoerbaar. Zet uploads en cache op een aparte plek waar PHP-bestanden niet worden uitgevoerd.
Shellfuncties uit. Met `disable_functions` (bijvoorbeeld exec, system, shell_exec, proc_open, passthru) wordt het lastiger om commando's uit te voeren. Let op: bij geheugenfouten zoals deze kan een ervaren aanvaller dat soms omzeilen. Het is een drempel, geen muur.
Uitgaand verkeer beperken. Een webserver hoeft zelden zelf naar buiten te verbinden. Sta alleen verkeer toe naar je betaalprovider, mailserver en updatebronnen. Dan kan een overgenomen server geen data wegsturen of malware ophalen.
Geheimen gescheiden. Bewaar API-sleutels in een secrets manager en gebruik per toepassing een eigen databasegebruiker met minimale rechten.
Containers en isolatie. Met een read-only bestandssysteem en strakke geheugenlimieten per worker verdwijnen wijzigingen bij een herstart en blijft een probleem tot één proces beperkt.
Weet wat je draait. Houd bij welke servers welke PHP-versie en software draaien, en spreek met je host een patchtermijn af, bijvoorbeeld kritieke lekken binnen 24 uur.

Het stopt hier niet: de golf van AI-gegenereerde code

PHP2Shell is één lek in één taal, en er is nu een patch. Het grotere probleem komt sluipend. Als ShoppingPartnerLab scannen we dagelijks webshops, en we zien steeds meer code, koppelingen en configuraties die met AI zijn gemaakt. Vaak werkt die code prima, maar heeft niemand met securitykennis er ooit naar gekeken.

Onafhankelijk onderzoek bevestigt dat beeld:

Veracode testte meer dan 100 taalmodellen op 80 programmeertaken. In 45% van de gevallen faalde de AI-code op securitytests tegen de OWASP Top 10.
IOActive analyseerde bijna 20.000 stukken AI-code. Bijna een derde (31,6%) was volledig te misbruiken.
Meer dan 75% van de ondervraagde ontwikkelaars dacht dat AI-code veiliger is dan door mensen geschreven code. Tegelijk gaf 56% toe dat AI-code vaak securityproblemen introduceert.

De risico's die wij het vaakst tegenkomen:

Geen inputvalidatie. SQL-injectie, onveilige uploads en ontbrekende autorisatiechecks: de klassiekers, nu op grote schaal.
Geheimen in de code. API-sleutels van betaalproviders, feeds of marketingtools die hard in scripts staan.
Verzonnen of verouderde packages. AI noemt soms libraries die niet bestaan. Aanvallers registreren die namen en vullen ze met malware.
Prompt injection. Een AI-chatbot of AI-agent met toegang tot klant- of orderdata kan instructies krijgen via een productreview, een gemanipuleerde productfeed of een chatbericht. De agent voert ze gewoon uit.

Dat laatste is het nieuwe aanvalsoppervlak. Bij PHP2Shell moest een aanvaller een geheugenfout in de kern van PHP vinden. Bij een slecht afgeschermde AI-agent is soms één goed geformuleerde zin genoeg.

Bedrijven en overheden worden hier steeds vaker door geraakt. Hoe sneller AI-code en AI-agents zonder review live gaan, hoe groter de stapel onzichtbare kwetsbaarheden wordt. Wie nu niets doet, staat straks niet voor één lek dat je met een update dicht, maar voor honderden kleine fouten verspreid door de hele stack. Dat is niet meer te overzien.

Anders denken: als een data-engineer

De klassieke webshopvraag is: "werkt het?" De vraag die je nu moet stellen is: "welke data stroomt waarheen, en wie of wat mag daar iets mee?" Zo denkt een data-engineer. Die manier van denken beschermt tegen lekken als PHP2Shell én tegen fouten in AI-code.

Vijf principes die we elke webshop aanraden:

Alle input is onbetrouwbaar, ook AI-output. Behandel wat een taalmodel genereert als input van een onbekende bezoeker. Code uit een prompt gaat pas live na review en een geautomatiseerde security-scan. Een antwoord van een AI-agent wordt gecontroleerd voordat er een actie op volgt.
Ken je datastromen. Breng in kaart welke systemen klantgegevens, orders en betaaldata ontvangen, opslaan en doorsturen. Een gat dat je niet ziet, kun je niet dichten.
Valideer op elke grens. Gebruik vaste schema's en datacontracten tussen systemen. Een productfeed, API-koppeling of chatbot accepteert alleen data in een vooraf afgesproken vorm.
Geef minimale rechten. Een AI-agent die productvragen beantwoordt, heeft geen toegang nodig tot orderhistorie of betaalgegevens. Dezelfde regel als voor je webserver: alleen wat strikt nodig is.
Maak alles observeerbaar. Log wat systemen en AI-agents doen en welke data ze opvragen, en monitor afwijkingen.

Bij dat laatste punt heeft AI echte waarde. Modellen die afwijkend gedrag herkennen in grote hoeveelheden logdata, zien een aanval vaak eerder dan een mens. Een model dat weet dat PHP normaal nooit een shell start, slaat alarm, ook bij een lek dat nog niet bekend is.

Maar AI maakt een systeem niet onbreekbaar. Het repareert geen geheugenfout in PHP en maakt slechte code niet veilig. Het is een detectielaag die 24 uur per dag meekijkt, naast goede basisbeveiliging en niet in plaats daarvan.

Stappenplan

Vandaag

Update naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12 en herstart alle PHP-workers
Lukt dat niet: noodmaatregelen toepassen of de site tijdelijk offline halen
Controleer processen, bestanden en logs op sporen van misbruik

Deze maand

Maak een overzicht van alle servers, PHP-versies en software
Vervang PHP 8.1 en ouder, en plan de upgrade van 8.2 vóór 31 december
Voer schadebeperking door: geen schrijfrechten op code, beperkt uitgaand verkeer, gescheiden geheimen
Spreek met je host of developer een vaste patchtermijn af

Structureel

Geen AI-gegenereerde code live zonder review en security-scan
AI-agents en chatbots alleen toegang tot de data die ze echt nodig hebben
Datastromen documenteren en valideren op elke grens
Gedragsmonitoring op webservers en AI-toepassingen
Back-ups testen en een incidentplan vastleggen: wie doet wat als het misgaat?

Tot slot

De shops die deze week rustig bleven, hadden geen magische technologie. Ze wisten waar hun shop op draait, wie hem bijhoudt en wat ze doen als het misgaat.

De volgende crisis komt waarschijnlijk niet uit één groot lek, maar uit duizenden kleine fouten in code die niemand echt heeft gelezen. AI maakt bouwen sneller dan ooit. Dat is een enorme kans, zolang beveiliging even hard meegroeit. Begin daar vandaag mee.

Bronnen

PHP.net – Security advisory en releases 21 oktober 2026
GitHub – GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GitHub – GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
Sansec – Critical PHP RCE: PHP2Shell
SecurityWeek – PHP2Shell: Mass Exploitation Looms
Patchstack – PHP vulnerable to critical RCE
Brussels Times – Major websites go offline
Cloud Security Alliance – Vibe Coding Security Debt
IOActive – The Security Gap in AI-Generated Code