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

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

[Tanx0r]

Niet helemaal waar. Achter elke Windows bak zit een online werkende gebruiker. Van die gebruikers kan 90% te debiel om te lezen en klikt op Okay of Accept zonder ooit te kijken of te denken waarom. Gebeurt dit binnen een bedrijfsnetwerk dan heb je de poppen aan het dansen.

Puur om deze reden geven bedrijven jaarlijks grote bedragen uit aan beveiligingsoftware en firewall technologie die moet meekijken op de applicatielaag.

Daarmee is Windows vrijwel net zo makkelijk binnen te dringen als een online server. Bugs in Windows hebben hiermee wel degelijk een zeer grote impact.

1400+ bugfixes op een patch tuesday is belachelijk.

Ik zeg niet dat we minder scherp moeten zijn op de bugs in PHP, ik zeg dat we net zo scherp moeten zijn op de bugs in Windows.

[martijnn]

Exact dit! Hanteer dan ook het Assume Breach principe. Ook interne servers zo snel mogelijk updaten.

[YGDRASSIL]

Deze PHP bugs maken het mogelijk een server op afstand over te nemen zonder credentials. Geen van de 1400 tuesday bugs maakten dat mogelijk. Dat microsoft lekker bezig is zijn software te verbeteren is top. En soms hebben die een serieuze issue, dan staat daar het vergrootglas op. Zoals inderdaad bij wannacry. Nu is het even PHP

[pegagus]

Dat ik te debiel ben om te lezen, komt omdat de systeembeheerders te debiel zijn om bepaalde foutmeldingen uit te schakelen. Dat voedt bij mij het patroon om bij foutmeldingen gewoon domweg op OK te klikken. Dus als ransomware mij als medewerker bereik middels een gefingeerde foutmelding en achter de OK-knop weet ik veel wat gebeurt, ja dan gaat het mis.

Ondertussen vraag ik mi of hoeveel bugs het coderen met AI-tools zelf wel niet met zich mee brengt. Mijn indruk is dat de codebrij als maar toeneemt. Onlangs een gigabyte van NVidia moeten downloaden, zijnde een videodriver van mijn laptop.

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

[Glashelder]

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

