Securityexperts vinden derde bug in PHP en claimen dat patch incompleet is

Beveiligingsexperts leggen PHP onder het vergrootglas en claimen nieuwe beveiligingsproblemen met de veelgebruikte scriptingtaal. Een van de kwetsbaarheden zou met de woensdag vervroegd uitgebrachte patch niet volledig zijn gefixt. Verder is er een derde bug gevonden, maar die is volgens PHP niet kritiek.

De securitysituatie rond PHP lijkt nog niet voorbij, nadat er woensdagmiddag patches vervroegd uitkwamen. Verschillende beveiligingsexperts analyseren de patches en de twee kritieke kwetsbaarheden. Daarbij claimt de Zwitserse beveiligingsonderzoeker Nicolas Krassas dat PHP-versie 8.5.12 incompleet is. Die woensdag uitgekomen release fixt volgens hem wel aanvalsroutes voor de twee kritieke gaten, maar zou drie andere methodes voor misbruik openlaten.

'Niet gecoördineerd'

Krassas stelt dat meer validatie van de patch nodig is. Hij heeft zijn bevinding online gepubliceerd en claimt werkende proof-of-conceptcode te hebben voor zijn vondst. Hij meldt daarbij dat hij zijn publicatie niet heeft afgestemd met het beveiligingsteam van PHP. De onderzoeker legt uit dat het beleid van PHP sinds 2017 is om geen CVE-beveiligingsscores toe te kennen aan bepaalde geheugencorruptiebugs. Op sites als Reddit en LinkedIn lopen nu discussies over de validiteit van Krassas' claim.

Ook de vondst van de Duitse beveiligingsonderzoeker Elise Amber Katze leidt nu tot twijfel en kritische analyse. Zij heeft een derde bug in PHP-code gevonden en die verantwoord gemeld bij het PHP-ontwikkelteam. Haar proof-of-conceptcode zou ook werken op de nieuwste 8.5.12-release van de scriptingtaal. PHP draait op 69,3 procent van alle websites wereldwijd.

Wel gecoördineerd, maar 'niet urgent'

Haar vondst is volgens PHP-kernontwikkelaar Ilija Tovilo een andere geheugenbug, die 'op geen enkele manier urgent is'. Terwijl Katze stelt dat haar bug relatief simpel is, zou misbruik ervan lastiger zijn dan van de twee kritieke kwetsbaarheden waarover woensdag grote zorgen ontstonden.

PHP-gaten. Bron: Tweakers

Reacties (148)

[ETH0.1]

Het is wel erg makkelijk om PHP nu zo hard af te rekenen. Natuurlijk is het goed dat onderzoekers de code scherp houden, maar de nuance ontbreekt volledig. Bij Microsoft accepteren we als 'business as usual' dat er vorige week zo'n 1600 patches werden uitgebracht, en komende maand waarschijnlijk weer een vergelijkbaar aantal.

Het voelt als een dubbele standaard: bij grote techgiganten horen gigantische patchrondes er nu eenmaal bij, maar zodra het open-source PHP-team snel en transparant reageert, wordt elke microscopische geheugenbug meteen onder een vergrootglas gelegd. Dat doet weinig recht aan het werk van de community die een groot deel van het internet draaiende houdt.

[jvwou123]

Verschil is wel dat die 1600 patches niet direct vanaf het internet te misbruiken zijn.

Php draait op servers die bedoeld zijn om voor iedereen te benaderen is. Windows is niet daarvoor bedoeld.

edit:
omdat er veel reageert wordt en ik niet iedereen het zelfde antwoord wil geven.

Ik typte dit snel even vanaf mijn telefoon, dus nuance ontbreekt. Die 1600 bug zijn niet wereldwijd, direct te misbruiken. Die php bugs (ook al zijn het er maar 2) is bij 70% van de websites wereldwijd te misbruiken, waardoor een aanvaller direct zonder enige vorm van authenticatie/autorisatie/firewall de bug kon misbruiken.

Dat Gerda op haar Windows laptop door die 1600 bug ook kwetsbaar is als ze op Facebook het verkeerde plaatje aanklik is echt wel van een totaal andere orde dan 70% van de websites die zonder interactie van de beheerder volledig over te nemen zijn.

Ik ben wel benieuwd, hoeveel beheerders hangen een Windows Server aan het internet, met IIS? Dan zou ik met 1000+ bug fixes per maand idd niet rustig meer slapen...

[Reactie gewijzigd door jvwou123 op 22 oktober 2026 10:49]

[Bongoan]

Misschien wordt het dan ook tijd dat bedrijven die hier gebruik van maken voor betalen (met inspanning om de code te verbeteren of financien om dit te bewerkstelligen).

[YGDRASSIL]

Lijkt me prima. Alleen is het open source. Waar gaat het geld heen, wie geeft het uit?

[Ghoelian]

In het geval van PHP is er een PHP Foundation die donaties ontvangt, en veel andere grote projecten hebben ook zoiets. Sommige hebben ook een optie om te doneren via Github.

[nl noob]

Er is een veelvoorkomend misverstand dat opensource software ook alleen door "vrijwilligers" wordt onderhouden. opensource zegt alleen iets over de licentie van de software, niet over hoe de ontwikkelaars worden betaald. Het betekend dat de broncode openbaar beschikbaar is en mag worden gebruikt, bestudeerd, aangepast en verspreid. Dat betekent niet dat iedereen die eraan werkt een vrijwilliger is. Veel bedrijven verdienen indirect geld aan open source projecten en hebben er daarom belang bij dat deze goed worden onderhouden.
Geld dat via sponsoring, donaties of bedrijfsondersteuning binnenkomt, wordt daarnaast vaak gebruikt voor beveiligingsproblemen en voor de infrastructuur. Veel devs vinden documentatie niet leuk, dus ook daar wordt vaak voor betaalt. Wie het uitgeeft verschilt per project. Bij kleinere projecten zijn dat vaak de maintainers, terwijl grotere projecten een stichting of governance-organisatie hebben waar dit (met vergoeding) wordt bepaald.

[101Garfield]

Al is het maar dat grote bedrijven tijd investeren in het reviewen van de code en verbeteringen aandragen.

Bedenk wel dat grote bedrijven wel geld verdienen aan de opensource software en daar ook iets tegenover moeten stellen.

[YGDRASSIL]

Waarom moeten ze dat? Staat volgens mij nergens. Jij vindt dat blijkbaar fair.

