De PHPocalypse bleef uit: waarom de PHP2Shell-waarschuwingen toch terecht waren

De PHPocalypse bleef uit: was de reactie op PHP2Shell dus overtrokken?

Was de reactie van vorige week op uitgelekte informatie over PHP-gaten overdreven? Die vraag komt op na flinke onrust in securitykringen en het preventief offline halen van websites vanwege twee kritieke kwetsbaarheden in PHP. Een concreet geval van een sitehack via PHP2Shell is nu bekend, maar de voorspelde massale pwnage is er niet van gekomen. Waarom niet? En kan de PHPocalypse alsnog komen?

Het viel al op dat media in Nederland flink meer aandacht voor het PHP-gevaar hadden dan die in het buitenland. Het leek er dan ook op dat beheerders van Nederlandse websites sneller en behoudender reageerden dan veel internationale collega's. Grote, belangrijke websites als Tweakers, RTL Nieuws, DigiD, MijnOverheid en de site van de Tweede Kamer gingen woensdag offline. Die sites gingen niet offline door hackaanvallen, maar uit voorzorg. In het buitenland gebeurde dit minder vaak. Sites die wel offline gingen, deden dat bovendien later.

Was Nederland te voorzichtig of zelfs voorbarig? Of is er door recente, grote hackaanvallen zoals bij Albert Heijn, ziekenhuizen en de overheid meer aandacht en ook meer besef? Het antwoord op die vragen ligt genuanceerd. Van overtrokken paniek is geen sprake, maar wel van voortschrijdend inzicht. En van onwetendheid, die voorlopig nog aanhoudt.

De dreiging van exploitcode

Woensdagochtend vroeg begon een woelige dag in de digitale wereld. Informatie was uitgelekt over twee kritieke kwetsbaarheden in de veelgebruikte scriptingtaal PHP. De schrik daarover werd aangejaagd door een prematuur gepubliceerde video waarin snel en makkelijk hacken van websites werd gedemonstreerd. Patches voor die twee gaten waren allang in de maak, maar zouden donderdag uitkomen.

Gaten in PHP veroorzaakten leed en dreigden het internet in brand te zetten. Bron: Tweakers

Het informatielek en het feit dat proof-of-conceptcode (poc-code) bestond, doorkruisten de precies geplande, verantwoorde onthulling van de kwetsbaarheden. Die onthulling moest samenvallen met de release van patches voor PHP. De premature onthulling ging niet gepaard met publicatie van exploitcode, maar de demonstratievideo bewees dat misbruik mogelijk was. Het is dan in de regel slechts een kwestie van tijd voordat andere hackers eigen exploitcode weten te maken.

Claudeviolen

Soms houden kwaadwillenden exploitcode onder de pet om die voor eigen doeleinden te gebruiken. Soms maken securityonderzoekers die openbaar om de wereld te waarschuwen, hoewel dat ook een olievlekwerking kan hebben. Elke minder begaafde aanvaller kan ermee aan de slag om hackpogingen te ondernemen. Daarmee zijn hackaanvallen niet per se succesvol, maar de dreiging neemt wel toe.

Het gebruik van AI-tools legt de lat nog wat lager en verhoogt het tempo van exploitontwikkeling. AI-toepassingen zoals Claude van Anthropic versnellen ook het uitvogelen van misbruikmogelijkheden, zelfs als er nog geen exploitcode beschikbaar is. Tweakers-beheerder Kees Hoekzema legde al uit 'dat tegenwoordig iedere claudeviool eenvoudig met AI een exploit kan maken op basis van relatief weinig informatie'.

AI-tools zoals Claude kunnen mensen helpen met complexe taken. Bron: Anthropic

De geplande patchrelease ging op de schop door het informatielek, het verschijnen van poc-code én de opdoemende dreiging van meer exploitcode. In plaats van afgelopen donderdagmiddag om 17.00 uur Nederlandse tijd kwamen de patches woensdagmiddag om 16.00 uur. Tot die tijd was het echter afwachten, scannen, piekeren, officieuze adviezen voor beschermende maatregelen evalueren en drastische stappen overwegen. Zo'n drastische stap was het offline halen van systemen die PHP gebruiken.

Aanvankelijke inschatting

