PHP Foundation erkent dat personeelstekort kritieke beveiligingsfix maanden vertraagde
Een ernstige fout in PHP bleef langer liggen dan technisch nodig was. Niet alleen omdat een veilige reparatie moeilijk bleek, maar ook omdat te weinig ervaren ontwikkelaars beschikbaar waren en besluitvorming vastliep.
De PHP Foundation noemt die vertraging zelf een structureel falen.
Het onderliggende probleem was al in 2024 gezien. Pas nadat onderzoekers in augustus 2026 lieten zien dat dezelfde fout daadwerkelijk tot uitvoering van code op afstand kon leiden, kreeg de reparatie de hoogste prioriteit.
Probleem was al in 2024 bekend
De PHP Foundation beschrijft de tijdlijn in een verantwoording na de beveiligingsrelease van 21 oktober.
Bij één van de twee kritieke kwetsbaarheden zat het probleem diep in het geheugenbeheer van PHP.
Wanneer een request precies op een ongunstig moment tegen de ingestelde geheugenlimiet liep, kon intern gedeeltelijk geïnitialiseerde data achterblijven. PHP kon die informatie later behandelen alsof zij geldig was.
Dat kon geheugen beschadigen.
De ontwikkelaars hadden in 2024 al een verwant probleem gezien. Een praktische route naar volledige remote code execution was toen nog niet bekend.
Repareren dreigde andere software te breken
Een oplossing kiezen bleek lastig.
De relevante code wordt door vrijwel ieder PHP-request geraakt. Een wijziging kon daardoor gevolgen hebben voor prestaties, bestaande applicaties en externe PHP-extensies.
Verschillende mogelijke oplossingen hadden ieder nadelen.
Daar kwam een organisatorisch probleem bovenop.
Volgens de Foundation was slechts een kleine groep ontwikkelaars beschikbaar met voldoende diepgaande kennis van de PHP-engine. Zij hadden daarnaast andere verantwoordelijkheden.
Het resultaat: discussies liepen vast en werk aan de fix begon volgens de organisatie meerdere keren opnieuw.
Foundation noemt vertraging structureel falen
De organisatie draait daar niet omheen.
De vertraging kwam volgens haar door zowel het interne besluitvormingsproces als een tekort aan capaciteit.
Dat is een belangrijk onderscheid.
Een moeilijke reparatie kan tijd kosten omdat ontwikkelaars moeten voorkomen dat de oplossing zelf nieuwe problemen veroorzaakt.
Maar wanneer een klein aantal specialisten en moeizame consensusvorming het proces verder vertragen, ligt het probleem niet meer uitsluitend in de code.
De PHP Foundation zegt haar werkwijze daarom aan te passen. Besluiten moeten sneller via meerderheidsvorming kunnen worden genomen en moeilijke compromissen mogen minder lang blijven hangen.
11 augustus veranderde de ernst van het dossier
De omslag kwam deze zomer.
Securitybedrijf Calif begon op 30 juli met een PHP-audit. Op 11 augustus rapporteerde onderzoeker Ryan A een aanval waarmee zonder authenticatie code kon worden uitgevoerd.
De oorzaak bleek dezelfde te zijn als bij het eerder bekende geheugenprobleem.
OpenAI meldde diezelfde dag onafhankelijk dezelfde onderliggende fout.
Vanaf dat moment werd duidelijk dat het risico veel groter was dan eerder bewezen kon worden. De Foundation maakte de reparatie vervolgens de hoogste prioriteit voor zijn beveiligingsteam.
Meer onderzoekers vonden aanvullende aanvalsroutes
Daar bleef het niet bij.
Wiz leverde volgens de Foundation op 24 augustus aanvullende informatie. OpenAI meldde op 18 september verdere aanvalsroutes.
Ook Trail of Bits voerde later onderzoek uit.
Die nieuwe resultaten veranderden niet alleen de hoeveelheid informatie.
Ze maakten concreter wat een aanvaller werkelijk met het probleem kon doen.
Dat verschil telt bij beveiligingsonderzoek.
Een verdachte fout in geheugenbeheer is ernstig. Een reproduceerbare aanval waarmee op afstand code kan worden uitgevoerd, verandert direct de prioriteit.
Een melding is nog geen patch
Juist daar zit de bredere les.
Een onderzoeker die een fout vindt, heeft één deel van het werk gedaan.
Daarna moet iemand de melding reproduceren. De aanvalsmogelijkheden moeten worden vastgesteld. Een reparatie moet worden ontworpen, getest en beoordeeld.
Vervolgens moet die wijziging veilig naar meerdere ondersteunde PHP-versies.
Bij software die op grote aantallen servers draait, kan een overhaaste fix zelf schade veroorzaken.
De afstand tussen “we hebben een bug gevonden” en “iedereen kan veilig updaten” kan daardoor groot zijn.
106 afgewezen rapporten kostten eveneens menselijk werk
Die druk wordt groter doordat beveiligingsteams steeds meer meldingen krijgen.
De PHP-securityploeg meldde op 14 oktober dat sinds 1 juli vijftien CVE's waren gepubliceerd.
In dezelfde periode werden 106 andere rapporten gesloten.
Die meldingen bleken bijvoorbeeld geen beveiligingslek, waren duplicaten of konden niet worden gereproduceerd.
Maar ook een verkeerde melding kost tijd.
Iemand moet haar lezen, proberen na te bootsen en beoordelen voordat verantwoord kan worden besloten dat er geen kwetsbaarheid is.
AI versnelt onderzoek, maar niet iedere beslissing
De PHP Foundation gebruikt zelf AI bij beveiligingswerk.
Eerder werd PHP onderzocht met Claude Mythos. De organisatie zegt daarnaast OpenAI's Daybreak Red te gebruiken bij het valideren van rapporten en exploits.
AI helpt ook om meldingen met dezelfde oorzaak bij elkaar te brengen.
Maar de PHP-securityploeg zegt expliciet dat mensen iedere uiteindelijke beslissing nemen.
Een mens bepaalt de ernst en schrijft of controleert iedere patch.
Dat is precies waar een groter aantal automatisch gevonden bugs tegen een harde grens kan lopen.
Meer vondsten betekenen ook meer menselijke beoordelingen.
PHP breidde zijn securityteam dit jaar uit
De Foundation heeft zijn capaciteit in 2026 al vergroot.
In mei werd een apart Ecosystem Security Team opgericht voor triage, coördinatie en verdere beveiligingsverbeteringen.
Alexandre Daubois kwam in juli erbij om beveiligingsmeldingen te behandelen. Daniel Scherzer volgde in september voor aanvullend hardeningwerk.
Volgens de Foundation maakte financiering het tijdens de recente crisis mogelijk dat meerdere mensen voltijds aan het probleem werkten, inclusief weekenden.
Dat onderstreept ook het probleem dat de organisatie zelf benoemt.
Kritieke opensourcesoftware kan wereldwijd door bedrijven worden gebruikt, terwijl een relatief kleine groep mensen de moeilijkste reparaties draagt.
Twee kritieke kwetsbaarheden zijn nu gepatcht
Op 21 oktober verschenen uiteindelijk vier nieuwe PHP-versies:
PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35.
Ze repareren CVE-2026-109618 en CVE-2026-109619.
Het PHP-project waarschuwt dat beide kwetsbaarheden onder de juiste omstandigheden uitvoering van code op afstand zonder authenticatie mogelijk maken. Voor ondersteunde PHP-installaties geldt het advies om direct te upgraden.
PHP noemt daarbij geen volledige alternatieve mitigatie.
Updaten is volgens het project de veilige oplossing.
De twee fouten werken niet exact hetzelfde
CVE-2026-109618 draait rond geheugenbeschadiging bij een out-of-memory-situatie.
Voor Apache met mod_php is volgens de PHP Foundation aangetoond dat een niet-ingelogde aanvaller de fout kan uitlokken voordat applicatiecode wordt uitgevoerd.
Ook via PHP-FPM is remote code execution bevestigd via routes in applicatiecode.
CVE-2026-109619 draait om oude interne toestand die na een fatale fout kan blijven verwijzen naar geheugen uit een eerder request.
Ook daar werd uiteindelijk uitvoering van code tegen een echte applicatie aangetoond.
Het zijn dus daadwerkelijke kritieke kwetsbaarheden.
Niet alleen theoretische waarschuwingen.
De release liep zelf nog tegen problemen aan
Zelfs de laatste fase verliep niet volledig volgens plan.
Twee dagen vóór de geplande release begonnen de CVE-nummers online te circuleren. Daarna verscheen ook materiaal rond een proof of concept.
PHP schoof zijn bekendmaking en uiteindelijke release daarom naar voren.
Volgens de Foundation was de oorspronkelijke planning juist bedoeld om softwaredistributeurs voldoende tijd te geven de patches klaar te zetten voordat technische details openbaar werden.
Dat laat nog een lastig onderdeel van beveiligingswerk zien.
Een patch moet snel verschijnen.
Maar gebruikers moeten hem op dat moment ook daadwerkelijk kunnen installeren.
Meer bugvondsten vergroten de druk na de ontdekking
De verklaring van de PHP Foundation legt daardoor een zwakke plek bloot die breder is dan PHP.
AI en geautomatiseerde scanners kunnen steeds sneller verdachte code vinden.
Dat kan de veiligheid verbeteren.
Maar een verdubbeling van het aantal bruikbare meldingen verdubbelt niet vanzelf het aantal ontwikkelaars dat diep genoeg in een project zit om veilige reparaties te ontwerpen.
Bij belangrijke opensourcesoftware kan ontdekking daardoor sneller opschalen dan herstelcapaciteit.
Geld voor audits alleen lost dat niet op
Voor bedrijven die zwaar van opensourcesoftware afhankelijk zijn, zit daar een ongemakkelijke rekensom.
Een externe audit kan nieuwe fouten vinden.
Een bug bounty kan onderzoekers stimuleren bewijs aan te leveren.
Maar na de vondst moeten nog steeds mensen beschikbaar zijn voor triage, patchontwikkeling, review, testen en releasecoördinatie.
Die werkzaamheden zijn minder zichtbaar dan een nieuwe CVE.
Ze bepalen wel hoe lang gebruikers blootgesteld blijven.
De PHP Foundation vraagt bedrijven die van PHP afhankelijk zijn daarom expliciet om financieel bij te dragen aan het beveiligingswerk.
De fout zat uiteindelijk ook in de capaciteit
De patches zijn nu beschikbaar.
Daarmee is de directe technische opdracht duidelijk: beheerders van ondersteunde PHP-versies moeten bijwerken.
Maar de verklaring van de Foundation blijft ook daarna relevant.
Het probleem werd niet maanden vertraagd omdat niemand ooit naar de code keek.
Er waren aanwijzingen. Er waren moeilijke technische keuzes. Er was te weinig specialistische capaciteit om die keuzes snel genoeg af te dwingen.
Op 11 augustus bewees nieuwe research hoe ernstig de fout kon worden.
Pas daarna ging het volledige gewicht van het securityteam erop.
De kwetsbaarheid zat in PHP.
De vertraging zat ook in het aantal mensen dat haar verantwoord kon repareren.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