[Roberto4646]

"Staat volgens mij nergens"

Jij geeft ook geen hand als je binnenkomt en je voorstelt bij je eerste sollicitatiegesprek? Staat ook nergens inderdaad, helemaal gelijk!

[Reactie gewijzigd door Roberto4646 op 22 oktober 2026 23:00]

[YGDRASSIL]

Bij opensource heb je een licentieverhaal. Daar staat vaak in wat je mag en moet. Geld betalen staat daar vrijwel nooit in volgens mij. Zou ik heel normaal vinden als dat wel zo was. Maar als je dan iets gratis weggeeft moet je niet raar opkijken als je er geen geld voor krijgt.

[Roberto4646]

Het is vaak gratis voor de particuliere gebruiker. Zakelijk ligt dat compleet anders.
Maar zoals al gezegd was, het ligt niet vast. We geven geen hand...

[YGDRASSIL]

Hoezo ligt dat zakelijk anders? Op mijn werk gebruiken we diverse opensource libraries. Geen enkele heeft een licentie die zegt dat er betaald moet worden. In ons geval helpen we soms mee door issues te melden of op te lossen en een pull requests te doen. Maar dit zijn kleine projectjes met vaak 1 maker en wat contributors zonder stichtingen en zo. Wil je best een hand geven, waar het me om gaat is dat meebetalen gewoon niet of nauwelijks geregeld is/de norm is voor de meeste open source.

[Roberto4646]

Jaja jaja daar gaan we het weer over gevoel en die hand hebben.

Bedrijven als Microsoft, Google, Airbus betalen heel vaak mee aan open source projecten. Kleinere bedrijven doneren ook vaak.

Omdat zij er namelijk (heel veel) geld mee verdienen. Dus zakelijk ligt dat zeker anders. Maar dat kun je meer zien als een 'gentleman agreement".

Zo is het heel netjes als jou bedrijf veel geld verdiend met het "gebruik" van open source projecten, dat zij wel doneren aan die projecten.

Maar is het gevoel en die hand he...

[ApexAlpha]

Dat weet jij helemaal niet? Als er een patch voor MS IIS is of de IPv6 stack van Windows dan is dat wel degelijk vanaf het internet een probleem.

Wannacry vergeten? Was ook Windows... Hele dag paniek...

review: Wat maakt WannaCry anders dan andere ransomware?

Php draait op servers die bedoeld zijn om voor iedereen te benaderen is. Windows is niet daarvoor bedoeld.

Grapjas er is een hele divisie van Windows genaamd "Windows Server". Wat denk je dat die doen?

[Reactie gewijzigd door ApexAlpha op 22 oktober 2026 08:30]

[JacOwns7]

Alleen als said servers internet facing zijn natuurlijk.

Ik ken maar bar weinig Windows IIS servers die PHP based sites hosten. Het grootte gros is ASP.net wat natuurlijk een logische keuze is. Het was met name imbeded PHP wat we hier gisteren tegenkwamen op 1400+ host, zoals HP device manager. Scheelde weer een bak urgentie.

[Reactie gewijzigd door JacOwns7 op 22 oktober 2026 08:43]

[ApexAlpha]

Wannacry ging niet over servers.

[JacOwns7]

Leuke aan Wannacry was wel dat het niet gepatched systemen troef. De patch (Maart 2017) was toen al uit.

Vind het niet een hele sterke voor vergelijking met een echte RCE. De initiele infectie in een omgeving moest nog steeds plaatsvinden door traditionele malware infectie, door bijv een schunnige bijlage in een mail.

[ApexAlpha]

Het is 100% een RCE.

Je moet alleen bij de SMB poort komen, maar genoeg bedrijven hadden die dus (ergens) wel open staan, gezien de impact.

[JacOwns7]

Gezien de usecase van SMB, was het wel logisch die poort intern open te hebben. Wannacry kon zijn ding niet doen als er gepatched was, of als niemand in een netwerk de malware initieel geopend had. Het moest ergens starten voordat het z'n gang kon gaan.

bij het PHP verhaal was het net even iets anders. Vandaar de voorzorgen gisteren dat sites op zwart gingen.

Uiteindelijk was het een RCE inderdaad als het begin gemaakt was.

[Reactie gewijzigd door JacOwns7 op 22 oktober 2026 10:57]

[Glashelder]

ASP.net wordt in het leeuwendeel tegenwoordig ook gewoon vanaf (een) Linux (container) geserveerd.

[JacOwns7]

Dat kan kloppen. Ik doelde meer specifiek op de rol die IIS vaak vervult op een Windows server.

[kozue]

Het ging niet perse om PHP op een Windows server. Het ging om exploits in Windows die vanaf het internet misbruikbaar zijn. Daar valt ASP.net net zo goed onder, of bugs in de IP stack, of wat dan ook.
Nou zullen de meeste Windows servers wel achter een reverse proxy zitten, maar een bug in je webapplicatie en het is klaar. Maakt niet uit in welke taal die geschreven is, overal kunnen fouten in zitten. Nu is het PHP, morgen is het wellicht .NET.

[JacOwns7]

Wannacry dat aangehaald werd, moest ten eerste altijd nog via klassieke malware infectie plaatsvinden bij iemand in een netwerk. Daarnaa kon het middels een kwetsbaarheid in SMBv1 doorhoppen naar andere targets in dat netwerk.

Als ASP.net een vergelijkbare RCE heeft zoals PHP die had, is die natuurlijk wel via het net te misbruiken. Die zijn direct internet facing.

[WoutervOorschot]

Die bugs zaten sws ook (deels) in windows server, welke wel bedoelt is om door iedereen te kunnen benaderen (als het voor websites wordt gebruikt dan).

[Mimiix]

Niet helemaal waar. De bugs moeten dan zitten in het deel van het OS dat publiek bereikbaar is.

[WoutervOorschot]

De bug kan ook zijn dat je code kunt uitvoeren vanuit serverside.

Maar inderdaad, de entry zal eerder via iis zijn dan windows zelf. Zoals deze php bug ook op windows kwaad kan als je php op je windows server hebt draaien.

[useruser]

De bug kan ook zijn dat je code kunt uitvoeren vanuit serverside.