Whitehathackers en beheerders gingen aan de slag om mogelijke exploitcode te testen en de impact van maatregelen in te schatten. Ondertussen werd het dreigingsniveau als hoog ingeschat. Dat kwam onder meer door het toegekende cijfer van 9.2 op de tienpuntenschaal van het Common Vulnerability Scoring System (CVSS). Die scores voor kwetsbaarheden zijn gebaseerd op hoe groot de impact is en hoe gemakkelijk misbruik mogelijk is. Voor de twee PHP-gaten (CVE-2026-109618 en CVE-2026-109619) was de ernst groot en werd misbruik als makkelijk ingeschat.

De aanvankelijke inschatting was niet alleen gebaseerd op de CVSS-scores. Het getoonde gemak en de hacksnelheid in de uitgelekte video voedden de vrees voor een PHPocalypse. Dat gold ook voor sombere opmerkingen van PHP-kernontwikkelaars en waarschuwende analyses van securityonderzoekers. Ook het Nationaal Cyber Security Centrum (NCSC) van de Nederlandse overheid was een van de vele partijen die waarschuwden. Die waarschuwing was gebaseerd op de toen beschikbare informatie, vertelt de woordvoerder van het NCSC aan Tweakers.

Bijgestelde inschatting

Het Nederlandse cybersecurityorgaan heeft zijn alarmmelding over de PHP-gaten eind vorige week aangepast. De ernst van deze kwetsbaarheden is nog altijd groot, maar de inschatting dat misbruik makkelijk zou zijn, is inmiddels bijgesteld. "Misbruik is ingewikkeld, updaten blijft het advies", stelt het NCSC. Uit nader onderzoek bleek 'dat het misbruiken van deze kwetsbaarheden ingewikkeld is en de kans op grootschalig misbruik kleiner dan eerder werd ingeschat'.

Beeld: NCSC

Deze niet onbelangrijke nuancering komt ook van securityleveranciers als Sophos en Trail of Bits. Het NCSC vertelt Tweakers dat de eerder beschikbare informatie 'wees op een risico op grootschalig misbruik'. "Naarmate er meer informatie beschikbaar kwam en we verder onderzoek konden doen, bleek dat voor succesvol misbruik aanzienlijke kennis van PHP nodig is", vertelt de woordvoerder. "Nieuwe inzichten kunnen ertoe leiden dat we een eerdere risico-inschatting bijstellen, zoals ook in dit geval."

Bitcoinbuit gestolen

Bij het NCSC is tot op heden een geval bekend van een hack via de PHP-gaten. De NCSC-woordvoerder stelt dat er nog onderzoeken lopen en erkent dat daaruit later kan blijken dat er meer PHP-misbruik is gepleegd. Niet elke aanvaller of inbreker maakt meteen gebruik van onrechtmatig verkregen toegang tot sites en servers.

Tweakers-beheerder Hoekzema vertelt dat er 'zeker al is gehackt en gepwnd'. Hij noemt het inmiddels bekende geval van Steal My Bitcoin. Die hackuitdaging had een wallet met zo'n tweeduizend dollar in bitcoin op de server staan, waarop de kwetsbare PHP-versie 8.4.26 draaide. Deze site ging 'in minder dan een dag' voor de bijl. Mogelijk worden er op termijn meer gevallen bekend van sites waarvan de beheerders nu nog niet naar buiten treden óf nog niet weten dat ze via PHP zijn gehackt.

Bitcoinbuit door PHP2Shell. Beeld: Steal My Bitcoin

Het zekere voor het onzekere nemen

Nederland heeft volgens de woordvoerder van het NCSC 'de goede keuze gemaakt' door snel te handelen en onder meer offline te gaan. Dat laatste deed het cybersecurityorgaan zelf ook. "Het zekere voor het onzekere nemen", aldus de woordvoerder. Voor experts en beheerders speelden dezelfde factoren een rol: de spaarzame informatie die toen bekend was, de exploitvideo waarin meerdere veelgebruikte webframeworks binnen enkele seconden werden gehackt, de sombere opmerkingen van PHP-ontwikkelaars en de alarmerende inschattingen van securityonderzoekers.

Daarbij was er ook sprake van proof-of-conceptcode die openbaar beschikbaar was, geeft Tweakers-beheerder Hoekzema aan. Hij benadrukt dat je zulke code nooit zomaar moet uitvoeren, omdat die zelf malware kan zijn. De beschikbaarheid van die code en de mate waarin het online gedeeld werd, gaven wel de indruk van legitimiteit. Op basis van de informatie en ontwikkelingen van toen 'zou ik nu ook de website weer offline halen', zegt Hoekzema.

