PHP2Shell: wat betekent dit kritieke PHP-lek voor uw website?

Het PHP-team heeft een update uitgebracht voor twee kritieke kwetsbaarheden in PHP. In de berichtgeving worden ze PHP2Shell genoemd. PHP is de programmeertaal achter een groot deel van het internet: WordPress, veel webshops, klantportalen en talloze zelfgebouwde websites draaien erop. Een kritiek lek in PHP raakt dus niet één product, maar een enorm aantal websites tegelijk.

In deze blog leggen we uit wat er aan de hand is, wie risico loopt en wat u nu moet doen.

Wat is er aan de hand?#

Op 21 oktober bracht het PHP-team de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit. Die lossen twee kritieke kwetsbaarheden op, elk met een score van 9,2 op CVSS v4.0, die het volgens het PHP-team mogelijk maken om zonder inloggen code uit te voeren op de server. Het PHP-team roept iedereen op om direct bij te werken (beveiligingsadvies op php.net).

Het gaat om deze twee lekken:

• CVE-2026-109618: code uitvoeren via een geheugenfout. Als PHP onverwacht zonder geheugen komt te zitten, kan het een verzoek halverwege onderbreken. Bij het opruimen kan PHP de half opgebouwde gegevens daarna als geldig behandelen (technisch advies).
• CVE-2026-109619: code uitvoeren via achtergebleven gegevens. Gegevens van een verzoek kunnen blijven bestaan nadat het bijbehorende geheugen al is vrijgegeven. Een volgend verzoek dat door hetzelfde proces wordt afgehandeld, kan die verouderde gegevens dan gebruiken (technisch advies).

Uitzonderlijk was dat er al vóór de update details over de lekken online uitlekten. Het beveiligingsbedrijf watchTowr bevestigde toen al dat de lekken echt waren. Op de ochtend van de release hadden watchTowr en Huntress nog geen misbruik in de praktijk gezien, maar Sansec verwachtte dat massaal misbruik binnen een kwartier na de update zou beginnen (SecurityWeek). Nu de update er is, is snel handelen dus belangrijk.

Wie loopt risico?#

Volgens het PHP-team alle PHP-installaties die webverzoeken afhandelen, of dat nu via PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP of LiteSpeed gaat. Het risico is het grootst bij mod_php: daar is een aanval aangetoond waarbij een verzoek zonder inloggen het lek activeert, nog voordat er ook maar één regel van de website zelf wordt uitgevoerd.

Dat laatste is belangrijk. Het lek zit in PHP zelf, niet in uw website. Een volledig bijgewerkte WordPress-site met de nieuwste plug-ins biedt dus geen bescherming zolang PHP zelf niet is bijgewerkt.

Denk bij systemen die op PHP draaien aan:

• WordPress-websites, inclusief alle plug-ins en thema's;
• webshops die op PHP zijn gebouwd;
• klantportalen, intranetten en beheeromgevingen van leveranciers;
• zelfgebouwde applicaties in PHP;
• oude servers die ooit zijn opgezet en daarna vergeten.

Juist dat laatste is een groot risico. Een vergeten testomgeving, een oud subdomein of een beheerpagina van een vorige leverancier wordt vaak niet meer bijgewerkt, en is daardoor precies waar aanvallers naar zoeken.

Websites die geen PHP op de server draaien, zoals statische websites, zijn via hun website niet kwetsbaar voor dit lek. Draait er achter zo'n website wel een back-end op PHP, dan moet die back-end net zo goed worden bijgewerkt.

Welk risico lopen consumenten?#

Het lek zit op de server van een website, niet op de computer of telefoon van bezoekers. Consumenten kunnen dus zelf niets bijwerken. Maar als een aanvaller via dit lek de server van een webshop of website overneemt, kan dat wel gevolgen hebben voor de klanten van die website. Een aanvaller met toegang tot de server kan bijvoorbeeld:

• klantgegevens stelen die op de server staan, zoals namen, adressen, e-mailadressen, bestelgeschiedenis en versleutelde wachtwoorden;
• de website ongemerkt aanpassen, bijvoorbeeld door code aan de betaalpagina toe te voegen die ingevulde betaalgegevens doorstuurt naar de aanvaller;
• bezoekers doorsturen naar een nepwebsite of malware aanbieden.

Wat kunt u als consument doen?

• Wees alert op berichten over een bestelling of account. Gestolen klantgegevens worden vaak gebruikt voor geloofwaardige phishing. Wees extra voorzichtig met e-mails, sms'jes of telefoontjes waarin om gegevens of een betaling wordt gevraagd.
• Gebruik voor elke website een ander wachtwoord en zet tweestapsverificatie aan waar dat kan. Een uitgelekt wachtwoord geeft dan geen toegang tot uw andere accounts.
• Controleer de adresbalk bij het betalen. Wordt u voor een betaling doorgestuurd naar uw bank, controleer dan dat u echt op de website van uw bank bent voordat u inlogt.
• Houd uw bankafschriften in de gaten en meld onbekende afschrijvingen direct bij uw bank.