Microsoft beschouwt het niet als security kwetsbaarheid als er interactie van een gebruiker nodig is. Zo heb ik ooit een kwetsbaarheid ontdekt en via hun bugbounty programma aangemeld, met een vrij eenvoudige bestandsnaam kon je explorer laten crashen en een deel van het ntfs filesystem onbruikbaar maken. Keurig gemeld, krijg ik als reactie terug dat het geen kwetsbaarheid is en geen bounty krijg omdat er een actie vanaf de gebruiker nodig is. Daar kun je over discussieren (open bijvoorbeeld een zipje met dit bestand, of stuur het als upload naar een webserver o.i.d.).

Eerst volgende patch tuesday was het wel gewoon gefixed. Sindsdien kunnen ze de tering krijgen, eerst volgende keer dat ik zoiets ontdek gaat het direct reddit op.

[Sfynx]

Volgens die logica is het kunnen compromitteren van een systeem via een geprepareerde afbeelding, wat we ook weleens zien langskomen, ook geen kwetsbaarheid. Je moet immers zelf de afbeelding openen. Een actie van een gebruiker die wordt verondersteld veilig te zijn maar dat niet is door een bug lijkt me gewoon een kwetsbaarheid.

Maar mooi dat je de bevestiging hebt dat hier responsible disclosure dus niet nodig is, want immers geen kwetsbaarheid

[Dryw.Filtiarn]

Tegelijkertijd zijn er voorbeelden geweest van de windows explorer previews die dergelijke exploits in afbeeldingen al konden triggeren; waarmee interactie door de gebruiker al een discutabele kwestie is geworden.

[YGDRASSIL]

Alleen deze keer geen 'op afstand eenvoudig je hele server overnemen' bugs in de windows server. En wel in PHP

[Scriptkid]

volgensmij heb je toch echt ook windows web services met PHP IIS of zoiets

[Sanghelios]

Natuurlijk wel. Hoeveel bedrijven draaien Windows via servers denk je?

[imqqmi]

Ooit van IIS gehoord met ASP? Er zijn wel degelijk Windows machines gebruikt als webservers en daar zullen ook kritieke bugs in zitten. Wordt niet meer veel gebruikt vermoed ik maar om te beweren dat Windows niet is bedoeld voor server toepassingen (je hebt ook Windows Server editie) is natuurlijk onzin.

[CH4OS]

Ik typte dit snel even vanaf mijn telefoon, dus nuance ontbreekt. Die 1600 bug zijn niet wereldwijd, direct te misbruiken. Die php bugs (ook al zijn het er maar 2) is bij 70% van de websites wereldwijd te misbruiken, waardoor een aanvaller direct zonder enige vorm van authenticatie/autorisatie/firewall de bug kon misbruiken.

Ook dit verdient nuance. PHP kan je op diverse manieren draaien, het is ook niet (en ook niet per se) direct te benaderen. Je kunt PHP als je dat zou willen laten uitvoeren op een dedicated machine middels een socket. Neemt niet weg dat de bug dan nog steeds te misbruiken is als je de gepatchte versie niet geinstalleerd hebt, maar mijn punt is vooral dat PHP ook indirect dus kan draaien.

[SubSpace]

Ik kan me eigenlijk zo snel geen al te schokkende IIS bugs herinneren. Over verschillende banen en opdrachten heen heb ik toch zeer regelmatig met IIS gewerkt.

[Splashy]

PHP is veruit de populairse taal op het web, en hoge bomen vangen veel wind. Waarschijnlijk had iedere taal met 70% marktaandeel onder een vergrootglas gelegen in deze situatie. Een lek in C# heeft lang niet zoveel impact omdat het marktaandeel op het web veel kleiner is.

[Macshack]

Uhm, het gaat natuurlijk niet alleen om marktaandeel. Maar ook wat er financieel te halen valt. Bij veel PHP websites valt er weinig te halen.

[Tsjilp]

Het gaat niet alleen wat die site aanbiedt he, als je de server kan overnemen kun je ook malware gaan serveren bijvoorbeeld.

En je wil niet weten hoeveel webshops op php (magento e.d.) draaien, dus denk dat er genoeg te halen is.

[Splashy]

Het zal je verbazen hoeveel enterprise projecten op PHP draaien, zowel in het bedrijfsleven als bij de overheid. PHP is meer dan Wordpress.

[kodak]

Het is niet voor het eerst dat mensen pas ergens problemen mee hebben na een confronterend probleem. Kritiek op PHP hebben is waarschijnlijk makkelijker dan tonen welke moeite men zelf heeft gedaan om de problemen te voorkomen. De meeste waarschijnlijk niets bijzonders. PHP is afhankelijk van vrijwilligers en donaties. Hoeveel van deze klagers heeft er ooit aan bijgedragen maar wil er wel de voordelen van? Bijvoorbeeld om zelf in het nieuws te komen?

[Reactie gewijzigd door kodak op 22 oktober 2026 08:23]

[The Zep Man]

Het voelt als een dubbele standaard: bij grote techgiganten horen gigantische patchrondes er nu eenmaal bij, maar zodra het open-source PHP-team snel en transparant reageert, wordt elke microscopische geheugenbug meteen onder een vergrootglas gelegd. Dat doet weinig recht aan het werk van de community die een groot deel van het internet draaiende houdt.

Het is een dubbele standaard. Opensource maakt diepgaande analyse mogelijk en makkelijk, zonder de kans dat er een leger advocaten in de nek hijgt. Verder is het aanvalsoppervlak van PHP over de linie heen een stuk groter dan menig Windowssysteem (iets als IIS uitgezonderd). Als er een kritieke kwetsbaarheid in Windows zit dan kijkt men naar externe beveiligingslagen om de kans op misbruik te beperken. Als er een kritieke kwetsbaarheid in PHP zit, dan kunnen veel publieke sites niets anders doen dan een risicoanalyse maken en desnoods sites offline halen, wat men gisteren veelal deed.

Ik ben het met je eens dat de discussie oneerlijk is. Wel toont gisteren ook aan dat veel sites onnodig steunen op dynamische uitvoer aan de kant van de server voor zaken die dat niet (altijd) nodig hebben. Daar zou naar mijn mening de discussie over moeten gaan, want er is veel ruimte voor verbetering. Men moet niet zoveel vertrouwen hebben in een enkele beveiligingslaag, opensource of anders.

