Ontdekker PHP-kwetsbaarheden lekte per ongeluk zelf vroegtijdig details uit

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

Dit nieuws in het kort

• Een van de ontdekkers van de PHP-kwetsbaarheden publiceerde zelf te vroeg informatie hierover.
• Een ander bedrijf brak vervolgens het embargo door te vroeg een patch te publiceren.
• De vroegtijdige publicatie van informatie over de PHP-kwetsbaarheden zorgde voor grote chaos op het internet.
• Veel websites moesten noodgedwongen offline, omdat informatie al openbaar werd voordat een oplossing was gepubliceerd.

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 (70)

[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]

[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]

[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.

[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.

[Gemeni]

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

[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]

[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).

[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.

[Nark0tiX]

Jaa want na halfuurtje rommelen met deepseek had ik de exploit succesvol getest. Vind het ook geen extreem complexe exploit. Blijft bizar dat dit al zeven jaar genegeerd werd. Zolang actief misbruikt. Hopen dat men nu wakker wordt

[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

[R.G]

Dit dus

[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.

[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]

[snollygoster]

Het Albert heijn effect.

[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.

[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]

[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]

[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.

[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.

[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

[Gemeni]

Als ik het goed begrijp is het normaal dat cybersecurity bedrijven zulke updates eerder krijgen.

Laten veel hackers nu net bij cybersecurity bedrijven werken…

[n9iels]

Een veel pyromanen werken bij de brandweer? Corrigeer mij zeker als ik het fout heb, maar volgens mij is er geen enkel bewijs dat hackers vaak overdag bij een cybersecurity bedrijf werken en in de avond random websites hacken.

[Gemeni]

Pepijn S is een voorbeeld en op basis van zijn arrestatie zijn ook mensen verdacht die bij andere beveiligingsbedrijven werken.

Denk dat er meer voorbeelden zijn te vinden…