Kort gezegd: Het tijdvenster tussen patch en aanval was bij PHP2Shell negatief: volgens mediaberichten was er al op 17 oktober 2026 een eerste aanvalspoging, vier dagen vóór de updates. Voor beheerders telt daarom niet de vraag „Hoeveel tijd rest er?”, maar „Hoe lang staat mijn server open?”. Dat persoonlijke venster eindigt pas als de update is geïnstalleerd en alle PHP-processen zijn herstart.
Het begin: aanvallen vóór de patch
Lange tijd gold een gemakkelijke aanname: tussen beveiligingsupdate en eerste aanvallen verstrijken enkele dagen, genoeg tijd voor het volgende onderhoudsvenster. PHP2Shell heeft die aanname weerlegd. Volgens mediaberichten die zich op Amazon beroepen, werd al op 17 oktober een eerste aanvalspoging waargenomen. Ook Cloudflare meldde vroege aanvallen. De patches kwamen op 21 oktober om 14:00 UTC.
Deze bijdrage legt uit hoe zulke tijdvensters ontstaan en hoe u het uwe verkort. De exacte opeenvolging van data vindt u in de PHP2Shell-tijdlijn.
Het tijdvenster tussen patch en aanval in fasen
Rond een beveiligingslek zijn meerdere fasen te onderscheiden. Bij PHP2Shell zagen ze er zo uit:
| Fase | In het algemeen | Bij PHP2Shell |
|---|---|---|
| Vóór bekendmaking | Lek is alleen bij ontdekkers en fabrikant bekend | Ontwikkeling van de correctie onder embargo |
| Eerste aanvallen zonder patch | Aanvallers gebruiken het lek voordat er een update bestaat | volgens mediaberichten eerste poging op 17 oktober |
| Voorafgaande aankondiging | Fabrikant kondigt update aan | 20 oktober, php.net kondigt de release aan |
| Patch beschikbaar | Update en beveiligingsmelding verschijnen | 21 oktober, 14:00 UTC |
| Analyse van de patch | Onderzoekers en aanvallers analyseren de wijzigingen | watchTowr heeft CVE-2026-109618 naar eigen zeggen nagebootst |
| Breed misbruik | geautomatiseerde campagnes tegen ongepatchte servers | door het BSI verwacht; bevestigde geslaagde aanvallen op grote schaal aanvankelijk niet bekend |
| Uw patch | Update en herstart op uw servers | individueel |
De laatste regel is de enige die u kunt beïnvloeden. Alles daarvoor bepalen anderen.
Waarom de patch zelf de druk verhoogt
Een beveiligingsupdate dicht het lek, maar maakt het tegelijk zichtbaar. Wijzigingen in de broncode van opensourceprojecten zoals PHP zijn openbaar. Wie de verschillen tussen oude en nieuwe versie vergelijkt, ontdekt waar de fout zat. Dat is geen verwijt aan het PHP-project, maar de normale gang van zaken bij open software en de basis waarop distributies backports kunnen bouwen.
Voor beheerders volgt hieruit: met elke dag na de patch groeit het aantal mensen dat weet hoe het lek werkt. Tegelijk daalt het aantal ongepatchte servers. De overblijvende worden daarmee de voor de hand liggende doelwitten. Hoe PHP beveiligingsupdates in het kader van zijn versieonderhoud uitlevert, legt de bijdrage over de releasecyclus van PHP uit.
Als uw server tussen 17 oktober en uw patch bereikbaar was, hoort een controle op sporen erbij. Stel de logs vanaf 20 oktober veilig voordat ze door rotatie verloren gaan.
Uw eigen tijdvenster meten
Uw persoonlijke tijdvenster begint uiterlijk met de publicatie van de patches en eindigt met de herstart van het laatste PHP-proces. Leg voor elke server vast:
- Kennis: Wanneer heeft iemand in het bedrijf van het lek gehoord?
- Beschikbaarheid: Wanneer stond het pakket van uw distributie of hostingprovider klaar?
- Installatie: Wanneer is het ingespeeld?
- Herstart: Wanneer liepen er geen oude PHP-processen meer?
Juist de herstart wordt vaak vergeten. Een geïnstalleerde update werkt pas als de oude processen zijn beëindigd. Hoe u dat controleert, beschrijft PHP-FPM en alle PHP-processen herstarten. Of er nog processen van vóór de update draaien, toont een blik op de starttijden:
# Starttijd van alle PHP-processen tonen
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Ligt de starttijd vóór de installatie van de update, dan staat het venster nog open.
Waarom uw venster van de herkomst afhangt
Hoe snel u kunt patchen, hangt niet alleen van u af, maar ook van waar uw PHP vandaan komt. Distributies hebben backports volgens berichten deels nog op 21 oktober uitgeleverd. Wie PHP uit een repository van een derde partij betrekt, is afhankelijk van diens tempo. Wie containers gebruikt, moet images opnieuw bouwen en uitrollen; een eenvoudige update in de draaiende container volstaat niet. En bij shared hosting bepaalt de hostingprovider het tijdstip.
Kent u de herkomst van elke server, dan weet u ook waar uw venster het langst open blijft. Juist daar loont voorbereiding het meest, bijvoorbeeld door afspraken met de hostingprovider of een geteste werkwijze voor nieuwe containerimages.
Zo verkort u het tijdvenster de volgende keer
- Meldingen abonneren: Beveiligingsmeldingen van php.net en uw distributie rechtstreeks ontvangen, niet pas via de pers.
- Verantwoordelijkheid vastleggen: Voor elke server een verantwoordelijk persoon met vervanger.
- Automatisering gebruiken waar ze past: Beveiligingsupdates uit de distributie kunnen automatisch worden ingespeeld. Wat daarvoor en wat ertegen pleit, beschrijft Automatische beveiligingsupdates.
- Herstart inplannen: De herstart van de PHP-diensten hoort vast in het proces, niet in de nazorg.
- Noodroute voorbereiden: Noodpagina en besluit over een tijdelijke uitschakeling, voor als een update niet direct kan.
- Bewijs bijhouden: Tijdstippen van installatie en herstart documenteren, zodat u uw venster later kunt aantonen.
Een duurzaam proces dat deze punten bundelt, is beschreven in de bijdrage over het patchmanagementproces.
Hoe helpt PHP SOS concreet?
- Patch en herstart: Wij spelen de update in en zorgen dat er geen oude PHP-processen meer draaien.
- Tijdvenster aantonen: Wij documenteren installatie en herstart per server met tijdstip.
- Sporencontrole: Voor de periode waarin uw server openstond, stellen wij logs veilig en controleren op bijzonderheden.
- Proces voor de toekomst: Wij richten samen met u meldroutes, verantwoordelijkheden en updateprocedures in.
Meer daarover onder PHP-patchservice.
Conclusie
Bij PHP2Shell was er geen respijt. Het tijdvenster tussen patch en aanval is bij kritieke lekken tegenwoordig vaak nul of zelfs negatief. Wat u wel kunt sturen, is uw eigen venster: het eindigt met de herstart, en het is met voorbereiding van dagen tot uren te verkorten.
Veelgestelde vragen
Hoeveel tijd rest er na een beveiligingsupdate tot aanvallen?
Een vaste termijn bestaat niet. Bij PHP2Shell werd volgens mediaberichten al op 17 oktober een eerste aanvalspoging waargenomen, dus vier dagen vóór de patches. Bij kritieke lekken in wijdverbreide software moet u ervan uitgaan dat er praktisch geen respijt is.
Wat is een zero-day?
Een lek dat wordt aangevallen voordat er een update beschikbaar is. De fabrikant had als het ware nul dagen om het te verhelpen. Daarna spreekt men vaak van een bekend lek of N-day-lek, waarvoor al een patch bestaat.
Waarom nemen aanvallen na een patch vaak toe?
Met de patch wordt openbaar waar de fout zat. Beveiligingsonderzoekers en aanvallers kunnen de wijzigingen analyseren. Tegelijk blijven veel servers nog dagen of weken ongepatcht en dus lonende doelwitten.
Wanneer is mijn server echt beschermd?
Als de update is geïnstalleerd en alle PHP-processen zijn herstart. Nieuwe bestanden alleen werken niet zolang oude processen in het geheugen draaien. Het einde van uw persoonlijke tijdvenster is dus de herstart, niet de download.