Tweakers offline vanwege PHP-lekken, 21 oktober 2026

Achteraf toch mitigatietips

Deze drastische stap was misschien niet gezet als bepaalde informatie eerder was gedeeld, geeft hij wel aan. Vanuit PHP werd gemeld dat de patches vervroegd zouden uitkomen en dat het installeren daarvan de enige echte bescherming was. Achteraf kwamen er alsnog adviezen voor mitigaties die wel enigszins hielpen tegen misbruik van de kwetsbaarheden.

"Met die informatie hadden we wellicht een andere afweging gemaakt, bijvoorbeeld read-only gaan of slechts heel beperkt functionaliteit uitzetten." Die laatste mitigerende maatregel kon bijvoorbeeld bestaan uit het blokkeren van bestandsuploads. Hoekzema baalt ervan dat de informatie over mitigaties niet eerder is gedeeld.

Hij spreekt het idee tegen dat de securitydreiging rond de PHP-gaten met een sisser is afgelopen. Hoekzema wijst erop dat er nu meerdere gevallen van werkende poc-code zijn 'en dus daadwerkelijke exploits' in omloop waarmee servers die PHP draaien zijn te hacken.

Met AI van moeilijk naar makkelijk

Terwijl onder meer het NCSC nu stelt dat misbruik moeilijk is, blijkt het zeker niet ondoenbaar. Een hacker vond een Bitcoinbuit van tweeduizend dollar wel de moeite waard om een exploit in te zetten. Voor zware cybercriminelen is dat bedrag mogelijk niet interessant genoeg. Dit inmiddels bekende geval van Steal My Bitcoin lijkt er dus op te wijzen dat gewone aanvallers de beschikking hebben over werkende PHP-exploitcode. Misschien komt er nog een bijstelling van de NCSC-inschatting dat misbruik moeilijk is?

Het gevaar zit nu niet puur en alleen in beschikbare poc-code of werkende exploitcode. Dankzij AI-ondersteund ontwikkelwerk kunnen mensen ook snel werkbare exploitcode maken. Nu de patches zijn uitgebracht, valt AI in te zetten om te zien wat die updates precies veranderen. Mogelijk dekt een patch een kwetsbaarheid niet volledig af en kan die dus alsnog worden misbruikt met aangepaste exploitcode.

Het Cyber Verification Program voor Claude Mythos legt beveiligingsgrenzen op. Beeld: Anthropic

"In het verleden zouden er misschien tien mensen in de wereld zijn geweest die op basis van zo'n patch een exploit konden maken, maar nu kan iedereen dat", legde Hoekzema vorige week al uit. Voor tien van zulke klassieke experts zouden de doelwitten een selecte groep sites vormen. Die groep zou veel kleiner zijn dan die van moderne aanvallers die AI gebruiken. "Dat die 10 mensen ons zouden targeten, was niet te verwachten, maar als iedereen het kan, dan weet ik dat er in no time ineens mensen in onze servers zitten."

Hij voegde daaraan toe: "Een paar jaar geleden was het niet bij mij opgekomen om offline te gaan voor een patch die een paar uur later beschikbaar zou zijn. De kans dat iemand in de tussentijd een werkende exploit zou maken en dat die persoon ons zou targeten, was zo klein dat je het niet eens zou overwegen. Maar nu is dat risico veel groter geworden."

Ongemerkt, ongepatcht of antiek

Het risico dat aanvallers zijn binnengekomen, kan harde realiteit zijn voor sites die minder waakzaam en snel waren. De kans bestaat dat systemen ongemerkt gehackt zijn. Daarbij kunnen binnengedrongen aanvallers zich bewust koest houden. Dit mogelijke securityprobleem speelde niet alleen op de woelige woensdag waarop informatie uitlekte en de patches uiteindelijk uitkwamen. Beheerders van sommige sites installeerden die updates minder snel, waardoor de theoretische hacktijd langer was dan die ene dag.

PHP-mascotte. Bron: PHP.net, Vincent Pontier

Sommige gebruikers zijn nog wat langer kwetsbaar. Bepaalde systemen zijn namelijk afhankelijk van leveranciers die de nieuwe PHP-versies moeten opnemen in updates voor hun eigen software. Voorbeelden hiervan zijn nas-apparaten zoals die van QNAP, netwerkapparatuur zoals die van Citrix en beveiligingssystemen zoals die van Palo Alto. PHP-installaties op zulke producten zijn niet per definitie bereikbaar vanaf het internet, wat het hackrisico verkleint maar niet volledig wegneemt.

