Ontdekker PHP-kwetsbaarheden lekte per ongeluk zelf vroegtijdig details uit

Een van de ontdekkers van de recente PHP-kwetsbaarheden lekte zelf vroegtijdig informatie over het bestaan ervan. Daarna publiceerde een ander bedrijf vóór het verstrijken van het embargo de komende patch. Hierdoor moesten de PHP-makers vervroegd een update uitbrengen. In afwachting daarvan gingen wereldwijd talloze websites uit voorzorg offline.

Dit nieuws in het kort

• Beveiligingsonderzoekers van Calif hebben kwetsbaarheden in PHP ontdekt en dit zelf uitgelekt.
• Dat zorgde nog niet voor exploits. Dat gebeurde pas nadat een bedrijf het embargo voor de patch schond.
• PHP is een scriptingtaal die door een groot deel van het internet gebruikt wordt. Vanwege de kwetsbaarheden gingen veel websites uit voorzorg offline.
• Er is inmiddels een update uitgebracht, maar de echte gevolgen van de kwetsbaarheid zijn nog onduidelijk.

In een blogpost legt de PHP Foundation uit waar het misging in aanloop naar de PHP-kwetsbaarheden die op 21 oktober voor grote problemen op het internet zorgden. Dat begon bij de circulatie van twee identificatienummers uit het Common Vulnerabilities and Exposures-systeem (CVE) die bedoeld waren voor de betreffende kwetsbaarheden.

​​​​​​Wat is PHP?

PHP is een veelzijdige scriptingtaal die dynamische webpagina's kan aanmaken. Wereldwijd gebruikt 69,3 procent van alle websites PHP. PHP vormt de basis voor het veelgebruikte WordPress en wordt ook gebruikt in Joomla, Drupal, Magento en andere websoftware. Tweakers schreef een uitgebreid achtergrondverhaal over de kwetsbaarheden.

Dit was voor de PHP-makers de reden om vervroegd een patch uit te brengen. De organisatie noemt de CVE-vermeldingen een lek, maar voor zover bekend is het gebruikelijk dat deze identificatienummers al voor de daadwerkelijke openbaarmaking van een kwetsbaarheid bekend worden. Er waren toen nog geen technische details bekend.

Video te vroeg en embargo gebroken

Toch kondigde de organisatie achter de opensourcesoftware eerder dan gepland een komende patch aan. In reactie op deze aankondiging en het 'uitlekken' van de CVE-nummers publiceerden beveiligingsonderzoekers van Calif een dag te vroeg een video met proof-of-conceptaanvallen die gebruikmaakten van de kwetsbaarheden. Ook advies aan enkele grote infrastructuurproviders lekte vroegtijdig uit.

Volgens onderzoek van de PHP-makers was er echter nog geen aanwijzing dat de uitgelekte informatie daadwerkelijk tot werkende exploits en misbruik van de kwetsbaarheden leidde.

Dat veranderde toen cyberbeveiligingsbedrijf Chainguard vóór het verstrijken van het afgesproken embargo zijn beveiligingsupdates publiceerde. Het bedrijf kreeg vroegtijdig toegang tot de patches, zodat gebruikers snel hun systemen konden updaten. De publicatie vond zes uur voor de gecoördineerde release van de beveiligingsupdates plaats.

Grote gevolgen

Door de verschillende lekken en fouten kwam informatie over de kritieke kwetsbaarheden te vroeg naar buiten. Omdat kwaadwillende ontwikkelaars die informatie kunnen gebruiken om exploits te maken, moesten wereldwijd websites offline om cyberaanvallen te voorkomen. Tweakers was een van die websites.

Mogelijk zijn de gevolgen ook na de patch groot. De kwetsbaarheden zitten in vele versies van PHP, waarvan de meeste niet meer ondersteund worden en dus geen beveiligingsupdate krijgen. Gebruikers wordt daarom aangeraden om direct naar een nieuwe versie te updaten.

Reacties (121)

[Stetsed]

Zoals ik all bij de andere post had gezet is wat chainguard doen echt een ander iets. De leaked video was van de POC, en gaf inderdaad heel wat detail wat betekende dat mensen de richting in konden kijken. Maar chainguard besloot om gewoon de binary met de patch vrij te maken, en met binary diffs kan je redelijk makkelijk achterkomen wat we nou de verandering is.

Dit is iets wat ik nooit in me leven had verwacht van een security bedrijf. Er zijn veel argumenteren dat de update eerder uit had moeten komen dan de origineel tijd, zeker na de video leak. Maar dat chainguard dan besloot blijkbaar zonder discussie dit zelf te doen schikt well de fundementeel betrouwbaarheid in deze situatie. En ik denk dat er zeker fall out zal zijn aan alle kanten na deze acties.

Want ja, hoe kan chainguard nu worden vertrouwd in de toekomst, misschien was het de goede keuze, misschien waren er genoeg echte POC’s dat de release datum eerder had moeten komen. Maar in basis was dit niet een keuze die chainguard moest maken. Dus zelfs als het de correcte keuze was hoe kan het nu vetrouwd worden dat chainguard in de toekomst dit niet weer zal doen