Denk aan de website van het NCSC en hun Belgische equivalent, die gisteren offline gingen. De meeste mensen komen naar die sites ten eerste om informatie op te halen. Dat kan ook prima via dynamisch gegenereerde en statisch aangeboden pagina's. Dan is het bij een crisis maar jammer dat de interne zoekmachine niet werkt (die men kan omleiden naar een externe) en dat men even geen meldingen via de reguliere weg kan doen. Ook waren er bijvoorbeeld sites die hun webmail offline haalden, terwijl je iets als webmail ook achter een WAF en (hardened) inlogportaal kan plaatsen.

Het gaat niet alleen om PHP, maar om elke interpreter gebruikt om dynamische webcontent aan te bieden. Ieder verzoek dynamisch verwerken is onhandig en vaak onnodig voor publieke sites die zich openstellen naar het volledige internet.

[Reactie gewijzigd door The Zep Man op 22 oktober 2026 08:57]

[Sissors]

De nuance ontbreekt? Heel Tweakers en vele andere websites zijn gisteren offline gegaan vanwege microscopische geheugen bugs? Deze bugs hebben gewoon een enorme impact gehad, dat heeft helemaal niks met opensource of niet te maken. Als er morgen een bug zit in Windows waardoor wereldwijd systeembeheerders bij bedrijven zeggen: "Nou vandaag blijven alle laptop en PCs uit tot de bug gepatcht is", dan gaat dat ook heel hoog in het nieuws komen, en dan verwacht ik ook geen reacties van: "Maar als Ubuntu een patch ronde heeft met 200 bugs zegt ook niemand er wat van!".

De impact van deze bugs is gewoon heel erg groot geweest, dus dan is het logisch dat het groot in het nieuws komt, en ook logisch dat vervolg problemen ook een nieuws item zijn.

[watercoolertje]

Ik zie het veel in het nieuws maar 'afrekenen' ben ik nog niet tegen gekomen. Gewoon geconstateerd en gemeld imo in die nieuwsberichten. Lijkt me niks mis mee eigenlijk.

[Reactie gewijzigd door watercoolertje op 22 oktober 2026 08:51]

[Dosio]

Waarom is dat erg makkelijk? PHP heeft dit zelf veroorzaakt. Ze hebben ook nog eens onnodig tijd lopen verspillen, doordat daar altijd unanieme besluiten nodig zijn en ze het onderling niet eens werden over de patch. Dat hebben ze inmiddels aangepast naar een meerderheid van stemmen.


Het komt vooral zo amateurisch over, voor iets waarvoor de meerderheid van alle websites van afhankelijk zijn. Hopelijk leren ze hiervan.

[Ashketchum22]

Het feit dat Microsoft 3 maanden achtereen op Patch Tuesday met "1100" patches per keer aan komt, geeft mij meer kriebels de andere kant op...
Okee... dus hoe lek is windows dan echt, als je dit 3x achter elkaar uitbrengt?
Ze brengen het als "Goed nieuws" maar onderwater geef je dus eigenlijk toe dat je een gatenkaas verkoopt....

[Moortn]

Niet elke bug is een beveiligingslek en niet elk beveiligingslek laat aanvallers eigen code uitvoeren.

[JacOwns7]

Net zo lek als ieder ander stuk software. 3x 1100 patches vind ik persoonlijk hard meevallen op een complex iets als Windows met miljoenen lijnen code.

Daarvan is het gros natuurlijk geen RCE.

[Kallik]

...even lek als macOS die vorige maand ook meer dan 1000 problemen moest oplossen met een patch. En Linux zal waarschijnlijk niet ver daarvan af zitten.

[pe0mot]

Inderdaad. Ik schrok toen ik gisteren mijn wekelijkse “brew update” draaide op Mac.

Idem “apt-get update” op Ubuntu onder wsl Windows.

[Reactie gewijzigd door pe0mot op 22 oktober 2026 10:28]

[Barsonax]

Beter dus als ze die niet zouden oplossen dus? Alsof andere software zoveel robuuster is, die zijn wellicht ook lek maar je weet het nog niet.

[GigaHenk]

Bugs zullen er altijd blijven.

Het grootste issue van het internet is dat communicatie praktisch gratis is.

Men zou een systeem moeten opzetten met bijvoorbeeld crypto payment dat contact niet gratis is, tenzij het gewenst was. Dus je betaald €1,- om te connecten, en als het legitiem contact was, wordt het weer vrijgegeven. Dan wordt het erg duur voor hackers om brute force ergens naar binnen te gaan. Of overal maar inbraakpogingen/scans doet. Met lightning zou dat kunnen

[HuisRocker]

Het grootste issue van het internet is dat communicatie praktisch gratis is.

Als je enige gereedschap een hamer is, ziet alles eruit als een spijker...

[GigaHenk]

Ik bedoel natuurlijk in de zin van security en spam.

[RobertMe]

Er is nu natuurlijk ook veel aandacht op gevestigd. Gisteren is iedereen naar de lekken gaan zoeken. Elk beetje dat nu dus niet door de patch is opgelost wordt dus weer opnieuw gemeld.

Hetzelfde zagen we begin dit jaar met de Linux kernel. Waar een security release kwam voor 1 of 2 CVEs. Maar binnen een week er nog een derde issue gevonden was in dezelfde regionen van dd code en er weer een security release kwam.

Dat het nu een paar dagen onstuimig is ligt eigenlijk dus in de lijn der verwachting. Aangezien iedereen die relevant wil zijn op security gebied (/"als hacker") nu zijn ogen heeft gericht op hetzelfde stuk code. En nu roepen dat je een issue gevonden hebt ook meteen er voor zorgt dat jouw naam rond gaat op het hele Internet. Of het issue nu echt bestaat of niet. Dd publiciteit heb je al te pakken.

[Ik_ben_Timo]

Dankjewel

[InjecTioN]

PHP ligt onder een vergrootglas omdat de kwetsbaarheid verholpen moet worden.

Stel je voor:

Kwaadwillenden hebben PHP altijd al onder een vergrootglas liggen, waardoor lekken in PHP niet doorgespeeld worden aan de community van PHP ontwikkelaars, zodat kwaadwillenden er misbruik van kunnen blijven maken. Je merkt het ook dat al dat die kwaadwillende personen er als de de kippen bij zijn om hun slag te kunnen slaan. Want de logs worden vervolgens (voornamelijk bij grote websites) duidelijk aangevuld met de aanvalsmethode voor php2shell.