Naast gebruikers die minder snel patchen of op hun ict-leveranciers moeten wachten, loopt nog een groep langer risico. Deze groep bestaat uit gebruikers met niet meer ondersteunde PHP-releases van vóór versie 8.2. Die verouderde releases draaien op meer dan een derde van alle PHP-gebruikende websites. Volgens gebruiksmetingen van W3Techs draait 7,7 procent nog de 5-serie en 27 procent de 7-serie. Van de 64,2 procent die de 8-serie draait, gebruikt een onbekend deel een niet-ondersteunde versie. Tot de 8-serie behoren PHP-versies 8.0 en 8.1, waarvoor de PHP-ontwikkelaars geen patches uitbrengen.

Bekend gevaar

Vanwege de ernst van de twee kwetsbaarheden biedt het PHP-beveiligingsteam wel broncode voor zogeheten backports van de patches. Deze backports zijn voor PHP-versies 7.4, 8.0 en 8.1. Daarmee zijn die oudere versies alsnog te beveiligen tegen PHP2Shell. Het NCSC adviseert in een beslisboom over de PHP-kwetsbaarheden om oudere PHP-versies offline te halen en te upgraden naar versies die wel worden ondersteund.

PHP-beslisboom. Bron: NCSC

Het verstandigst is om patches te installeren en ondersteunde softwareversies te gebruiken. Bij de meeste hackaanvallen misbruiken aanvallers bekende kwetsbaarheden waarvoor al patches beschikbaar zijn. Dat geldt ondanks de aandacht voor en zorgen over zerodaygaten als PHP2Shell. Zerodaygaten zijn kwetsbaarheden waarvoor nog geen patches beschikbaar zijn.

Een bijkomende complicatie is dat bekende kwetsbaarheden soms geen patches krijgen, bijvoorbeeld in oudere PHP-versies en in apparaten waarvan de fabrikant het ingebouwde PHP niet bijwerkt. De sombere voorspelling is dan ook dat PHP2Shell een lange staart heeft.

_{Redactie: Jasper Bakker • Eindredactie: Monique van den Boomen}

Reacties (39)

[Cristan]

My bitcoin was stolen after 19.28 hours

Maar van die 19 uur serveerde die pagina er 17 uur alleen een statische pagina. Toen er een echte PHP pagina live ging was dit in 2 uur gehackt (bron: deze video van liveoverflow). En in die 2 uur werd die pagina zo gebombardeerd dat er nauwelijks een request tussen te krijgen viel.

[Henk1827]

Die site had de perfecte paramaterset ingesteld voor de exploit. In de echte wereld zijn die perfecte parametersets er niet en daarom zijn er nagenoeg geen succesvolle hacks geweest.

[Groentjuh]

In het begin draaide de website nginx en serveerde via PHP's dev server een statische index.html pagina. Daarmee kon het probleem niet uitgebuit worden, want met statische index.html pagina wordt php zelf dus niet echt aangesproken. Binnenkomende multipart-form werden dan ik niet verwerkt in die configuratie.

Daarna werd het nginx met PHP's dev server, die wel PHP-code serveerde. Dat is een ongebruikelijke setup. Nginx/Apache met bijvoorbeeld php-fpm zou gebruikelijk zijn. Voor de exploit zou Apache met mod-php ideal zijn geweest. Juist zo'n ongebruikelijk setup is in mijn mening juist geen "perfecte parameterset" te noemen. Het enige dat je kunt zeggen is dat de x-powered-by header uit had kunnen staan.

Kun jij aangeven waarom dit volgens jou zo'n "perfecte parametersets" was?

Tuurlijk zou het ook nog eens achter een WAF of Cloudflare kunnen zijn gezet, maar het doel van die hele website was dat deze gehackt zou kunnen worden met PHP2Shell; niet het testen van de WAF/Cloudflare.

[paradoXical]

Ik heb mijn servers preventief uit gezet, had op dat moment geen tijd om een goede beslissing te nemen, dus mijn klanten geinformeerd, en we hebben er precies 6 uur uit gelegen. Iedereen had er begrip voor en de schade valt uiteindelijk reuze mee. Better safe then sorry, en weer een ervaring rijker.

[Wouterie]