NOTE Ik will het duidelijk maken dat ik niet zeg of het eerder releasen van de patch fout of slecht zou zijn, maar puur over dat chainguard deze keuze niet mocht maken, het was niet hun keuze om te maken.

[Reactie gewijzigd door Stetsed op 21 oktober 2026 20:23]

[pdidi]

Hoewel de X-Post van Chainguard niet de CVE's benoemde, liet het niet veel aan de verbeelding over. Het lijkt puur ingegeven doordat er vanwege de gelekte Calif video er steeds meer PoC's kwamen en het ze te heet begon te worden. De X-Post:
Two critical PHP vulnerabilities (CVSS 9.2) were disclosed today, allowing unauthenticated RCE on default configurations.

To help everyone patch fast we are making images for PHP 8.2, 8.3, 8.4, and 8.5 free for anyone to use. You can access them here: https://images.chainguard.dev/directory/image/php/versions

Coordinated disclosure is hard, we appreciated everyone's help as we worked through this over the last several days.

[Stetsed]

Bedankt voor de update, inderdaad ik had nog geen officeele bron, maar dit is eigenlijk dicht bij genoeg, ja ze noemen niet de CVE's maar "Two critical PHP" met een CVSS van 9.2 de enige kandidaat is de vulnerabilities die nu open staan

-- Comments op basis van de post

En dit is waar ik het fundamenteel niet eens ben met Chainguard. Calif had zeker een fout gemaakt, en hier kwamen POC's uit. Maar tenminste volgens de PHP security team waaren dit nog verre van volledig exploitable en ik weet ook dat veel van de "PoC's" of andere exploits waren, of nog lang niet RCE hadden. Chainguard besloot toen, inderdaad hier zeggen ze het meer direct, om gewoon te doen.

Dus ze hebben hier gekozen dat inplaats van dat ze verder gaan met concensus, zichzelf voor trekken en gewoon een release doen. Waardoor het dan mogelijk is om via die images en binary diffing veel dichter bij en makelijker de exploit te vinden. "Coordinated disclosure is hard", nee, zij hebben gewoon er voor gekozen dat zij het beter weten.

Dus ik zal weer herhalen dat misschien had de release eerder moeten komen, maar fundamenteel heeft chainguard hier laten zien dat zij denken beter te weten en de keuze zullen maken zelfs als zij niet de eigenaar zijn. En ik verwacht zeker dat dit mogelijke permanente schade tot hun reputatie kan leveren.

[Reactie gewijzigd door Stetsed op 21 oktober 2026 20:21]

[ApexAlpha]

Het Php team zelf kan niet weten of die Poc's werkten of niet. Het Php core team heeft geen inzicht in het verkeer richting elke Php installaties.

Cloudflare heeft bevestigd dat ze al actieve aanvallen zagen.

Je hebt gelijk dat Chainguard het probleem wel weer groter heeft gemaakt. Zodra je de patch hebt kun je direct zien waar het probleem zat.

[Mania-92]

Ik moet dus juist eigenlijk klant van chainguard worden. Dan krijg ik schijnbaar het snelst noodzakelijke patches. Dat is natuurlijk hoe commercie werkt.

[Stetsed]

Dat is dus het ding, in deze situtatie. Maar het kan zeker in de toekomst betekenen dat chainguard helemaal geen patches ontvangt van te voren want ze kunnen geen garantie geven dat ze niet weer hetzelfde zullen doen als zij denken dat her eerder moet. Want de enige reden dat ze hem krijgen is omdat er het vertrouwen is dat zij zich zullen houden aan de gemaakte afspraak.

Dit is niet alsof chainguard de patch heeft gemaakt en dan niet wachten voor iedereen om dit te published. Dit was een update die vanuit een andere organisatie kwam, waar met een groot aantal bedrijven in vetrouwen zijn gebracht om in 1 keer hem overall vrij te laten. En chainguard besloot dat zij beter wisten en hem eerder vrij hebben gelaten, hebben hun gebruikers dus uren eerder gekregen? Ja, betekent dit dat het mogelijk is dat ze in de toekomst de patches helemaal niet krijgen en dus mogelijk later dan iedereen hem vrij kunnen geven en geen voorbereidings tijd hebben ook ja

[Reactie gewijzigd door Stetsed op 21 oktober 2026 19:49]

[Mania-92]

Chainguard claimt dat het de kwetsbaarheid al actief in het wild gesignaleerd werd. Stel dat is waar. En chainguard had gewacht tot 16:00. En in de tussentijd wordt een klant van chainguard gehackt. IANAL maar ik denk dat de volledige schade dan gewoon op chainguard geclaimt kan worden. Bovendien krijg je dan krantenkoppen 'Klant x van chainguard gehackt, gegevens van 80 miljoen gebruikers gelekt. Chainguard had de patch al op de planken liggen maar bewust niet uitgerold.' Dan kunnen ze de toko ook sluiten.

[Stetsed]