[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

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

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

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

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

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

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

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

[Ik_ben_Timo]

Dankjewel

[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

[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. ¯\_(ツ)_/¯

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

Dat snap ik. Ik bedoel, 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. Om dan al een website offline te halen omdat het mogelijk nog niet helemaal klaar is, is dan gewoon echt voorbarig.

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

[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

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

[marsian]

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

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

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

[r03n_d]

8.3.36 is een gepatchte versie, van 8.3 dus.

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

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

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

[YoMarK]

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

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

[haroldsnel]

Dit soort issues gaan we vaker krijgen aangezien het steeds makkelijker wordt om met AI zulke exploids te vinden. Ligt er dan maar net aan wie sneller is. Diegene die sites wil 'hacken' of diegene die het juist wil voorkomen.

[Scriptkid]

Het probleem is nu wel dat andere onderzoekers zoals in het artikel nu hard roepen dat er meer issues zijn.

Dat moeten ze niet doen, niet in het nieuws , Denk dat er nu genoeg AI aan het zoeken gezet zijn.

Je kan dan lekker roepen ja maar de proof on concept heb ik niet laten zien , tja dat heeft aan Goede AI ook zo gevonden met een paar dagen scannen waarschijnlijk.

[ThomTech]

Ik snap je punt. Aan de andere kant vraag ik me af of de hackers deze data niet veel sneller onderling verspreiden als dat wij denken. Ik denk dat je het daarom toch kenbaar moet maken ondanks dat je dan de deuren misschien open zet.

Als niemand weet dat er een lek is, en aan de "dark side" wordt die info wel gewoon doorverkocht, dan zit je met 1 dat het een verdien model is voor iemand dus veel interessanter om dit te blijven doen en 2 dat met niet weet dat er iets mis is, en dus ook geen maatregelen kan treffen, dus langer kwetsbaar is.

Het is een blijft een kat en muis spel wat dat aangaat. Ik hoop alleen dat we met z'n alle snel genoeg blijven om alles zo veilig mogelijk te houden. Met alles van de laatste weken worden we wel met de voetjes op de grond gezet. Ik ben benieuwd de komende tijd.

[RobertMe]

Het is hopelijk / waarschijnlijk wel een tijdelijk probleem. AI laten zoeken naar security issues wordt gewoon onderdeel van het development proces waardoor er dus ook geen software wordt uitgebracht met lekken, die AI had kunnen vinden. Hoogstens dat nieuwe / verbeterde modellen eens in de zoveel tijd iets vinden dat daarvoor nog niet gevonden werd door de oudere / slechtere modellen. Maar de "baseline" zal wel hoger komen te liggen.

Hetzelfde als dat je bij development zonder AI steeds verbeteringen zag. Waar 20+ jaar terug wachtwoorden nog in plaintext werden opgeslagen is de kans daarop nu zeer klein omdat iedereen weet dat het veel beter moet. En waar 15, 20 jaar terug het nog voor kwam dat SQL queries aan elkaar werden geplakt met mogelijke SQL injection lekken tot gevolg zal nu iedereen prepared statements / parameterized queries gebruiken. En zo zal ook AI ervoor zorgen dat de standaard in defensief programmeren tegen beveiligingsissues omhoog gaat. Uiteraard ook geholpen door nieuwe / modernere programmeertalen die ook veiliger zijn opgezet, zoals Rust i.p.v. C/C++.

[hakariki]

"beveiligingsonderzoeker" Is dit nieuw beleid van DPG Media om vrouwen een mannelijke versie te geven van woorden? Ik zie dit nu ineens ook gebeuren op nu.nl. Waarom gebruiken we niet de normale vrouwelijke vorm? Ik zie soms heel gedetailleerde redeneringen plaatsvinden van Tweakers redacteuren over een correcte vorm van een woord. Maar het gebruiken van het juiste gender voor een woord is dan ineens niet belangrijk?

[DrBackBeat]

Is 'beveiligingsonderzoeker' niet gewoon neutraal dan? We vinden 'wolkenkrabber' ook geen mannelijk woord toch?

Ik draai het om, het is gek om in geval van een vrouw ineens een toevoeging te maken om aan te duiden 'let op het is nu wel een vrouw he'. Woorden zonder een geslachtsaanpassing vind ik verreweg de meest logische manier om voortaan alle personen aan te wijzen, naast 'man' of 'vrouw' te vervangen met 'persoon' waar mogelijk.

[hakariki]

Je kunt het gek vinden maar dat zijn de regels van de Nederlandse taal.

Wolkenkrabber is een zelfstandig naamwoord van een object. Dit object heeft een enkel gender. In dit geval mannelijk.

Het gender van onderzoeker is mannelijk. Het gender van onderzoekster is vrouwelijk.

[piertje1984]

Af en toe een keer heel hard op je snufferd gaan en vervolgens drie keer zo hard je best doen om het in de toekomst te voorkomen is wel eens goed.

[Transportman]

Maar alleen als dat voorkomen ook de nieuwe situatie blijft. Ik verwacht dat binnen een paar maanden heel wat bedrijven weer in het oude gedrag vervallen dat patchen weer onvoldoende aandacht krijgt.

[piertje1984]

En helaas heb je daar een sterk punt. Toen ik nog bij een hostings bedrijf werkte... man man de hoeveelheid webbouwers die bakken met geld vragen/verdienen met onderhoud contracten en vervolgens gewoon in PHP 5.nogwat bleven hangen ja want anders draait die niet goed of dat werkt niet. Dat was echt om te huilen.

En als WP dan bepaalde functies niet meer beschikbaar zette voor oudere PHP versies moesten wij het maar fiksen.

[Hoi1966]

Op naar de 4e en 5e bug en het zal nog wel een tijdje doorgaan ben ik bang ;-)