Ik heb nog wel een stevig gesprek gevoerd met één van onze leveranciers die zonder enige vorm van communicatie de stekker eruit trok waardoor meerdere kritieke processen niet netjes konden worden afgesloten. De schade valt natuurlijk wel mee, maar zo hebben we het gewoon niet afgesproken.

Wat ik niet snap is dat de kwetsbaarheid 's ochtends al was gelekt en 's middags zou er een patch komen. Zeg dan 's ochtends dat je de systemen down brengt om (ik noem wat) 11 uur en na de patch weer opstart. Maar nee, de leverancier kwam er ergens in de loop van de dag achter dat er een kwetsbaarheid was en trok de stekkers eruit.

Ik vind daar wat van, maar helaas is mijn directie ervan overtuigd dat het een prima actie was. Jippie... paniekvoetbal. Zo doen we het dus voortaan. Niks SLA's en andere afspraken! Gewoon de stekker eruit trekken.

[fenrirs]

en, wie had je de schuld gegeven als ze het gewoon hadden laten draaien? Al dan niet met waarschuwing?

Ik heb zelf ook een site uit de lucht gegooid, simpelweg omdat er geen mogelijkheid was om heel snel te patchen. Een aantal processen was daardoor inderdaad niet mogelijk. Jammer dan.

Het toeval wil dat er voor diezelfde processen een dag later er een fysieke calamiteit was (met reëel gevaar). Moet je dan ook eerst maar over in discussie gaan? Nee, dus gewoon afsluiten die handel.

[Reactie gewijzigd door fenrirs op 28 oktober 2026 10:07]

[Wouterie]

Het gaat mij om de timing. Ze wisten 's ochtends al dat het lek erin zat, maar besloten 's middags de boel plat te gooien. Gooi het dan meteen plat of communiceer over een tijdsstip. Dat het plat moest, dan was duidelijk.

[YGDRASSIL]

Je leverancier had zich aan de SLA kunnen houden met een reeele kans om gehacked te worden. De inschatting was blijkbaar dat dit voor zijn klanten de betere weg was. En natuurlijk is er paniekvoetbal als er iets onverwachts aan de hand is. Als er een brand in het gebouw ernaast is zal misschien de stekker er op dezelfde manier uitgaan. En dan is het ook paniekvoetbal en wel terecht?

[Wouterie]

Het gaat mij op de timing. 's Ochtends wist de hele wereld dat er een lek zat, maar de leverancier besloot 's middags pas de boel plat te gooien. DAT het plat moest, dan stond als een paal boven water, maar dat het op deze manier moest dat vind ik een beetje raar.

[HanBeert]

En als het systeem gehacked was had je gezegd: "Waarom is dat systeem niet preventief offline gehaald."

[Wouterie]

Het gaat mij om de timing. Ze wisten 's ochtends al dat het lek erin zat, maar besloten 's middags de boel plat te gooien. Gooi het dan meteen plat of communiceer over een tijdsstip. Dat het plat moest, dan was wel duidelijk. Al die uren dat het niet plat was stond het open en was er dus klaarblijkelijk niets aan de hand.

[eborn]

Als je voor SLA's betaald en daar afspraken over hebt lopen, dan is het inderdaad niet netjes. Als je denkt dat je een SLA hebt (zoveel zoveel klanten die 99.99% uptime garantie ergens zien staan), dan is het ook niet geweldig, maar als je met elk bedrijf eerst 2 uur moet gaan overleggen voordat er stappen gezet worden, dan kun je als dienstverlener beter niets doen. Want de ervaring leert dat zelfs SLA contacten en SLA escalatie contactpersonen toevallig net op vakantie zijn en niemand een beslissing durft te nemen.

[Wouterie]

Het gaat mij om de timing, niet om de noodzaak. Het was 's ochtends als bekend maar 's middags gooiden ze de boel pas plat. Tijd genoeg om te communiceren en een plan te maken.

Bij een noodsituatie geldt nog steeds dat er gecommuniceerd wordt. Dat mag éénzijdig, een simpele mededeling.

[GrooV]

Misschien voor dit incident, maar we kunnen toch echt niet bij ieder lek de servers er uit gaan trekken zonder te weten wat de gevolgen zijn. Daarom altijd een gelaagd veiligheidssysteem gebruiken. Een WAF had dit ook gewoon tegen kunnen houden, in combinatie met het uitzetten van de upload functionaliteit had je gewoon door kunnen draaien.