Kortom: ik ben erg blij dat deze beveiligingsexperts de patch stevig aan de tand voelen. Een patch is zo sterk als de zwakste schakel. Of andersom: een kwetsbaarheid is zo fragiel als de zwakste schakel.

Hoe dan ook begrijp ik je sentiment omtrent dat zoiets niet eerlijk is. Maar aan dat sentiment hebben die kwaadwillenden helaas niets. ¯\_(ツ)_/¯

[albatross]

De nuance ontbreekt volledig? Wellicht bij jezelf, want de nuance zit em in het feit dat een groot bedrijf als MS scherp gehouden wordt door duizenden professionele klanten, terwijl dat bij Open-Source niet zo vanzelfsprekend is. Daar moeten nerds, hobby-isten, en tweakers, zelf aan de bel trekken!

En je vergeet de belangrijkste nuance: dat PHP dus inderdaad Open-Source is, en dus iedereen mee kan kijken.. en dat dus ook doet. Of heb jij de source code van Windows? Ik dus ook niet.

[SED]

Over dat "snel en transparant" reageren is het zinvol om je even in te lezen. De behoorlijk verstoorde discussie over deze kwetsbaarheden loopt kennelijk al sinds 2024 zonder dat men tot een aanvaarde oplossing kwam.

[Madelijn]

Ja, Microsoft..

Tenslotte was het Bill Gates die persoonlijk het correct bewijzen van programmatuur de nek omdraaide met een toespraak waarin hij het belachelijk maakte, en vervolgens met een valse verwijzing naar het stopprobleem beweerde dat het theoretisch onmogelijk was. Allemaal alleen omdat hij het zelf niet snapte, en blijkbaar ook niet wilde leren.

Al die lekken en patches zijn een direct gevolg van die toespraak toen. Weinberg's law.

Ik meende dat OPA een veel betere taal was om veilige websites in te bouwen - maar zie nu net dat hun eigen website geen https accepteert! Fantastische reclame, dus..

[Reactie gewijzigd door Madelijn op 22 oktober 2026 13:51]

[Salvatore.NL]

Ze hebben zelf het boetekleed aangetrokken?!

De stichting, die grotendeels draait op vrijwilligers en donaties van derden, meldt dat in 2024 al het vermoeden bestond dat een bepaalde kwetsbaarheid kon worden misbruikt. Maar het werk aan een fix liep telkens vast door een gebrek aan overeenstemming binnen het beveiligingsteam van PHP over de juiste oplossing en een relatief klein team van ontwikkelaars met de benodigde kennis.

‘We draaien er niet omheen: die vertraging was een structureel falen, veroorzaakt door het besluitvormingsproces van het beveiligingsteam en een gebrek aan middelen’, schrijft de PHP Foundation.

[Madelijn]

Wat? Microsoft en bugs? No way!

Bill Gates zei het zelf: No! There are no significant bugs in our released software that any significant number of users want fixed.

Waarvan akte.

[Triblade_8472]

Wie rekent PHP nu hard af dan?

Wel is het feit dat ze er twee maanden aan gewerkt hebben en niet in staat waren een patch uit te brengen, maar nu er druk lag dit opeens binnen 12 uur gerepareerd hebben.

Daarnaast geld er voor deze bug:
De onderzoeker legt uit dat het beleid van PHP sinds 2017 is om geen CVE-beveiligingsscores toe te kennen aan bepaalde geheugencorruptiebugs.
Dat staat natuurlijk ook niet zo sjiek, ervan uitgaande dat het waar is.

[marsian]

Alleen in 8.5.12? Dan blijf ik mooi nog even op 8.3.36

[jGS]

@marsian Je instinct klopt half 🙂 Even op een rij, met bronnen:

1. De "incomplete patch" van Krassas gaat terug op een geheugenfout in unserialize(). Die zit in álle versies, ook 8.3.36. Maar ze is alleen misbruikbaar als je applicatie unserialize() loslaat op invoer van bezoekers. Nog geen fix of CVE: https://github.com/php/php-src/issues/24481

2. De bug van Katze: volgens haarzelf wel op afstand uit te lokken, maar er code mee uitvoeren noemt ze "really non-trivial". PHP-kernontwikkelaar Ilija Tovilo ziet geen bewijs dat de fix van woensdag tekortschiet.

3. Waar hier nog niemand over sprak: de update zelf heeft een crashbug in SimpleXML, alleen op 8.4.27 en 8.5.12 ("zend_mm_heap corrupted"). Op dát punt zit je met 8.3.36 dus net goed: https://github.com/php/php-src/issues/24488

Kort: updaten blijft verplicht, en de nieuwe meldingen zijn geen tweede php2shell.

Disclaimer: ik werk bij Hosted Power. We onderhouden een gratis open-source extensie die 1 en 3 opvangt tot PHP ze zelf uitbrengt, ook op gepatchte PHP: https://github.com/HOSTED-POWER/php_uploadprogress_guard

[R4gnax]

Voor het geval je dit serieus bedoeld ipv sarcastisch:
de twee kritieke bugs die gisteren wereldkundig werden gemaakt, zitten in alle PHP versies minstens terug tot aan versie 5.4.0

Een aanval op basis van die bugs kan triviaal uitgevoerd worden en geeft de aanvaller remote code execution zodat deze overal bij kan waar PHP bij kan - cq. de mogelijkheid om de server over te nemen als deze niet goed gesandboxd is.

Patchen dus. En niet wachten.

[Reactie gewijzigd door R4gnax op 22 oktober 2026 08:15]

[reputatio]

Ik denk dat dit niet sarcastisch was, gezien ik hier dezelfde vraag heb obv het artikel. Wij hebben alles gepatched, waaronder PHP 8.3 & 8.4 instances. De 8.3.36 is ook de versie met de patch voor de 2 security vulnerabilities.

Echter in dit artikel gaat het over een “nieuwe” en wordt gezegd dat deze aanwezig is in 8.5.12. Maar 8.3.36 & 8.4.27 zijn ook de versies met een patch sinds gisteren, dus is de nieuwe vulnerability beperkt tot 8.5.12 of alle gepatchte versies?

[r03n_d]

8.3.36 is een gepatchte versie, van 8.3 dus.

[marsian]

Mocht het nog niet duidelijk zijn, het was serieus 😊
Als 8.3.36 wel de 2 lekken patched en niet de nieuwe gaten heeft dan zit ik daar best.

[watercoolertje]