Het ding is zoals ik zij: Het kan zijn dat de keuze die chainguard maakte de correcte was, maar fundamenteel was het niet hun keuze om te maken. Want in wat ze deden hebben ze een binary die de exploit recreëren veel makelijker maakt publiek gemaakt. Waardoor elke andere partij, en het kan zeker zijn dat hierdoor andere partijen nog niet klaar waren.

Misschien moest de release date opgeschoven worden, maar het hele systeem is gebouwd op vertrouwen, dat wanneer er iets wordt gedeeld dit niet gewoon publiek wordt maakt. Dus het maakt niet uit welke redens chainguard had, fundamenteel was het niet hun keuze om te make.

Want nu kijk je vanuit de kant van chainguard, maar kijk eens even van de kant van elk andere van de waarschijnlijk dozijn aan bedrijven, de Debian security team, docker team, veel andere waarschijnlijk die allemaal zich well aan de regels hebben gehouden zodat iedereen klaar kan staan. Hoe kan iemand chainguard nog vertrouwen in de toekomst, dus ja misschien heeft dit chainguard problemen voorkomen, maar het kan zijn dat nu dus in de toekomst chainguard niks krijgt.

Zoals ik zij we zullen dit zien hoe het zich zal voorzetten, maar dat de CEO zo direct heeft gezegd dat hij WIST dat er nog een embargo was, en dat hij nog steeds heeft gezegd om het te doen, is vanuit het perspectief van samenwerking een gigantische rode vlag

[Mania-92]

Maar wat je dus voorstelt. Jij bent een beveiligingsbedrijf en je hebt een contractuele verplichting om klanten veilig te houden. Vervolgens heb je patch die je om 16:00 onder embargo mag publiceren. Om 10:00 heb je signalen dat de kwetsbaarheid actief wordt misbruikt. Maar je kiest er bewust voor om je klanten, die je contractueel moet beveiligen, 6 uur lang kwetsbaar te laten voor een kwetsbaarheid waarvan je weet (of denkt in ieder geval) dat die actief misbruikt wordt. Dát vind ik pas onverantwoordelijk. En als ik je klant was en in die 6 uur gehackt was, had ik tet alle schade op je verhaalt.

Dat anderen dan wellicht te laat zijn doet er niet toe. Je hebt een contract na te komen met je klanten, niet met anderen.

Overigens als de analyse van chainguard klopt, en de kwetsbaarheid actief misbruikt werd reeds, is het maar zeer de vraag of het publiceren van een patch zoveel kwaad heeft gedaan.

[divvid]

chainguard had ook kunnen kiezen om hun klanten te beschermen door desbetreffende sites tijdelijk off-line te halen totdat de patch beschikbaar komt. Het is dan een risoco van de klant om ze online te houden

[Mania-92]

Systemen van klanten offline halen omdat je een patch die je wel hebt, niet in wil zetten. Ik zie de ene na de andere schadeclaim al binnenvliegen.

[MSalters]

Geen kwestie van "niet willen " maar "niet mogen". Laat je klanten de PHP foundation maar aanklagen, die stelden het embargo in.

[mbbs1024]

Dan is de vraag maar of zo een embargo wettelijk is, want het gaat tenslotte over open source.

[MSalters]

Dat is een nogal vreemde redenatie. Het gaat hier om een embargo door de copyright eigenaar, het PHP Team. De nieuwe versie is pas open source als zij de source daarvan publiceren. En vanwege dat embargo gebeurde dat pas om 1600.

[mbbs1024]

Het is toch eerder gepubliceerd, want die beveiligingsfirma had het al.

[MSalters]

Onder embargo, niet onder de open source licentie.

[divvid]

als je de patch hebt is het simpel, deployen. Als je 'm niet hebt is offline halen veiliger.

publiceren voor embargo datem/tijd is gewoon not-done en helpt niemand. Maar laten we eerlijk zijn. de bug zit er al sinds 2012 in. Grote kans dat die gewoon bekend is bij de usual suspects. Die zijn dus nu hun 'speeltje' kwijt

[Reactie gewijzigd door divvid op 22 oktober 2026 11:23]

[Ilmar]

Het logische risico is echter dat bij de volgende kwetsbaarheid je als beveiligingsbedrijf gewoon niet op de embargo-lijst staat. Dan krijg je de patch pas om 16:00, tegelijk met alle aanvallers, terwijl de concurrenten wel een dag hebben om te implementeren en testen.

Kortom, je bent deze ene keer misschien een aantal uur sneller, maar als prijs betaal je dat je alle volgende keren later zult zijn.

[RBakkum]

Ik ben niet bekend met hoe dit normaal zou werken. Maar kan zo'n chainguard niet in een geval van een case dat ze zien dat het misbruikt wordt bij een omgeving daar in grijpen zonder het publiekelijk te delen?
Het feit dat ze een link actief delen is ook iets wat ze met betreffende partij alleen hadden kunnen delen. Of werkt dat in deze wereld niet zo?

[svenslootweg]

Dat anderen dan wellicht te laat zijn doet er niet toe. Je hebt een contract na te komen met je klanten, niet met anderen.