[Cergorach]

Dat is wel een heel positieve conclusie een week na het incident... Helemaal omdat er al aanvallen werden uitgevoerd voordat dit naar buiten kwam, de helft van de wereld nog niet heeft gepatched en de andere helft die wel heeft gepatched niet meer heeft gedaan dan dat. Ik verwacht dat het aantal bedrijven/mensen dat daadwerkelijk de data op die servers is gaan checken en de daarbij horende databases echt miniem is.

Het zou zomaar kunnen dat we nog jaren later opmerkingen gaan krijgen van: "He? Wat doet die user met admin rechten in de database? Die ken ik helemaal niet. Het zal wel goed zijn..."

[eborn]

Een goede hacker dumpt via de shell een database, biedt die via een upload folder aan, download de file en verwijdert deze weer. 99% van de sites zal dat never nooit merken.

[rescue]

Mijn hosting provider gaf de ochtend voor het beschikbaar komen van de patch aan dat ze passende maatregelen hadden genomen en geen actie nodig was. Hoewel niet helemaal duidelijk wat voor maatregelen heb ik de site laten draaien.

Toen alles opeens offline ging heb ik me wel afgevraagd of ik een bijzondere provider heb of dat er teveel paniek was.

[eborn]

Ga er maar vanuit dat ze een aantal mitigaties langs zagen komen (waarvan een PHP developer later aangaf dat ze onvoldoende waren) en op basis daarvan hoopten het even te kunnen rekken. Offline halen van al je diensten kan SLA gevolgen hebben die je op grote schaal niet wilt hebben. Alles laten draaien en later eventueel mea culpa roepen en op kosten van de klant een backup terugzetten is dan efficiënter.

[Sebas1979]

Grote, belangrijke websites als Tweakers, RTL Nieuws, DigiD, MijnOverheid en de site van de Tweede Kamer

Kijk, prioriteiten

[418O2]

Y2k all over again. "Er was niks aan de hand!". Omdat er is ingegrepen

[Reactie gewijzigd door 418O2 op 28 oktober 2026 10:14]

[Zoop]

"waar is dat gat in de ozenlaag dan"

[jj71]

"Claudeviolen" Ha ha

[mr_evil08]

Een beetje hacker maakt een achterdeur in het systeem en wacht tot de storm is gaan liggen voordat verdere acties worden ondernomen om minder op te vallen.

[ctrl-tab]

Je vraagt je af hoe lang deze vulnerabilities al stilletjes bekend waren, bij bijvoorbeeld state actors of hun partners

[Sangre]

om Peter Pannekoek even te quoten:

"Je zegt ook niet: Achteraf gezien hadden we het hek om het tijgerverblijf helemaal niet nodig, want er is in 20 jaar nooit een tijger ontsnapt"

Daar moet ik altijd aan denken als er achteraf commentaar komt dat het probleem niet zo groot was als gedacht. :-)

[Kallik]

Wat voor onzin ben je allemaal aan het verkondigen hier?

Moeten we je echt gaan uitleggen hoe het kan dat een bug die al jaren lang bestaat pas een probleem word van zodra deze ontdekt word? Om nog maar te zwijgen over het feit dat PHP2Shell absoluut wel uit te buiten viel. Het klinkt vooral alsof je je hele verhaal hier basseerd op de onvolledige PoCs (want ik kan eerlijk gezegd niet inzien waar je anders vandaan zou halen dat de exploit niet bruikbaar was) en er dan maar vanuit gaat dat omdat die PoCs niet volledig waren en daardoor niet werkte, dat betekend dat de bug niet te exploiten viel. Niets is minder waar. Amazon, Cloudflare, WatchTower, etc. claimde allemaal succesvolle aanvallen te hebben gedetecteerd.

[c-nan]

Niets is minder waar. Amazon, Cloudflare, WatchTower, etc. claimde allemaal succesvolle aanvallen te hebben gedetecteerd.

Hier wil ik bronnen van zien. Dat is namelijk niet wat ik heb gelezen.

Ik ben intensief bezig geweest rondom PHP2Shell en kwam snel tot de conclusie; storm in een glas water. Is de kwetsbaarheid aanwezig? Ja. Is de impact groot? Is het makkelijk uit te buiten? Nee.

De kwetsbaarheid is moeilijk uit te buiten, na 2 of 3 dagen had ik een werkende exploit. Maar de parameters moeten dan echt 100% kloppen.