Hij is serieus, alleen denk jij dat hij het over de patches van gisteren heeft (die heeft ie dus al binnen gezien zijn versienummer) terwijl hij het over de exploit in dit artikel heeft. En daar wordt enkel gesproken over een lek in 8.5 (wat niks uitsluit maar daar komt zijn opmerking dus vandaag).

Het heeft verder echt niet veel zin om van 8.3 naar 8.5 te upgraden mbt tot de exploits, 8.3 heeft ook nog ondersteuning tot 31 dec 2027 en patches komen voor alle ondersteunde versies gelijktijdig uit.

[Reactie gewijzigd door watercoolertje op 22 oktober 2026 08:44]

[mjz2cool]

8.3.36 is de gepatchte versie voor 8.3.35. Dit artikel vermeld dat 8.5.12 incompleet zou zijn en heeft het niet over andere versies. In dat opzicht is het geen gek idee om dan op 8.3.36 te blijven.

[SuperDre]

Je mag er wel van uit gaan dat als dat probleem er nog in 8.5.12 zit, dat het ook in de 8.2,8.3 en 8.4 versies zit.

[mrmrmr]

Je kunt omwille van veiligheid beslissen te handelen alsof het zo is, maar of het werkelijk zo is zal toch gecontroleerd moeten worden. Er zijn wijzigingen gedaan aan versie 8.5 ten opzichte van eerdere versies.

Dit is een geheugenprobleem en de werking daarvan is afhankelijk van de omliggende code, data, de gebruikte compiler en parameters zoals die voor optimalisatie.

[steffer51]

Als hij 8.3.36 draait, dan is de patch geïnstalleerd.

Idealiter blokkeer je, indien mogelijk, elk verkeer naar je website dat niet afkomstig is van vertrouwde ip adressen.

[MrDrako]

uh hoe zie je dat voor je? buiten mijn eigen netwerk vertrouw ik helemaal niemand.

[steffer51]

Als het over webapplicaties gaat die enkel intern gebruikt worden, kan je enkel jouw ip adres toestaan.

Is uiteraard geen optie voor websites die voor iedereen zichtbaar moeten zijn.

[Peter Huizenga]

simpel gezegd. Stel je heb een website die je laat lopen via een CDN. Wat je dan kan doen is alleen verkeer over 80/443 toelaten op je firewall, proxy, webserver van die vertrouwde CDN.
Op die manier kun je WAF/DDOS etc. toepassen via je CDN die dit soort aanvallen al kan stoppen. Al het andere verkeer wat binnen komt op 80/443 kan je dan afvangen/stoppen met je firewall.

[Mirx_NL]

Php heeft meerdere actief ondersteunde versies. 8.3.36 bevat ook de fix.

Net zoals windows 10 en windows 11 naast elkara bestonden en een tijd lang beide updates kregen.

[YoMarK]

Is toch gewoon een ondersteunde versie? In het artikel hierboven hebben ze het expliciet over 8.5

[SuperDre]

Ga er maar van uit dat het ook voor de 8.2, 8.3 en 8.4 versies van de laatste veiligheidspatches gaat.

[CH4OS]

Daarin is het ook gefixt; download: PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12. Al zie ik geen reden om op een stokoude branch te blijven, ondanks dat het nog supported is.

[Reactie gewijzigd door CH4OS op 22 oktober 2026 08:21]

[StarZ]

Goed dat het onder een vergrootglas ligt maar we moeten niet doen alsof dit uniek is voor PHP. Ik durf te wedden dat we binnen nu en een jaar weer zo'n ernstig lek vinden bij een andere taal of platform. En we moeten niet vergeten dat PHP gewoon gratis is en dat deze mensen dit gewoon gratis oplossen.

Overigens moet ik wel lachen om het plaatje met HTML (zonder enige php?) met een huilend PHP olifantje haha

[3raser]

Ik begreep dat deze bugs eigenlijk al een jaar bekend waren maar dat het volgens PHP onmogelijk was om er een exploit voor te schrijven. AI heeft dit nu toch voor elkaar gekregen. Dan vraag ik me af, waarom niet gewoon patchen als je weet dat het er zit. Was de patch zo ingewikkeld en de exploit zo complex dat niemand er aandacht aan besteedde?

Heeft PHP zijn prioriteiten wel op orde vraag ik me dan af. Als zij kwetsbaarheden zoals in dit artikel als niet-urgent beschouwen maar AI schrijft er binnen 5 minuten een exploit voor, wat is je mening dan nog waard?

[RobertMe]

Ik las iets dat hiervoor iets van 5000 regels code zijn geschreven / gewijzigd. Als dat klopt dan snap ik wel dat een theoretisch maar niet te misbruiken (geacht) lek niet gedicht is. Waarbij meen ik de theorie ook alleen was om de OOM / crash te veroorzaken, niet om met die OOM ook nog eens een RCE te "triggeren".

Had men, achteraf gezien, dit wel meteen moeten fixen? Ja, waarschijnlijk wel. Is het verklaarbaar dat men het toen niet heeft gedaan? Eigenlijk wel. Ook omdat je niet weet welke nieuwe issues je introduceert als je "even" 5000 regels code toevoegt/wijzigt in iets dat schijnbaar al ~20 jaar "prima werkte". Vandaar waarschijnlijk ook de uitgebreidere validatie met én twee security bedrijven én AI. I.p.v. de PHP devs die het zelfstandig fixen zonder dat externe partijen met waarschijnlijk / mogelijk veel meer expertise op het security vlak er naar kijken.

[Jory]

De commit voor maintained branches is +10,759 -988 regels code. Nu zit daar een boel test code e.d. bij, dus ~5000 regels "productie" code dat klinkt niet gek.

De commit voor EOL versies is wel een stuk kleiner, maar zal flink wat hoeken afgesneden hebben (zoals simpelweg hardcoded doen alsof er een feature uit staat).

Dus eens: dit ga je niet doen als je beredeneerd hebt dat iets alleen theoretisch mogelijk is.

[Bedge85]

Er zijn twee zaken waar je rekening mee moet houden.

Als eerste is PHP een community project. Er zijn wel ontwikkelaars die betaald worden door bijvoorbeeld de PHP Foundation. Maar in de basis is het vrijwilligerswerk. Keuzes worden democratisch genomen door ontwikkelaars door middel van een RFC, zoals deze over het genereren van een exception als ongeldige tekens worden gebruikt in bepaalde functies. Het is goed vergelijkbaar met een project als Debian. Zon structuur heeft voordelen, wat ook terug te zien is in de populariteit van deze projecten. Maar som ook nadelen.