Dan moet je dus niet aan een coordinated-disclosure-proces deelnemen. Vrij simpel, lijkt me. Geen beloftes maken die je niet waar kunt maken.

Het 'onverantwoordelijk' noemen om je klanten geen patch te geven vind ik dan ook erg kort door de bocht, want het gevolg van dat wel doen is dat je iedereen die niet je klant is, aan een groter gevaar blootstelt. Je hebt ook nog zoiets als een verantwoordelijkheid naar de maatschappij.

[peterh]

Ik weet dat het bij sommigen tegen het zere been is, maar “zoals ik zij” kan toch echt niet?

[Gemeni]

En nu is Chainguard verantwoordelijk voor nog meer schade en is het vertrouwen in hen weg…

[Stphn75]

ik snap niet dat dit ge-plust wordt, ja, ze waren de eerste met de POC, op basis van wellicht inside information, dus, wat is dat dan waard?

het breken van het protocol kan zich zeker wreken, dus mogelijk worden ze in het vervolg niet meer deze voorinformatie.. weg voordeel..

nee, dit was een slechte stap.. en een grote

[Polderviking]

Ik denk niet dat chainguard kan blijven rekenen op early patches met dit gerommel.

[Triblade_8472]

Het zijn net mensen die er werken...

Alles wat fout kan gaan, gaat een keer fout. Dit was blijkbaar een hiaat in de instructies, technologie om dit te voorkomen, een persoonlijke vlaag van verstandsverbijstering of een combinatie hiervan.

Niet goed, maar menselijk denk ik dan. Iets om van te leren. Fouten maken is niks bijzonders, ervan leren zorgt juist voor vertrouwen mijns inziens. Niet van fouten leren zou wantrouwen moeten oproepen. Vallen en opstaan, toch?

[GrooV]

Het zijn net mensen die er werken...

Alles wat fout kan gaan, gaat een keer fout. Dit was blijkbaar een hiaat in de instructies, technologie om dit te voorkomen, een persoonlijke vlaag van verstandsverbijstering of een combinatie hiervan.

Niet goed, maar menselijk denk ik dan. Iets om van te leren. Fouten maken is niks bijzonders, ervan leren zorgt juist voor vertrouwen mijns inziens. Niet van fouten leren zou wantrouwen moeten oproepen. Vallen en opstaan, toch?

Nee chainguard profileert zich als de eerste en beste. Dit is gewoon bewust gedaan, zij kunnen nu tegen hun klanten zeggen dat ze de eerste waren

[Finraziel]

En dat was dan wellicht gelijk de laatste keer?

[Stetsed]