[Dynas]

geloofwaardige conclusie als je zelf al aangeeft dat de impact groot is en het jezelf gelukt is het werkend te krijgen...

[eric.1]

Die bug was ook al jarenlang bekend hoor. Alleen heeft niemand, publiekelijk, de connectie gelegd tussen de bug in kwestie en de mogelijkheid om het vanaf een externe locatie uit te buiten. Tot...ergens deze zomer dan, toen de bal is gaan rollen.

Ik denk dat eigenlijk de enige echte overdreven reactie de X-post van een van die maintainers is geweest. De "I know too much"-reactie. In plaats daarvan hadden ze gewoon officieel mitigaties kunnen delen die het gewoon veel moeilijker maken om uit te buiten. In plaats van "Only patching helps". Nu moesten we van derden lezen hoe we dit het beste konden aanpakken totdat de patch er kwam...

En dan zie je de patch in kwestie, en de commits in de repo, het wekt geen vertrouwen - voor een taal die op serieus veel publiekelijk beschikbare servers draait.

En al die bedrijven die roepen dat ze al lang en breed aanvallen hebben gedetecteerd...het kan, maar vergis je niet in de marketing van deze bende...iedereen wilde de spotlight pakken.

[demonite]

Je stelt het wel erg zwart-wit... de werkelijkheid ligt ergens tussen in.

Wat mij betreft beter safe than sorry. Verder is het ook niet verkeerd voor het besef hoe afhankelijk we eigenlijk wel (of niet) zijn van online diensten.

[olafmol]

Haha ja. Soms is het wel goed om tegen de standaard-statements in te gaan. Tuurlijk zijn het allemaal grijstinten maar ik wordt echt allergisch als ik weer zo'n "cyber security expert" in de krant lees die keihard claimt dat dankzij zijn getoeter op sociale media in Nederland alles goed is gegaan, maar dat andere landen "grootschalig de sjaak zijn". Alleen nu hoor je niks meer van meneer. Ik vind dat deze types ook een verantwoordelijkheid hebben.
NB het is ook wel veelzeggend dat bij de BBC een "expert" zat die nog nooit van PHP had gehoord..

[Vinnie.1234]

Toch heb ik liever dat websites 100 keer op zwart gaan wat achteraf niet nodig bleek te zijn dan dat ze 1 keer niet op zwart gaan en mijn gegevens worden gelekt. Kijk Tweakers mogen ze van mij jatten wat ze willen, maar overheidswebsites zijn al een ander ding.

[der_joachim]

Tja. Men zou vooral eens moeten kijken naar hoe dit de volgende keer beter en zonder paniek opgepakt kan worden.

Jij noemt het 'paniek', ik noem het 'voorzorg'. Ik beheer een SaaS omgeving, geschreven in PHP. Toen het even vrij ernstig leek, heb ik de omgeving meteen 'uit' gezet, dus met een statische storingspagina en een begeleidende tekst dat uit voorzorg de service niet beschikbaar was.

Ik had me er al bij neergelegd dat ik door het stof zou moeten gaan naar de klanten toe, maar er is geen enkele klant geweest die me dit kwalijk heeft genomen of dit als 'paniek'-actie heeft ervaren. Zelfs een week na dato krijg ik nog bedankjes van klanten omdat ze de perceptie hebben dat we de veiligheid van hun data serieus nemen.

Daarnaast vraag ik me af hoe ze hadden gereageerd als wij vrolijk waren doorgegaan terwijl her en der andere PHP-servers wel plat gingen. Zelfs als er niets gebeurd was, zouden we lastige vragen hebben gekregen. En terecht.

[Dynas]

exact dit, onder tijdsdruk met beperkte kennis heb je de risico's afgewogen en gehandeld. De gevolgen hadden groot kunnen zijn met blufpoker, nu was het beperkt tot maar een aantal uren downtime. Professioneel gehandeld wat zich nu uit in waardering vanuit klanten.

[GrooV]

Natuurlijk was er nu draagvlak, ook omdat de overheid offline ging. Maar wat als dit volgende week weer gebeurt? En de week daarop weer?

Je kan niet bezig blijven met je site offline halen, beveiliging moet actief gebeuren, meerdere lagen, continue

[Dynas]

nieuwe tijden, nieuwe uitdagingen...
klanten zullen dit op korte termijn begrijpen
op lange termijn niet, en daar zal het kaf zich van het koren gaan scheiden.