Kort gezegd: Wie het PHP-lek PHP2Shell vandaag nog gedicht wil hebben, heeft vier dingen nodig: de juiste update, de herstart van alle PHP-processen, de controle op al ingebrachte schadelijke code en een bewijs. Bent u getroffen? Bel ons. Wij helpen. Wij nemen dit op afstand over, vanaf het eerste bericht.
Verwijder nu niets en zet niets opnieuw op. Ook bij het patchen geldt: eerst veiligstellen, dan wijzigen. Is er al iets binnengedrongen, dan hebben wij de toestand van bestanden en logboeken nodig. Meld uw noodgeval, dan bepalen we samen met u de volgorde.
Waarom het lek niet kan wachten
De twee kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 zitten in PHP zelf en maken het mogelijk om zonder inloggen op afstand schadelijke code uit te voeren. Het BSI (de Duitse federale dienst voor informatiebeveiliging) heeft waarschuwingsniveau 3 (oranje) afgekondigd en adviseert de directe update. Als dat niet meteen kan, moeten webservers tijdelijk van het netwerk. Volgens berichten in de media waren er al vóór de publicatie van de patches op 21-10-2026 de eerste waargenomen aanvalspogingen. Cloudflare heeft pogingen waargenomen en beschermingsregels uitgerold, maar waarschuwt dat regels op basis van alleen de aanvraaggegevens niet volstaan.
Belangrijk voor beheerders: een CMS-update dicht het PHP-lek niet. Ook WordPress.org plant volgens berichten geen update ertegen, omdat het lek in de interpreter zit. Het wordt alleen op PHP-niveau gedicht, dus bij datgene wat uw server daadwerkelijk uitvoert.
Wat u nu direct doet
- Ken de doelversie. Verholpen zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. PHP 8.2 bereikt op 31-12-2026 het einde van de ondersteuning; houd daar rekening mee.
- Breng alle systemen in kaart. Ook testservers, containerimages en oude systemen die vanaf internet bereikbaar zijn.
- Bepaal wie verantwoordelijk is. Bij hostingpakketten en managed servers voert de aanbieder de update door. Vraag schriftelijk naar de versie en de herstart.
- Bewaar de logboeken. Vanaf 20-10-2026, aldus de vakpers.
- Stem een tijdvenster af. Een herstart onderbreekt lopende verzoeken even. Spreek een tijdstip af waarop iemand beslissingen kan nemen.
- Wacht niet als het open staat. Kan er niet direct worden gepatcht, bekijk dan samen met ons het afschermen of de tussentijdse maatregelen.
Hoe helpt PHP SOS concreet?
- Situatie opnemen: Wij inventariseren systemen, PHP-versies, uitvoeringsmodi, hostingproviders en bereikbaarheid en leggen de volgorde vast: eerst de meest blootgestelde systemen.
- Veiligstellen en dichten: Wij zetten de actuele toestand veilig, voeren de update door of brengen de hosting op de aantoonbaar gepatchte stand en herstarten alle processen. Bij containers bouwen we het image opnieuw en rollen we het uit.
- Controleren en opschonen: Omdat een patch schadelijke code niet verwijdert, controleren wij op tekenen van een eerdere inbraak en ruimen we zo nodig op.
- Beveiligen en rapporteren: U krijgt een schriftelijk bewijs per systeem en aanbevelingen, zodat de volgende update sneller verloopt. Het dienstenpakket beschrijft de PHP-patchservice.
Update, herstart, bewijs: waar het op aankomt
De meest voorkomende fout is een update zonder herstart. Zolang oude processen in het geheugen draaien, blijft de kwetsbare code actief, ook als de bestanden nieuw zijn. De handleiding daarvoor staat op de pagina PHP-FPM en alle workers herstarten. De tweede fout is de weergave te geloven: distributies en hostingproviders leveren vaak backports, waarbij het versienummer gelijk blijft. Betrouwbaar is de pakketchangelog met de CVE-nummers, bij de Debian-familie met apt-get changelog <paket>.
Daarnaast geldt volgens de PHP-handleiding sinds de beveiligingsreleases de nieuwe directive memory_hard_limit_percent. Kent een PHP-versie die niet, dan is ze getroffen. De test is kort:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Hij moet per versie en uitvoeringsmodus worden uitgevoerd, omdat de opdrachtregel een andere PHP-versie kan gebruiken dan de webserver. Ten slotte leggen we het resultaat vast, zodat u het kunt tonen aan uw hostingprovider, verzekeraar of opdrachtgever.
Als de update niet direct kan
Er zijn redenen waarom een update vandaag niet lukt: een oude toepassing die op nieuwere PHP-versies niet draait, een hostingprovider zonder toestemming, een containerimage in een vaste pipeline. Voor die gevallen noemt php.net tussentijdse maatregelen die uitdrukkelijk geen volledige bescherming zijn: memory_limit=-1 zo instellen dat toepassingen het niet kunnen overschrijven, post_max_size beperken, session.upload_progress.enabled=0 en op PHP 8.5 fatal_error_backtraces=0, telkens met herstart. Daarbij komen beschermingsregels aan de rand, die een update niet vervangen. Een rondgaande tip om alle verzoeken met PHPSESSID te blokkeren, wordt door vakauteurs uitdrukkelijk afgewezen.
Welke maatregelen bij uw systeem passen en wat ze kunnen breken, bespreken we vooraf. Meer daarover op de pagina Noodmaatregelen als u nog niet kunt patchen en bij het onderwerp WAF en virtueel patchen. Voor PHP 8.1 en ouder geldt een eigen situatie, beschreven onder PHP 8.1 en ouder: wat nu geldt.
Wat u ons het best kunt sturen
- Lijst van de servers en hostingproviders, voor zover beschikbaar
- Uitvoer van
php -vper systeem en een opmerking over de uitvoeringsmodus - Vermelding of containers, Plesk, cPanel of een managed aanbod in gebruik zijn
- gewenst tijdvenster en contactpersoon voor herstarts
- Aanwijzingen voor opvallende zaken sinds 17-10-2026
Waarom PHP SOS
Wij werken Made in Germany en zijn met ons partnernetwerk van cyberprofessionals al meer dan 25 jaar gespecialiseerd in IT-beveiliging. U hebt één aanspreekpunt dat de update begeleidt, de herstart controleert en het bewijs levert. Wij werken op afstand, zonder reistijd, en documenteren elke stap. Wij beloven geen wonderen: een patch dicht het lek, maar bewijst niet dat er daarvoor niets is gebeurd, en dat zeggen wij u ook zo.
Bent u getroffen? Bel ons. Wij helpen.
Laat het lek niet langer open staan. Bel ons of stuur een bericht via WhatsApp. Wij nemen het over vanaf het eerste bericht en blijven erbij tot het incident is afgerond en gedocumenteerd. Meld nu uw noodgeval.
Veelgestelde vragen
Kan ik het PHP-beveiligingslek zelf dichten of heb ik hulp nodig?
Een update is voor beheerders te doen, maar foutgevoelig: de versie die echt wordt gebruikt moet worden bijgewerkt en alle processen moeten herstarten. Wie meerdere servers, containerimages of een hostingprovider met eigenaardigheden heeft, bespaart met ondersteuning tijd en fouten.
Moet PHP na de update worden herstart?
Ja. Nieuwe bestanden alleen zijn niet genoeg zolang oude PHP-processen in het geheugen draaien. Alle workers of processen moeten worden herstart, bij mod_php de webserver.
Wat te doen als er nog geen update voor mijn PHP-versie bestaat?
Voor PHP 8.1 en ouder levert het PHP-project geen officiële updates meer. Dan zijn een aantoonbaar gepatchte backport van de aanbieder, een migratie naar een onderhouden versie of tussentijdse maatregelen nodig, die echter geen volledige bescherming bieden.
Is het genoeg om session.upload_progress.enabled op 0 te zetten?
Nee. Volgens vakberichten dicht die instelling alleen niet beide kwetsbaarheden; de PHP-update blijft verplicht. Zet haar alleen in php.ini, de FPM-pool of de serverconfiguratie, niet via ini_set() of .user.ini.
Hoe weet ik dat het lek daarna echt is gedicht?
Door bewijs op het draaiende systeem: versie of pakketchangelog, een test op de nieuwe directive memory_hard_limit_percent en de bevestiging dat alle processen na de update zijn herstart.