Ik kan hier geen confirmatie op vinden en geen officiële bron, maar zover ik kan zien(bedankt frackleboon), is dit niet een fout. Hier zegt een user dat het expliciet een instructie was(https://news.ycombinator.com/item?id=50176735), en in de geschiedenis van comments lijkt het waar te ze zijn dat dit de CEO van chainguard is.

Als dit inderdaad waar is, en dat zullen we leren over de komende dagen, is dit een expliciete instructie om de regels te negeren en om door te zetten. En dat zal gigantische schaden doen aan het vertrouwen in toekomstige responsible disclosures waar chainguard deel van is

[Reactie gewijzigd door Stetsed op 21 oktober 2026 19:46]

[Liveonline]

interessant https://blackoutmap.net/blog/php2shell

[Skit3000]

Achteraf gezien vond ik beter gaan op deze manier waarbij websites even op zwart gaan en iedereen de impact voelt, dan wanneer ze deze update gewoon normaal uit hadden gerold en sitebeheerders het maar als "gewoon weer een update" zouden hebben gezien (en dan weken/maanden wachten met installeren).

[SuperDre]

Misschien een kwestie van timezone verschil? Ingesteld op 14:00 local time, maar dat dat bij hun server bv 10:00 uur onze tijd was (waar het origineel voor ons 16:00 gereleased zou worden).

[svenslootweg]

De CEO heeft al publiekelijk toegegeven dat het bewust was. Bovendien worden dit soort dingen altijd in UTC gecoordineerd.

[Rob Coops]

En toch he, Google deed hetzelfde met de 90 dagen tijdslimiet waar men strak aan vast hield en aan alle kanten bedrijven in de problemen wist te brengen. Ondanks dat is 90 dagen nu de standaard niet wanneer het de ontwikkelaar schikt (soms zelfs jaren later)

Chainguard verkoopt een service die 0-CVE's belooft in hun images. Chainguard heeft vast een fout gemaakt in welke patches er in de volgende build zaten en op die manier niet met opzet de patches gepubliceerd. Althans ik heb niet de indruk dat men daar graag een rommeltje maakt van de security na dat ik al weer tijden met ze werk.

Ik heb geen idee hoe zij werken intern maar ik kan me nit helemaal voorstellen dat er een persoon is die de build samen stelt ik neem aan dat het simpel weg een CI process is dat alles met tag X in de volgende build mee neemt. En als iemand de patch van die tag heeft voorzien zonder er bij stil te staan dat dit een embargo zou kunnen schenden dan is dat natuurlijk verkeerd en moet men de processen wat aanpassen maar dat hoeft absoluut geen opzet te zijn.

Daar naast is het nu ook weer niet een heel groot probleem. Een van de dingen die dit laat zien binnen bedrijven die nu snel moeten reageren om zich tegen een mogelijke aanval te beschermen is of en hoe goed ze voorbereid zijn op een exploit die massaal misbruikt wordt maar waar nog geen patch voor beschikbaar is.
Kunnen we de sites snel genoeg uit zetten weten we wie die beslissing neemt en wie de site uitzet. Lopen we tegen problemen aan met processen die dit soort snelle acties onmogelijk maken, beheerders die niet beschikbaar zijn etc...

Als je je bedenkt dat in veel gevallen bedrijven nog steeds een nieuwe patch niet uitrollen in de eerste 3 tot 9 maanden na dat deze beschikbaar komt is 6 uur eerder dan gepland niet een hele grote ramp. Natuurlijk zouden system automatisch de patches op moeten pakken en zouden in veel gevallen bedrijven streng bestraft moeten worden als ze niet binnen 7 dagen de nieuwste patch uitrollen maar dat is niet het geval helaas.
Het enige land waarvan ik weet dat er in ieder geval voor banken een verplichting is om systemen up to date te houden is Singapore waar 6 maanden de deadline is (niet voor patches maar voor software die eol is, met als straf dat je je banking license kwijt kunt raken.
Dat is natuurkijk niet echt zinnig en ik weet uit eigen ervaring dat men pas dit jaar een upgrade naar RedHat 8 heeft gemaakt bij een van de grote banken voor systemen die de transacties ook voor Singapore de transacties verwerken dan durf ik met vrij grote zekerheid te zeggen dat dat niet echt iets is waar men boven op zit.

Ik zou maar wat graag zien dat zeker bedrijven die financiele data verwerken (alle bedrijven dus) verplicht worden om simpel weg binnen 7 dagen security updates uit te rollen. Waardoor de bedrijven die software leveren dus verplicht gaan worden om automatisch patches uit te rollen.Waardoor deze zelfde bedrijven de grappen zo als Microsoft regelmatig uithaalt waarbij systemen onbetrouwbaar worden of in sommige gevallen helemaal niet meer werken simpel weg hun klanten gaan verliezen en we eindelijk eens meer betrouwbare software gaan krijgen.
Ik weet dat veel mensen zullen roepen je weet niet waar je het over hebt. dat mag je best vinden daar heb ik geen last van. Maar uit eindelijk is er geen andere optie dan simpel weg te stoppen met het steeds maar achterhouden van systemen omdat bedrijven bang zijn dat een patch voor problemen zal zorgen. We zien de tijd tussen het vinden van een security probleem en een exploit in het wild terug gedrongen worden van dagen naar uren. We kunnen het ons niet langer veroorloven om te denken dat we de tijd hebben om te patchen, dat is simpel weg niet langer waar. Vast houden aan achterhaalde tijdlijnen is simpel weg niet iets dat zinnig is, natuurlijk duurt het nog wel even voor we veel sneller kunnen patchen en zullen er voorlopig nog bedrijven zijn die dit niet willen doen maar uiteindelijk zullen we voor het overgrote deel naar automatisch patching toe gaan waar bij het uitstellen van patches eerder als schandaalig dan als verstandig wordt gezien.

[TRS-3]

Het per ongeluk voortijdig lekken leverde weer onbetaalbaar veel reclame voor AI.

Want niet het feit dat de CVE-score hoog was (dat zegt wel iets over de ernst van mogelijk misbruik natuurlijk) maar het lekken vóór de patch was hier het grootste probleem.

[Nark0tiX]

Bizar dat dit al zeven jaar bekend was, en telkens vragen er over genegeerd werden. En als SOL het aangeeft er wordt geacteerd...

Krijg sterk het idee dat deze gewoon als backdoor werd gebruikt.

[SanderBos]

Nee, volgens de uitleg van met name Calif zit het toch anders.

Er was al lang een OutOfMemory bug bekend, maar na analyse was de conclusie dat het heel lastig te fixen was, en dat het heel lastig was om er een exploit voor te maken. Blijkbaar zijn er nu ook zo'n 5000 regels aan wijzigingen nodig geweest in alleen al de productiecode, dus dat het lastig was klopte blijkbaar, je moet bedenken elke van die 5000 veranderde regels kan weer andere bugs introduceren.

Het was blijkbaar eenvoudig om met een eerste request het systeem in vulnerable state te brengen, maar lastig om dan een 2e request te verzinnen die die state misbruikte.

Alleen dan komt veel jaren later ineens AI langs, en die zegt ik maak wel even een exploit geen probleem.

Hier vertelt 1 van de personen die de exploit heeft gevonden er meer over.

[Polderviking]

Ik geloof niet zo in bewust duistere intenties hier.
Er zullen fouten gemaakt zijn, maar ik denk vooral dat er ook gewoon meer geld naar dit soort open source projecten moet.
Misschien vanuit bedrijven die er zo gretig gebruik van maken.

Ik moest bij dit issue terugdenken aan log4j, was ook zo'n baksteentje waar heel het internet stiekem op leunt (inclusief hele dure Enterprise producten) maar wat gewoon onderhouden werd door een individu ergens als hobbyproject.

[Waarnemer]

ja, die was tof. log4j

zijn vast nog een hoop ongepatchte machientjes enzo in omloop

[Yordi-]

Je houdt je hart vast voor het MKB en haar hobbyisten achter de websites en ICT.

Dat de overheid en grote organisatie dit snel op orde hebben lijkt me logisch, maar de komst van AI en ook dit soort lekken zijn voor kleinere bedrijven een enorm risico. Al die beunhazen alleen al in Nederland die het MKB aan ICT helpen… laat staan hoe dat geregeld is in minder ontwikkelde landen.

[Polderviking]

Ik vond die grote Nederlandse hosters anders vrij laat doorkomen met e.e.a. offline te halen.

[n9iels]

Ik vind het verschil hierin erg opvallend. MijnDomein heeft preventief alle websites van hun klanten offline gehaald, terwijl bijv. Yourhosting dat niet heeft gedaan en pas na 16:00 eens de stekker eruit heeft getrokken.

Sowieso lijkt het erop dat wij in NL heel snel waren, wellicht omdat grote websites het goede voorbeeld gaven. Toen de NOS al aan het live-bloggen was stond er op de websites van BBC en CNN nog helemaal niks. Wellicht toch wat Albert Heijn trauma?

[barbarbar]

Het recente gebeuren bij Albert Heijn heeft het in ieder geval acceptabel gemaakt om de boel offline te gooien. Ik had klanten die zelf vroegen de boel maar offline te gooien (maar ze gebruiken helemaal geen php...). Dus dat een groot bedrijf recent die actie heeft gedaan is bij velen wel aangekomen dat offline gaan wel een serieuze optie is.

[BleghBlarg]

Soms is het niet eens dat klanten zelf bang zijn, maar die moeten zelf een inschatting maken of hun klanten daar wel of niet bang voor zijn.
Als de inschatting is dat hun klanten wellicht vragen gaan stellen als ze online blijven dan kan je beter gewoon je website offline gooien, of je nou PHP gebruikt of niet. (Aan sommige doelgroepen is het lastig uit te leggen dat je niet kwetsbaar bent terwijl voor hen het halve internet plat ligt)

Maar ook zeker een domino effect dat je het bijna solidariteit zou noemen. Maar ik kan me voorstellen dat offline gaan makkelijker is dan een uitleg geven.

[barbarbar]

Uit solidariteit het bedrijf/werk van klanten een dag platleggen omdat anderen problemen hebben? Dat lijkt me toch niet. Gewoon even berichtje terug: we gebruiken nergens php, en klaar.

[BleghBlarg]

Daarom ook "bijna solidariteit" het is meer hoe het eruit ziet dan de intentie erachter.

Maar ik kan je 100% zekerheid zeggen (eigen ervaring) dat er partijen zijn die voor het gemak offline zijn gegaan. Denk ook dat je het formaat van een klantenbestand niet moet onderschatten, het antwoord kan simpel zijn, maar 300 keer dezelfde vraag beantwoorden is ook vermoeiend. (mensen lezen hun mail toch maar de helft van de tijd dus een algemeen mailtje is ook niet echt de oplossing)

[E!Ma0RB7]

Mijn host had het goed gedaan, vind ik.

Zij hebben zelf niks offline gehaald, maar gaven aan dat ik zelf die afweging moest maken. En zo hoort het ook denk ik: mijn leverancier moet niet mijn risicoacceptatie invullen.

Op hun website stond sinds vanochtend vroeg een dikke rode banner met een link naar een liveblog waarin alles stond dat je nodig had:

1. Uitleg wat er aan de hand was.
2. Bericht dat je zelf het risico moest afwegen om je site offline te halen.
3. Indien je je site wél offline wilde halen, hadden ze daar een faciliteit voor ingericht, zodat dit snel en gemakkelijk kon (was letterlijk een vinkje aan- of uitvinken).
4. Voorts een tip om je PHP-versie te checken en een duidelijk stappenplan over hoe je die kon upgraden (mijn site werkte op 8.1 (!) > dus gelijk geupgrade ).

Geen heisa, geen paniek, ik had de keuze en zij faciliteerde wat nodig was.

Ik zou ze bijna fooi geven.

[Gemeni]

Alles offline is dan ook wel een paardenmiddel…

Is echt niet altijd nodig. Heb het idee dat dit vooral in Nederland gebeurde door een domino effect. Iedereen werd bang…

[Polderviking]

True. Dat is altijd een afweging van de impact die het heeft en het risico dat je wil lopen natuurlijk.
En alles is altijd een beetje alarmistisch tot het toch terecht bleek... alleen als je te laat bent ben je wel ook gelijk klaar (of gaar).

Ging me er meer om dat je als je alleen maar een paar servertjes te doen hebt in het MKB er sprake kan zijn van amateurisme, maar ook dat je gewoon wel weet wat je doet en veel sneller kan reageren.

[Reactie gewijzigd door Polderviking op 21 oktober 2026 19:38]

[n9iels]

Ik denk dat we later pas gaan horen of dit overdreven was of niet. Persoonlijk denk ik dat het hoe dan ook goed is geweest. Het is een opfrisser dat security issues serieus genomen moeten worden en dat voorkomen beter is dan genezen. Noem het een Albert Heijn effect of een paardenmiddel, ik denk niet dat dit een maand terug met zo veel aandacht in media was gekomen. Wat mij betreft hoe dan ook een win.

[snollygoster]

Het Albert heijn effect.

[svennd]

Tenzij je een webshop bent is de website even offline halen ook echt wel een simpele solution. Een dubbele RCE zonder patch is wellicht de reputational damage wel waard.

[Llopigat]

Hmm als hobbyist heb je een update zo gedaan.

In een groot bedrijf is dat een stuk lastiger omdat er eerst hele comite's overheen moeten pissen.

[n9iels]

Mwah, bij security issues die op de frontpage van de NOS gaan is dit vaak een stuk makkelijker hoor. Ook niet technisch onderlegde mensen snappen dan dat het serieus is. En zo niet.... tja dan maar hopen op een CTO die zijn vuist op tafel durft te slaan en het oké vindt om achteraf uitleg te geven.

[Llopigat]

Makkelijker ja. Maar alsnog zijn er policies en processen en die moet je naleven vanwege ISO gedoe. En dat hangt weer samen met je cybersecurityverzekering, die dwingen ook veel procesmatig gedoe af. Dan moet je 30 man bij elkaar krijgen, zijn mensen vaak weer op vakantie zonder goede delegatie, iedereen moet er weer over overleggen, blablabla. Bij ons was het ook weer drama vandaag al was ik er zelf niet bij betrokken, maar ik heb er wel over gehoord.

Als MKB/Hobbyist druk je gewoon op update en klaar. Als iemand die in beide omgevingen actief is (ik beheer ook dingen voor onze makerspace) is het contrast enorm en het geeft je echt een enorm voordeel met dit soort dingen.

Bij ons op het werk hebben we voor elke techneut 6 man die proces, lifecycle, governance, compliance enz onzin doen. Dat zijn allemaal CYA (Cover Your Ass) types die geen stap zetten als het niet ergens in een flowchart staat. Die mensen hebben ook helemaal geen verstand van zaken. Het zijn bijna juristen. Het maakt het onmogelijk om snel te reageren.

En dit is iets van de laatste 5 jaar ongeveer. Zo tijdens Corona is het allemaal opgezet, voor die tijd konden we nog gewoon snel schakelen als dat nodig was. Er was wel eens een audit ofzo maar dat werd redelijk makkelijk afgedaan.

[Reactie gewijzigd door Llopigat op 21 oktober 2026 19:51]

[hackerhater]

Well mijn klant was vandaag het overleggen en ruim voor de patch tijd kwam het besluit dat alles plat ging.
En geen enkele site gaat weer online zonder het OK van IT

[E!Ma0RB7]

Open deur: de truc is om vooraf alle comités een noodprotocol te laten goedkeuren voor als je het nodig hebt. In geval van nood hoef je niet op hun plasje te wachten.

Vorige maand had ons bedrijf (niet klein met >> 2.000 medewerkers) bij de Citrix Netscaler kwetsbaarheden de protocollen klaarliggen. Binnen een kwartier lag 'de stekker eruit' en werd management (dat toch wel héél erg 'nieuwsgierig' was) conform protocol achteraf (maar wel erg vlot) geïnformeerd. Geconfronteerd met het eigen protocol was de reactie: "Oh, nou. Goed gedaan, mensen!"

Er valt altijd wat te zeuren over hoe het op de zaak gaat, maar dit werkt(e) goed bij ons.

[Llopigat]

Mja maar dan heb je weer de vraag: Wat is een noodsituatie.

We hebben wel een versnelde procedure hiervoor maar dat was deze al

De normale procedure duurt namelijk weken. Nou is het wel een bedrijf met > 100.000 werknemers. Maar dat is precies mijn punt. Hoe groter is helemaal niet hoe kwetsbaarder. Grote bedrijven hebben veel meer complexiteit.

[Reactie gewijzigd door Llopigat op 21 oktober 2026 21:00]

[armageddon_2k1]

Dat is echt heel naief om te denken dat overheid en grote hosters snel bij zijn

[frackleboom]

Zoals hier te lezen is, heeft Chainguard-CEO Dan Lorenc zelf besloten de builds eerder openbaar beschikbaar te maken.

[DennusB]

Bizar slechte keus. Kan ze nog wel eens serieuze imago schade opleveren

[frackleboom]

Ik hoop dat ze voortaan geen early access meer krijgen. Dit is absurd en extreem riskant, zeker nu LLM’s patchdiffing zo makkelijk maken.

[Llopigat]

Aan de andere kant waren de exploits al vol aan het rondvliegen op internet. En dat was niet zijn schuld maar die van de ontdekkers met hun video.

Op welk punt geef je dan de voorrang aan je klanten? Ik zou die keuze ook niet gemaakt hebben, maar aan de andere kant kan ik het me wel voorstellen. De fuck up was op dat moment al compleet. Vergeet niet dat met een log van die exploits in de hand andere actoren ook gewoon een exploit konden ontwikkelen. De informatie werd al vrijelijk op internet verspreid juist door die aanvallen.

[Reactie gewijzigd door Llopigat op 21 oktober 2026 19:36]

[svennd]

De vulnerability was al gekend sinds 21 september, het risico wordt steeds groter, en hoe dichter bij de deadline hoe moeilijker, het geheim te houden is, maar daar sta je als cybersecurity bedrijf boven. Overigens waren er maatregelen te nemen die de impact konden verkleinen (selinux/apparmor, nginx/apache filter,...) Als je early released hoor je niet in de pre-phase te zitten. Op hackernews is zelfs al te horen dat de sales direct aan de slag is gegaan om bij de competitie klanten te gaan pikken.

Etical hacking right ?

[cane]

Ik heb berichten gezien dat de patch niet geholpen heeft en of dat er mogelijk meerdere bugs gevonden zijn. Zou niet raar zijn nadat er zoveel ogen op PHP op dit moment zijn en in de code en met AI dat er nu juist meer bugs gevonden worden.

[n9iels]

Wees voorzichtig bij het lezen van dat soort berichten en onthoud dat het eerste bericht eigenlijk altijd fout is, of op zijn best incompleet. Na zo'n patch probeert elke security onderzoeker wanhopig meer lekken te vinden en (allicht onbewust) elke gevonden hick-up te publiceren.

[barto7]

Kan je hier meer over vertellen?

[dutchgio]

Dat is overigens niet alleen met PHP. Microsoft heeft ook vrijwel elke maand een nieuw record met Patch Tuesday mede door AI.

[hbokh]

Het lijkt nog niet gedaan…

Op Mastodon meldt een gebruiker dat de exploit / PoC nog steeds werkt in PHP 8.5.12:

https://fedi.katze.sh/@elise/117479383739450605

[Ninaomi]

Het lijkt erop dat het een aparte geheugenbug is, die nog niet is opgelost, waardoor een specifieke PHP-functie wordt geactiveerd wanneer een script deze op een bepaalde manier aanroept. Deze functie blijkt niet bereikbaar te zijn via een eenvoudig webverzoek.

[R.G]

Is mastodon een self hosted Twitter?

Is zij een Berlijnse hacker? Hoe vond je dit?

Interessant

[Abbu-kun]

offtoppic i.g. maar Mastodon is een ActivityPub instance en kan met Mastodon instances maar ook andere programmas netwerken. Sommige Mastodon instances zijn heel groot en andere zijn eenpersoons. Sommige ActivityPub software is ook in PHP geschreven dus vandaar dat het er lekker veel wordt besproken.

[Polderviking]

Geen reacties van betrokken bedrijven nog? Vooral wel benieuwd naar die van Chainguard...

[jordynegen11]

Het lijkt erop dat er nog meer gaat komen…
Ben benieuwd of dit echt is.

https://fedi.katze.sh/@elise/117479383739450605

[Reactie gewijzigd door jordynegen11 op 21 oktober 2026 19:58]

[Nimja]

Dat bericht is van:

Oct 21, 2026, 04:32 PM

En tot zover (nu, 3 uur later) heb ik geen bevestigingen gezien voor/tegen die bevinding.

Ik heb wel ditzelfde screenshot herhaald zien worden op X.

[satya]

Kan het zijn dat ze het lokaal op de omgeving zelf uitvoert?

[HostMan]

Voor mensen die op hun hostingprovider wachten: de meeste goede Nederlandse hostingproviders gebruiken CloudLinux. CloudLinux heeft nog niet voor iedere PHP versie een patch gereleased, je kunt de status hier volgen: https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5
Het mooie is wel dat CloudLinux direct met backports voor PHP versies t/m 5.2 komt.

Hier kan je hostingprovider niets aan doen.
Gebruikt je hostingprovider CloudLinux en werkt alles zoals normaal? Dan loop je momenteel mogelijk nog risico, de kans is groot dat er voor jouw PHP versie nog geen patch is uitgebracht door CloudLinux. Haal dan zelf je website of app offline, tot CloudLinux haar alt-PHP versies heeft gepubliceerd.

[WhatsappHack]

Het gekke is dat cPanel heeft aangekondigd te backporten naar 7.4 en 8.1 en dat ook al gedaan heeft om 16:00, maar op oude servers ook updates gepusht lijkt te hebben voor nog oudere versies inclusief PHP 5.4. Klinkt haast alsof ze de binaries van CL of TuxCare gepusht hebben, wat dan extra vreemd maakt dat CL ze zelf dan niet pusht.

[CPM]

Ben benieuwd wanneer Synology met een update komt. Genoeg mensen die WebStation en php draaien en geen idee hebben dat ze dat doen.