Daarnaast is het geen eenvoudige patch. De patch is inclusief tests 11556 regels aan wijzigingen in 423 bestanden. Dit is ten eerste enorm arbeidsintensief terwijl er ook maar een handjevol PHP ontwikkelaars zijn met voldoende kennis van PHP om zoiets te doen. Daarnaast bestaat er de kans dat er hierdoor ook (onvoorziene) zaken niet meer exact zo werken als voor de patch.

Ik denk dat doordat PHP op zoveel plekken gebruikt wordt, mensen ook denken dat er een enorme organisatie achter zit. Maar PHP is in de basis een community die voornamelijk bestaat uit vrijwilligers met een relatief kleine groep betaalde ontwikkelaars. Op https://externals.io/ zijn de discussie op de mailinglist van PHP publiek toegankelijk. Dit kan inzicht geven in de manier waarop er over problemen wordt gepraat en de besluitvorming.

[rjd22]

Het wat inderdaad een enorm complexe patch. De patch nam meer dan 5000 lijnen aan veranderingen in beslag. En dit moet dan met terugwerkende kracht over 3 oudere versies gedaan worden.

[Splashy]

Dat klopt niet helemaal, de mensen bij PHP Foundation die aan PHP werken krijgen gewoon een salaris. Het salaris wordt betaald van de donaties.

[StarZ]

Dat ze het gratis oplossen betekend niet dat ze niet betaald krijgen. Jij betaald niks voor de patch.

[Martinspire]

Gezien Tweakers niet offline is, gok ik dat het niet zulke ernstige bugs zijn als de andere 2 die nu gedicht zijn?

[CH4OS]

Want het moet gelijk offline, omdat er nog niet veel meer duidelijkheid is over wat er nu speelt?

[Webgnome]

Dat is wat MartinSpire dus aangeeft. Blijkbaar is het nog niet ernstig genoeg en ik ga er even vanuit dat de technische mensen binnen Tweakers er boven op zitten en kunnen bepalen OF en wanneer het nodig is om een site down te brengen.

[CH4OS]

Ik snap wat hij bedoelt. Ik bedoel echter, dat het wellicht wat voorbarig is om een website al offline te halen, terwijl alle (technische) details nog niet bekend zijn.

De derde bug is niet bevestigd, er is nog geen impact van bekend, en ook van de mogelijke gemiste mitigaties in de patch van gisteren is ook nog niets bekend, noch bevestigd. Om dan al een website offline te halen omdat het mogelijk nog niet helemaal klaar is, is dan gewoon echt voorbarig.

Het is dan een beetje als heftig reageren op een storm in een glas water.

[Reactie gewijzigd door CH4OS op 22 oktober 2026 10:31]

[jackyallstar]

Mensen waarom moet dit negatief beoordeeld worden? Is toch geen gekke reactie van Martinspire en gewoon On Topic?

[Martinspire]

Ik heb gewoon wat "fans". Er zit altijd wel een -1 of 0 bij. Maar de mods doen er niets aan.

[jackyallstar]

Zeker wat kletskouzen een keer terrecht gesteld? Ik ken er ook een paar. Blijft amusant.

[svennd]

Als je het achtergrond artikel leest, er was reeds active exploitation gededetecteerd voor de patch officieel uit was. Als dat nu niet het geval is gaan ze Tweakers niet offline halen.

[beerten]

Goed dat het nu zoveel aandacht krijgt. Komt de veiligheid alleen maar ten goede. Zeker als de gevonden lekken netjes gemeld worden. En er geen video's gemaakt worden door net iets te enthousiaste nerds

[arjan1995]

Eens, en dit was eigenlijk ook wel te verwachten.

Helaas gaat het alleen bij Krssas alweer fout. Uit het artikel:

Krassas stelt dat meer validatie van de patch nodig is. Hij heeft zijn bevinding online gepubliceerd en claimt werkende proof-of-conceptcode te hebben voor zijn vondst. Hij meldt daarbij dat hij zijn publicatie niet heeft afgestemd met het beveiligingsteam van PHP

Ik heb de git repo bekeken en daar blijkt een PoC in te staan

[hipster]

Ik verbaas me er eigenlijk over dat PHP nog steeds zo populair is in 2026

[Splashy]

Mij niet, het is tegenwoordig een moderne en productive taal waar je makkelijk developers voor kan vinden.

[Botmeister]

Wordpress draait op PHP en heeft een groot aandeel in het aantal websites op het internet. WP was echter snel met online patchen las ik vanochtend. Maar diegene met een standalone server zullen zelf hun WP-omgeving moeten updaten.

[Webgnome]

waarom verbaasd dat je dan? Het is blijkbaar de right tool for the job in heel veel situaties. Net als dat Java/Kotlin is binnen andere sectoren? Of c++?

[ReSpawN]

Kortzichtig. Denk je dat PHP alleen Wordpress als CMS heeft? Snap je dat Tweakers 'gewoon' Symfony draait? Groot deel van de mensen die dit roept, ook in mijn kennis/vrienden/collega-kring, zijn mensen die PHP bij 4.3 of PHP 5.2 verlaten hebben. Ten tijde van die versies hadden we ook Framework 1.1, om nou te zeggen dat dat een pareltje was...

[Sebritar]

tja het is logisch dat het enkel PHP is met open bugs en kwetsbaarheden
/cynisch

Eeuhm ja het wordt nou eenmaal steeds eenvoudiger om exploits te vinden en uit te buiten. Alle systemen en alle talen kennen tekortkomingen. Om nou serieus te denken dat PHP de enige is zal wat kort door de bocht zijn.

[air2]

Het is meer de omgang met security meldingen en security in het algemeen. Niet zozeer dat deze bugs gevonden worden.

[CapnCrinkle]

Lijkt mij ook onwaarschijnlijk, maar to be fair is het wel zo dat PHP bepaalde taken automatiseert zodat de developer zich daar geen zorgen meer over hoeft te maken. Bij talen waarbij de developer (meer) controle heeft over deze zaken, zullen security bugs vaak meer bij de developer liggen en minder bij de achterliggende taal.
Dat gezegd hebbende zijn de meeste modernere talen volgens mij al op een punt waar je dit soort zaken al niet meer zelf afhandelt.

