Wat PHP2Shell me leerde over het beschermen van ruim 100 sites

In oktober 2026 maakte PHP twee kritieke kwetsbaarheden bekend in de interpreter zelf, samen PHP2Shell genoemd (CVE-2026-109618 en CVE-2026-109619). Via beide konden aanvallers op afstand code uitvoeren. Een lek in PHP zelf, en niet in een plugin of framework, maakt bijna elke PHP-site een mogelijk doelwit.

Ik heb de afhandeling gedaan voor ruim 100 sites. Sommige eigenaren kozen ervoor hun site offline te halen tot die veilig was. Een paar kritieke systemen moesten online blijven. Die hielden we draaiende onder nauwlettende monitoring met hulp van AI. Uiteindelijk is er geen enkel domein gecompromitteerd.

Dit zijn de lessen die ik op orde wil hebben voor de volgende keer.

Wat PHP2Shell is

Volgens het beveiligingsadvies van PHP loopt elke PHP-installatie die webverzoeken afhandelt risico. Dat geldt voor PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Beide lekken scoren 9,2 op CVSS v4.0. PHP ziet het grootste risico bij mod_php: daar is aangetoond dat een verzoek zonder inlog de aanval al uitvoert voordat er applicatiecode draait. Hoe netjes je eigen code is, maakt dus niets uit.

De gerepareerde versies verschenen op 21 oktober 2026: 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor de niet meer ondersteunde versies 7.4, 8.0 en 8.1 publiceerde het PHP-team minimale source-backports.

watchTowr zag vanaf de dag van de release misbruik in het wild. Dan wordt het een race, en elk uur dat je kwijt bent aan uitzoeken waar je staat, ben je niet aan het patchen.

1. Weet wat je draait voordat je het nodig hebt

De eerste vraag is eenvoudig: welke site draait welke PHP-versie, en hoe? Met mod_php of FPM, op welke server, beheerd door wie?

Kost het een dag om dat te beantwoorden, dan ben je een dag kwijt. Houd een overzicht bij met per site de PHP-versie en de manier waarop PHP draait. Werk het bij als onderdeel van het gewone werk, niet pas tijdens een incident.

2. Patch in volgorde van risico

Honderd sites tegelijk lukt niet, dus bepaal de volgorde:

• Sites die vanaf internet bereikbaar zijn gaan voor interne sites.
• mod_php gaat voor de andere opstellingen, omdat die hier het meeste risico loopt.
• Sites met gevoelige gegevens of veel gebruikers gaan voor kleine visitekaartjessites.

Controleer of de fix er echt in zit, niet alleen het versienummer. Linuxdistributies kregen de patches vooraf, dus hun pakketten kunnen de fix bevatten onder een ouder versienummer. En een bijgewerkte binary doet niets zolang de PHP-workers niet opnieuw zijn gestart. Kijk wat het draaiende proces gebruikt, niet wat er op schijf staat.

3. Gebruik tijdelijke maatregelen, maar leun er niet op

Het advies van PHP noemt maatregelen voor als je niet direct kunt updaten, zoals session.upload_progress.enabled=0 instellen en post_max_size verlagen. In een aanvullende melding op 23 oktober raadt PHP aan de upload-progress-instelling uit te laten tot de volgende reguliere bugfixrelease.

Twee details zijn belangrijk. Zet deze instellingen in php.ini of de configuratie van de FPM-pool, niet in ini_set() of .user.ini, want die komen te laat. En herstart daarna elke worker.

Ook dan verkleinen deze maatregelen alleen het risico terwijl je de lijst afwerkt. PHP is er duidelijk over: er bestaan geen volledige mitigaties, en updaten is de enige veilige keuze. Zie ze als een manier om tijd te winnen.

4. Een site offline halen is een prima keuze

Voor sommige eigenaren was het veiligst om hun site offline te halen tot de patch erop zat. Dat is geen falen. Een paar uur offline kost iets. Een gecompromitteerde site kan veel meer kosten: gestolen gegevens, malware bij bezoekers en een lange opruimklus.

Leg de keuze eerlijk voor: wat het risico is, hoe lang het patchen duurt en wat downtime kost. Laat de eigenaar dan beslissen. Het is hun bedrijf.

5. Houd scherp in de gaten wat online moet blijven

Sommige systemen kunnen niet offline, ook niet een paar uur. Die hebben we bewust laten draaien zolang het risico er was, en bewaakt met monitoring met hulp van AI.

Tijdens een incident als dit zijn de logs te groot om met de hand door te lezen. AI helpt ze te doorzoeken en markeert wat afwijkt, zodat een mens naar de paar dingen kan kijken die ertoe doen. De beslissing om in te grijpen blijft bij een mens.

Waar je na zo’n lek op een PHP-server op wilt letten:

• Nieuwe of gewijzigde PHP-bestanden in webmappen.
• PHP-workers die andere processen starten, zoals een shell.
• Onverwachte uitgaande verbindingen vanaf de webserver.
• Ongebruikelijke verzoeken naar endpoints die normaal weinig verkeer krijgen.

Monitoring vervangt de patch niet. Het verkleint de periode waarin er ongemerkt iets mis kan gaan.

6. Rond het netjes af

Als de laatste site gepatcht is, is het incident niet voorbij. Controleer per site of de draaiende PHP-versie de fix bevat, en kijk op de systemen die kwetsbaar waren naar de signalen hierboven. “We hebben gepatcht” en “er is niets gebeurd” zijn twee verschillende uitspraken, en je wilt ze allebei kunnen onderbouwen.

Kijk daarna vooruit. PHP 8.2 is op 31 december 2026 end-of-life en krijgt daarna geen beveiligingsupdates meer. Een site die dan nog op 8.2 of ouder draait, krijgt bij het volgende lek als dit helemaal geen officiële patch. Plan die upgrades nu, nu er nog geen deadline in je nek hijgt.

Een korte checklist

Voor het volgende kritieke PHP-lek wil ik op al deze vragen ja kunnen zeggen:

• Weten we van elke site welke PHP-versie er draait, en hoe?
• Draait elke site op een PHP-versie die nog beveiligingsupdates krijgt?
• Is er een afgesproken volgorde om onder tijdsdruk te patchen?
• Kunnen we controleren dat de fix actief is in het draaiende proces, en niet alleen geïnstalleerd?
• Weet elke site-eigenaar vooraf wie beslist over offline halen?
• Is er monitoring voor de systemen die nooit plat mogen?
• Controleren we achteraf op sporen van een inbraak, in plaats van aan te nemen dat die er niet zijn?

Er komen altijd weer kritieke kwetsbaarheden. Hoe het afloopt, hangt vooral af van de voorbereiding vóór de bekendmaking.