Voor organisaties betekent dit ook een verantwoordelijkheid richting hun klanten. Lekken er persoonsgegevens uit, dan moet dat in de meeste gevallen binnen 72 uur nadat het is ontdekt worden gemeld bij de Autoriteit Persoonsgegevens.

Wat moet u nu doen?#

1. Breng in kaart waar PHP draait. Niet alleen uw hoofdwebsite, maar ook webshops, portalen, testomgevingen en systemen van leveranciers. Vraag het na bij uw hostingpartij en websitebouwer.
2. Werk bij naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Linux-distributies en leveranciers met langdurige ondersteuning hebben de oplossing vooraf ontvangen, dus controleer bij hen of er bijgewerkte pakketten zijn. Laat uw hostingpartij bevestigen dat de update is uitgevoerd, ook als zij het beheer doen.
3. Draait u PHP 8.1 of ouder? Die versies krijgen geen updates meer van het PHP-team. Sommige leveranciers bieden zelf een oplossing aan, maar upgraden naar een ondersteunde versie is de echte oplossing. Voor wie PHP zelf compileert, heeft het PHP-team uitzonderlijk minimale oplossingen voor PHP 7.4, 8.0 en 8.1 beschikbaar gesteld.
4. Controleer of er al iets is gebeurd. Zeker bij systemen die pas laat zijn bijgewerkt: kijk naar onbekende nieuwe bestanden op de webserver, nieuwe beheerdersaccounts en ongebruikelijke activiteit in de logbestanden.
5. Zet uit wat u niet meer gebruikt. Elk systeem dat niet meer nodig is maar nog wel aanstaat, is een extra ingang voor aanvallers.

Voor beheerders: kunt u niet direct bijwerken?#

Het PHP-team is duidelijk: alleen bijwerken is een volledige oplossing. De tijdelijke maatregelen uit het beveiligingsadvies blokkeren alleen bepaalde aanvalsroutes en maken een installatie niet veilig. Een korte uitleg per lek:

Lek 1, CVE-2026-109618: een geheugenfout

Volgens het advies kan PHP worden onderbroken als het geheugen opraakt terwijl het de gegevens van een verzoek nog aan het opbouwen is. De maatregelen maken het lastiger om juist dat geheugentekort te veroorzaken:

• memory_limit=-1 zet de eigen geheugengrens van PHP uit. Zo kan een aanvaller die grens niet meer bewust laten overschrijden. Zet dit met php_admin_value in de FPM-pool of Apache-configuratie, zodat applicaties het niet kunnen terugdraaien. Volgens het advies kan een echt geheugentekort van de server de kwetsbare route nog wel bereiken, en raadt het een geheugengrens op container- of cgroup-niveau aan. Zonder die grens kan één zwaar verzoek veel geheugen van de server gebruiken.
• post_max_size laag zetten, volgens het advies 8M als de applicatie geen bestandsuploads nodig heeft en anders 32M. Dit beperkt hoeveel data PHP uit één verzoek inleest. Grotere uploads werken daarna niet meer.

Lek 2, CVE-2026-109619: achtergebleven gegevens

Een webserver houdt een aantal PHP-processen ("workers") draaiend die het ene verzoek na het andere afhandelen. Volgens het advies kunnen gegevens van een verzoek in zo'n proces blijven hangen en door een volgend verzoek worden gebruikt. Het PHP-team noemt twee bevestigde routes:

• session.upload_progress.enabled=0 zet de functie uit die de voortgang van uploads bijhoudt, bijvoorbeeld voor een voortgangsbalk. Volgens het advies moet deze instelling actief zijn voordat PHP het verzoek inleest: zet hem daarom in php.ini of de FPM-pool, niet via ini_set() of .user.ini. Voortgangsbalken die op deze functie leunen, werken daarna niet meer.
• fatal_error_backtraces=0 (alleen PHP 8.5) zet het overzicht van actieve functies bij een fatale fout uit. Het maken van dat overzicht is volgens het advies de tweede bevestigde route.

Herstart na deze wijzigingen alle workers, zoals het advies aangeeft. Draaiende processen gebruiken anders nog de oude instellingen.

Gebruikt u remirepo?

rpms.remirepo.net is een door vrijwilligers onderhouden repository waarmee veel beheerders nieuwere PHP-versies installeren, onder meer op Red Hat en Fedora. Volgens het PHP-team krijgt die op de dag van de release geen updates. Stap dan over op de pakketten van uw distributie of compileer PHP zelf.

Waarom dit om meer gaat dan één update#

De update voor PHP2Shell is er nu, maar het volgende kritieke lek komt er gegarandeerd aan. De organisaties die het snelst en veiligst reageren, zijn de organisaties die precies weten welke systemen ze hebben en hoe die aan het internet hangen.

Dat is waar een pentest helpt. Wij brengen in kaart welke systemen van buitenaf bereikbaar zijn, ook de systemen die u zelf uit het oog bent verloren, en testen hoe ver een aanvaller daadwerkelijk komt. U krijgt een helder rapport met concrete verbeterpunten, zodat u bij het volgende lek niet hoeft te zoeken, maar direct weet wat u moet doen.

Jeremy Melis21-10-2026