Van wat ik begreep van deze bugs, is één ervan ook behoorlijk afhankelijk van een bepaalde techniek (php_mod ivm apache) welke ook al lang niet meer overal gebruikt wordt. Tegenwoordig is héél veel al php-FPM, waarmee één van de grootste risico's al mitigated is van wat ik begrijp.

That said, zekerheid heb je ook niet. Mijn zooi was gewoon online en ik ben nu access logs, files en error logs aan het tracen voor verdachte zaken maar tot nu toe komt er in ieder geval niets boven water. Geen verdachte files of verbindingen, buiten je gemiddelde "gok bots" die gewoon wordpress commands opsturen en dat soort zaken (ik gebruik geen wordpress).

Ik vraag me af of er mogelijk nog meer details naar buiten zullen komen over welke configuraties nou écht precies geraakt konden worden op welke manieren.
Al mijn zooi was om 16:00 iig gepatched dus het was geen super lange periode dat het nog online stond zonder de patch, maar je weet nooit of een bot niet toevallig jouw spul heeft getarget, interessant doelwit of niet.

[TheDevilOnLine]

Heel bot gezegd: Dit soort beveiligingsonderzoekers, die zichzelf en de issues die ze vinden heel belangrijk vinden, zijn precies de reden waarom de bugs die gisteren gepatched zijn zo lang zijn blijven liggen. Ze vinden alle issues die ze vinden kritiek, waardoor security teams van software bedrijven bedolven worden onder gevonden bugs (waarvan meer dan de helft geen bug is).

De bugs van beide onderzoekers ontstaan alleen als je ZMM (Zend Memory Management) uitschakeld, waarna ze het gek vinden dat er problemen met het memory management ontstaan. Is dat een bug: ja. Moet het opgelost worden: ja. Moet daarvoor iedereen alles laten vallen om het maar op te lossen: nee absoluut niet.

Stel je hebt een auto. Als je weet wat je doet, dan is het doorsnijden van je remleidingen, risky maar ok. Als je niet weet wat je doet en je ervoor kiest om je auto standaard te laten is er ook geen enkel probleem. Als je niet weet wat je doet, en dan je remleidingen doorsnijdt en gaat rijden, dan heb je een flinke uitdaging. Moeten dan meteen alle auto's teruggeroepen worden om sterkere remleidingen aan te brengen?

Zowel Krassas als Katz maken wat mij betreft misbruik van de situatie en de angst die na gisteren is ontstaan, alleen maar om te laten zien hoe belangrijk en goed ze zijn, zonder enige nuance aan te brengen. Dat is misschien nog wel gevaarlijker dan de bug zelf. Door onduidelijk te zijn in de duiding van de issue (en hoe die te voorkomen) is het een geweldige bron voor social engineering en mensen gaan proberen te verleiden om juist hun instellingen aan te passen zodat ZMM uit staat en men kwetsbaar wordt.

Voor mij is dit vergelijkbaar met sommige Amerikaanse rechtszaken waardoor op koffie de melding staat "Pas op heet" en dat in de handleiding van de magnetron staat dat je je baby er niet in mag stoppen.

[Reactie gewijzigd door TheDevilOnLine op 22 oktober 2026 09:41]

[bugcyber]

De bugs van beide onderzoekers ontstaan alleen als je ZMM (Zend Memory Management) uitschakeld, waarna ze het gek vinden dat er problemen met het memory management ontstaan. Is dat een bug: ja. Moet het opgelost worden: ja. Moet daarvoor iedereen alles laten vallen om het maar op te lossen: nee absoluut niet.

Dit vind ik wel nuttige informatie. De bugs zijn er dus enkel in een opstelling die je niet snel in een productie omgeving zal tegenkomen.

[Webgnome]

Een van de twee zegt ook zelf, op Mastodon, dat dit geen groot probleem is voor nu. Ze stipte het alleen aan omdat ze had verwacht dat dit ook mee genomen zou worden in deze patch.

[ReSpawN]

Fijn, lekker onder het vergrootglas een van de grote webtalen beter maken, bedankt!

Ik bedien PHP, .NET, Java, Python en natuurlijk TS/JS, maar mijn LinkedIn staat vol met profiteurs die claimen dat hun taal superieur en veilig is. Bot gezegd? Rot op man. 1 query richting Google, eigenhandig opgezocht, zonder AI, voor alleen al .NET, vond ik een 9.9 op de schaal van 'omfg': CVE-2025-55315. Elke taal heeft z'n eigen problemen gehad en zal ze ongetwijfeld weer krijgen.

In het AI-tijdperk gaan we dit alleen maar vaker zien in Open Source software. Slecht? Ik denk het niet. Voor de 999 mensen die het gedicht hebben zal er altijd wel 1 rotte appel tussen zitten, en liever dat met die 999 gebruiker een AI meekijkt en signaleert dat er een lek is. Kom maar door, samen maken we internet.com veiliger.

[Reactie gewijzigd door ReSpawN op 22 oktober 2026 10:22]

[Memori]

mijn LinkedIn staat vol met profiteurs die claimen dat hun taal superieur en veilig is.

Een van de kenmerken van een junior (<10jr ervaring) programmeur.

[ReSpawN]

Dat lijkt me ook ja. Kortzichtig... Goed, met 26 jaar ervaring (ik word oud...) weet ik wel beter, maar het triggert wel.

[CybrWire]

Een van de drie paden die Nicolas Krassas beschrijft, is een mislukte sessiedecode waarbij __wakeup() en __destruct() nog steeds worden uitgevoerd. Ik heb dat hier gerapporteerd: https://github.com/php/php-src/issues/24518.

Het is een enginebug en het effect is beperkt tot een klasse die de applicatie al had geladen. Met andere woorden: leest de ene site een sessiebestand dat een andere site (op hetzelfde systeem) anders heeft opgeslagen, dan gooit PHP de sessie weg — maar voert vóór het weggooien toch nog de opstart- en opruimcode van het halfgelezen object uit. Dat doet alleen iets als de website zelf zo'n klasse heeft. Dit is geen manier om een server over te nemen.

De geheugenfout is een andere melding: PHP geeft geheugen vrij en gebruikt het daarna opnieuw, als de opruimcode van een object nogmaals unserialize() aanroept. Die staat open als https://github.com/php/php-src/issues/24481 en eerder al als https://github.com/php/php-src/issues/21824.