Toevoegen als voorkeursbron op Google
Op 21 oktober 2026 bestookten aanvallers websites al met verzoeken die misbruik moesten maken van twee kritieke kwetsbaarheden in PHP, bekend als PHP2Shell. Officiële beveiligingspatches waren er nog niet, maar onze engineering- en beveiligingsteams werkten al hard om de websites bij Kinsta te beschermen.
Er kwam veel bij kijken. Ons team schakelde noodregels voor de Cloudflare firewall in, paste PHP configuraties aan en bereidde zich voor om patches op honderdduizenden containers uit te rollen zodra die beschikbaar kwamen. Tegelijk handelde ons supportteam een stortvloed aan vragen af van klanten die zich zorgen maakten over hun websites.
Op 23 oktober had de beveiliging van Cloudflare al meer dan 550.000 verzoeken geblokkeerd die op de kwetsbaarheden waren gericht. Ook hadden we de benodigde PHP beveiligingsupdates op ons hele hostingplatform uitgerold, en vonden we geen aanwijzingen voor geslaagde inbraken.
Hieronder lees je hoe de reactie verliep: van de eerste tekenen van misbruik tot de uitrol van de patches en het werk dat daarna volgde.
Voorbereiden op PHP2Shell voordat de patches er waren
Op 20 oktober kondigde het PHP beveiligingsteam een kritieke beveiligingsupdate aan voor de volgende dag. De aankondiging waarschuwde voor twee kwetsbaarheden met een ernstscore van 9,2 volgens CVSS 4.0, en riep PHP gebruikers op om zich voor te bereiden op het updaten van hun installaties zodra de patches beschikbaar waren.
De kwetsbaarheden, later bekend als CVE-2026-109618 en CVE-2026-109619, zitten in de interne geheugenverwerking van PHP. Onder bepaalde omstandigheden konden aanvallers daarmee op afstand code uitvoeren, zonder authenticatie.
Vooral voor WordPress websites was de aankondiging belangrijk, omdat PHP de applicatie zelf draait. Een WordPress plugin of thema updaten kon deze kwetsbaarheden niet verhelpen. De onderliggende PHP runtime moest zelf worden gepatcht.
Voor hostingproviders zoals Kinsta was de eerste uitdaging om websites te beschermen voordat de officiële patches er waren. Ons team begon zich voor te bereiden op de release, maar de eerste pogingen tot misbruik doken al op.
Volgens Laszlo Farkas, Director of Engineering bij Kinsta, zag ons team in de vroege uren van 21 oktober de eerste verzoeken die op de kwetsbaarheden waren gericht. Engineers controleerden de sites die doelwit waren handmatig en bleven de activiteit in de gaten houden op tekenen van een geslaagde inbraak.
Op dat moment hadden we al maatregelen genomen om de websites op ons platform te beschermen.
Zo activeerden we de noodregels voor de WAF van Cloudflare
Elke website bij Kinsta zit achter Cloudflare, ook productie- en testomgevingen. Daardoor kan ons engineeringteam firewallbescherming op het hele hostingplatform toepassen, zonder dat klanten per website regels hoeven in te stellen.
Nog voordat PHP2Shell openbaar werd, introduceerde Cloudflare noodregels voor de Web Application Firewall (WAF) om pogingen tot misbruik op te sporen. Ons engineeringteam hield de changelog van Cloudflare’s WAF nauwlettend in de gaten. Zodra er nieuwe regels verschenen, bekeek het team ze en zette het de actie zo snel mogelijk op Block.
Omdat elke Kinsta site al achter Cloudflare draait, konden we deze beveiliging op ons hele hostingplatform toepassen, in productie- én testomgevingen, zonder dat klanten zelf iets hoefden te doen.
Die platformbrede bescherming was belangrijk, want PHP2Shell was geen typische kwetsbaarheid op applicatieniveau. De aanvallen richtten zich op PHP zelf. Beveiligingsupdates voor WordPress of bescherming op pluginniveau hadden het onderliggende probleem dus niet opgelost.
Met de WAF-regels konden we bekende pogingen tot misbruik blokkeren terwijl we de PHP patches voorbereidden. Cloudflare bleef zijn beveiliging bijwerken naarmate aanvallers van techniek wisselden. In het technische rapport over PHP2Shell beschrijft Cloudflare hoe aanvallers hun payloads aanpasten om bestaande detecties te omzeilen.
Cloudflare introduceerde ook volledige transactiedetectie, die signalen uit zowel het HTTP-verzoek als het antwoord van de server analyseert. Dat geeft extra informatie om verdachte verzoeken te herkennen, en kan voorkomen dat een bijbehorend antwoord de aanvrager bereikt.
Onze engineers zagen de aanvalspatronen veranderen naarmate er nieuwe regels bijkwamen.
Op 23 oktober had de beveiliging van Cloudflare voor Kinsta sites al meer dan 550.000 verzoeken geblokkeerd die gericht waren op PHP2Shell.
Dit cijfer gaat over geblokkeerde verzoeken die verband hielden met de kwetsbaarheden, niet over geslaagde aanvallen of unieke aanvallers. Het laat zien hoeveel verdacht verkeer onze firewall heeft tegengehouden terwijl het team de PHP fixes uitrolde.
Tijdelijke beveiliging toevoegen in de PHP configuratie
We vertrouwden niet alleen op Cloudflare. Terwijl we wachtten op gepatchte PHP pakketten, rolde ons engineeringteam ook wijzigingen in de PHP configuratie uit in al onze hostingomgevingen. Zo beperkten we de blootstelling aan bekende aanvalsroutes.
Zo schakelden we de feature voor de voortgang van sessie-uploads in PHP uit, via de instelling `session.upload_progress.enabled`.
In het beveiligingsadvies van PHP wordt deze instelling genoemd als maatregel tegen bepaalde aanvalsroutes. Schakel je hem uit, dan help je aanvallen te blokkeren die misbruik maken van de manier waarop PHP de voortgang van sessie-uploads verwerkt. Dat dekt wel niet elke mogelijke manier waarop de kwetsbaarheden kunnen worden misbruikt.
De firewallregels en configuratiewijzigingen boden extra bescherming zolang er nog geen patches waren of ze nog werden uitgerold. De PHP runtime bijwerken bleef wel nodig.
Op 23 oktober publiceerde het PHP team een aanvullend advies: houd de voortgang van sessie-uploads uitgeschakeld tot een volgende bugfixrelease. Dat bevestigde de voorzorgsmaatregel die ons engineeringteam al had genomen.
Onze Cloudflare regels en lokale configuratiemaatregelen bleven de hele uitrol van kracht, ongeacht of een omgeving het bijgewerkte PHP pakket al had gekregen.
PHP patches uitrollen op honderdduizenden containers
Toen het PHP ontwikkelteam op 21 oktober de beveiligingsupdates uitbracht, was onze volgende uitdaging om die fixes op de hele hostinginfrastructuur uit te rollen.
De officiële releases waren PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Maar Kinsta ondersteunt ook oudere PHP versies, en daarvoor waren beveiligingsfixes van externe beheerders nodig.
We werkten samen met Freexian, onze leverancier van PHP pakketten, om gepatchte pakketten te krijgen voor alle PHP versies op ons platform, ook oudere versies met long-term support.
De pakketten kwamen stuk voor stuk beschikbaar, niet allemaal tegelijk. Zodra een nieuwe build in onze pakketmirror binnenkwam, valideerde ons engineeringteam die en begon het met de uitrol, zonder te wachten tot elke PHP branch klaar was.
Zo verliep de uitrol:
| Datum en tijd (UTC) | Wat er gebeurde |
| 21 okt, ~14:00–17:45 | PHP bracht de beveiligingspatches uit. PHP 8.5.12 stond om 14:24 in onze pakketmirror en om 15:54 begon de uitrol. Om 17:45 waren tienduizenden containers bijgewerkt. |
| 21 okt, 18:50–19:04 | PHP 8.3.36 kwam beschikbaar en de uitrol begon, naast die van PHP 8.5. |
| 21 okt, 21:17–22:28 | Gepatchte pakketten voor PHP 7.4, 8.0 en 8.1 kwamen beschikbaar. Om 22:28 begonnen de volgende uitrollen. |
| 21–22 okt, 23:25–01:37 | De pakketten voor PHP 8.2 en 8.4 kwamen om 23:25 binnen. Op 22 oktober om 01:37 begon de uitrol. |
| 22 okt, 04:31 | Nog maar 1.888 containers, zo’n 0,5% van het totaal, moesten worden bijgewerkt en hadden extra aandacht nodig. |
| 22 okt, 08:26 | We bevestigden dat de bescherming 100% dekte en markeerden het incident als opgelost. |
Dat we wijzigingen op deze schaal konden uitrollen, was een van de belangrijkste onderdelen van de reactie.
Farkas benadrukte hoe snel het team wijzigingen op de hele infrastructuur kon doorvoeren:
“Hier ben ik het meest trots op. Zodra een wijziging is gevalideerd en we weten dat er niets door stukgaat, kunnen we hem binnen een paar uur op de hele infrastructuur uitrollen.”
Daardoor kon ons team gepatchte PHP pakketten binnen enkele uren op honderdduizenden containers uitrollen.
We hoefden PHP updates ook niet met individuele klanten af te stemmen. Kinsta beheert PHP op platformniveau. Zodra ons engineeringteam een bijgewerkt pakket had gevalideerd, konden we het dus in alle betrokken omgevingen uitrollen, zonder site-eigenaren te vragen zelf updates te installeren.
Waarom oudere PHP versies extra fixes nodig hadden
Bij de uitrol moesten we ook rekening houden met het verschil tussen de officieel ondersteunde branches van PHP en oudere versies die door externe leveranciers worden onderhouden.
Het PHP project bracht beveiligingsupdates uit voor PHP 8.2 tot en met 8.5. Versies als PHP 7.4, 8.0 en 8.1 kregen geen reguliere beveiligingsreleases meer van het PHP project zelf. Aanbieders van long-term support konden wel gebackporte fixes leveren.
Met backporting passen beheerders beveiligingsfixes toe op een oudere softwarebranch, zonder dat gebruikers naar een nieuwere PHP versie hoeven te upgraden.
Zo konden we ook voor die oudere PHP omgevingen beveiligingsupdates uitrollen, zodra Freexian gepatchte pakketten uitbracht.
Het verklaart ook waarom een PHP versienummer je niet altijd vertelt of een bepaalde beveiligingsfix is toegepast. Pakketten die door leveranciers worden onderhouden, kunnen gepatchte code bevatten zonder hetzelfde versienummer te tonen als de officiële upstream release van PHP.
Gedurende de hele operatie bleven we updates uitrollen en hielden we de extra firewall- en configuratiemaatregelen in stand.
Aanvallen monitoren en controleren op tekenen van inbraak
Patches uitrollen was maar een deel van de reactie. Ons team moest ook vaststellen of waargenomen pogingen tot misbruik waren geslaagd.
Toen we in de vroege uren van 21 oktober voor het eerst activiteit zagen die op websites bij Kinsta was gericht, onderzochten onze engineers de betrokken sites handmatig.
Ze bleven het hele incident door verdacht verkeer monitoren en steekproeven nemen in de hostingomgevingen, op zoek naar tekenen dat aanvallers de kwetsbaarheden met succes hadden misbruikt.
De security events van Cloudflare hielpen ons te begrijpen wat het doelwit was en hoe de aanvalspatronen veranderden naarmate we nieuwe regels uitrolden. Maar alleen uit het aantal geblokkeerde verzoeken konden we niet afleiden of er aanvallen waren geslaagd.
Daarom waren die handmatige controles zo belangrijk. Ons team hield ook nauw contact met Patchstack, onze partner voor Kwetsbaarheidsbescherming, en wisselde informatie uit over de dreigingen en aanvalspatronen die beide teams zagen. Daarnaast namen we deel aan gesprekken met andere hostingproviders om informatie en goede werkwijzen te delen, terwijl de bredere PHP community in actie kwam.
Dat werk vulde onze samenwerking met Cloudflare en Freexian aan. Cloudflare leverde de bescherming tegen pogingen tot misbruik, Freexian de gepatchte PHP pakketten, en dankzij de afstemming met beveiligingspartners begrepen onze engineers beter hoe de dreiging zich ontwikkelde.
Gedurende het hele incident hebben we geen aanwijzingen gevonden voor geslaagde inbraken via PHP2Shell.
Die conclusie is gebaseerd op de monitoring en onderzoeken tijdens de reactie. Dat betekent niet dat er geen aanvallen waren, zoals de firewalldata laten zien. Het betekent dat we bij onze controles geen tekenen van een geslaagde inbraak hebben gevonden.
Het incident oplossen en blijven controleren
Op 22 oktober om 08:26 UTC markeerden we het PHP beveiligingsincident als opgelost op onze openbare statuspagina.
Op dat moment hadden we de beveiligingsupdates over het hele platform uitgerold en waren alle sites beschermd door een combinatie van patches en mitigerende maatregelen.
Dat het incident was opgelost, betekende niet dat we stopten met controleren. Ook nadat het openbare incident was afgesloten, bleef ons team omgevingen verifiëren en de beveiliging monitoren.
Bij een uitrol over meerdere PHP branches en honderdduizenden containers was dat belangrijk. Om 04:31 UTC had nog zo’n 0,5% van de containers extra aandacht nodig. Onze engineers bleven die laatste omgevingen doorlopen en de resultaten controleren. Een beschikbaar gepatcht pakket zagen ze niet als bewijs dat elke installatie ook echt was bijgewerkt.
Ook tijdens dit controlewerk bleven de Cloudflare regels en de maatregelen in de PHP configuratie van kracht.
Klanten hoefden voor de PHP beveiligingsupdates niets handmatig te patchen of van versie te wisselen.
Inspelen op klanten die extra voorzorgsmaatregelen namen
De reactie op PHP2Shell reikte veel verder dan hostingproviders. Toen het nieuws over de kwetsbaarheden zich verspreidde, begonnen overheidsinstanties en andere organisaties wereldwijd websites tijdelijk offline te halen terwijl ze beveiligingsupdates voorbereidden.
In Nederland haalde het Nationaal Cyber Security Centrum uit voorzorg zijn eigen website offline. Ook overheidswebsites in Duitsland, Frankrijk, België en Finland gingen tijdelijk uit de lucht. In Japan gaf premier Sanae Takaichi op X een dringende waarschuwing af: websitebeheerders moesten de patches zo snel mogelijk installeren, of hun diensten tijdelijk stilleggen als ze niet meteen konden updaten.
Bij Kinsta zagen we dezelfde zorgen bij klanten. Ons supportteam kreeg veel meer vragen over PHP2Shell, en sommige klanten namen extra voorzorgsmaatregelen om hun websites te beschermen.
Zo gebruikten ze de feature om omgevingen op te schorten in MyKinsta om sites offline te halen, schakelden ze via Botbescherming sitebrede challenges in, of vroegen ze support om inkomend verkeer op serverniveau te blokkeren. Klanten hebben tijdens het incident uit eigen beweging zo’n 3.000 sites opgeschort.
Gezien de ernst van de kwetsbaarheden en de voorzorgsmaatregelen elders, waren die beslissingen begrijpelijk. Toch raadde ons engineeringteam klanten niet aan om hun websites bij Kinsta offline te halen. We hadden de noodregels voor de WAF van Cloudflare al op het hele hostingplatform ingeschakeld. Sites die online bleven, bleven dus beschermd, zonder onbereikbaar te worden voor bezoekers.
Ons supportteam begon klanten af te raden hun sites onnodig op te schorten, terwijl het engineeringteam de PHP patches verder uitrolde.
Zodra de beveiligingsupdates waren uitgerold, liepen we de opschortingen tijdens het incident na. Zo konden we zien welke websites klanten specifiek vanwege PHP2Shell offline hadden gehaald.
Die omgevingen heeft ons team daarna weer geactiveerd. Sites die om andere redenen waren opgeschort, bleven ongemoeid. Daarvoor moesten we opschortingen uit voorzorg onderscheiden van andere bewuste opschortingen, in plaats van simpelweg elke offline omgeving terug te zetten.
Onze teams blokkeerden dus niet alleen aanvallen en rolden patches uit, maar hielpen klanten ook om hun eigen voorzorgsmaatregelen terug te draaien.
Wat de reactie betekende voor Kinsta klanten
PHP2Shell vroeg om samenwerking tussen ons engineeringteam, ons supportteam en verschillende externe beveiligings- en infrastructuurpartners. Maar het patchen zelf regelde het platform.
Klanten hoefden niet bij te houden wanneer elke PHP release beschikbaar kwam, uit te zoeken welk gepatcht pakket hun website nodig had, of de updates zelf te installeren.
Farkas legde uit wat de reactie uiteindelijk betekende voor Kinsta klanten:
“Voor mij is de belangrijkste boodschap dat klanten hier helemaal niet over hoefden na te denken: wat ze moesten updaten, wanneer of hoe. Ze waren simpelweg beschermd op ons platform.”
De reactie van klanten tijdens het incident liet ook zien hoe belangrijk het is om over die beveiliging te communiceren. Sommige klanten haalden hun websites offline terwijl de noodregels voor de WAF al actief waren. Onze teams zetten daarna de omgevingen terug die vanwege de kwetsbaarheden waren opgeschort.
Intussen rolde ons engineeringteam de PHP beveiligingsupdates uit op honderdduizenden containers, zonder dat klanten de wijzigingen zelf hoefden te beheren.
Wil je de beveiligingsupdates en de afhandeling van het incident nalezen? Bekijk dan ons rapport over het PHP beveiligingsincident.
Wil je weten wat de kwetsbaarheden voor jouw website betekenen? Lees dan ons bijbehorende artikel: PHP2Shell: hoe Kinsta WordPress sites beschermde.
