Cloudflare ziet miljoenen aanvalspogingen na openbaarmaking van PHP-lekken
Duizenden aanvalspogingen vóór de bekendmaking. Tienduizenden binnen 45 minuten erna. Twee uur later stond de teller al op honderdduizenden en daarna op miljoenen.
Cloudflare-topman Matthew Prince beschrijft daarmee hoe snel aanvallers zich op twee zware PHP-lekken stortten. Die cijfers meten aanvalspogingen op het Cloudflare-netwerk. Ze bewijzen niet dat miljoenen websites zijn gehackt.
Aanvallen begonnen al vóór de publieke aankondiging
Prince deelde de cijfers op 22 oktober via X.
Volgens hem registreerde Cloudflare in de tien uur vóór de publieke bekendmaking al duizenden pogingen om de kwetsbaarheden te misbruiken.
Daarna liep het tempo snel op.
Binnen 45 minuten zag Cloudflare tienduizenden pogingen. Binnen twee uur ging het om honderdduizenden. Vervolgens steeg het totaal naar miljoenen.
Dat patroon laat vooral zien hoe klein het tijdsvenster na een beveiligingsmelding kan zijn.
Miljoenen pogingen zijn geen miljoenen hacks
De grote aantallen vragen om een belangrijke grens.
Een exploitpoging is een verzoek dat kenmerken bevat van een aanval. Dat betekent niet automatisch dat de achterliggende server kwetsbaar was of dat de aanval slaagde.
Eén aanvaller kan bovendien duizenden verzoeken versturen.
Ook kunnen veel pogingen op dezelfde website of server worden gericht.
Uit Prince' cijfers volgt daarom niet hoeveel bedrijven daadwerkelijk zijn binnengedrongen, hoeveel gegevens zijn buitgemaakt of hoeveel servers zijn overgenomen.
Cloudflare geeft in deze telling ook geen succespercentage.
Twee PHP-lekken maken code-uitvoering mogelijk
De aanvalsgolf draait om CVE-2026-109618 en CVE-2026-109619.
Het PHP-project beoordeelt beide kwetsbaarheden als kritiek. Ze kunnen onder de juiste omstandigheden leiden tot remote code execution zonder dat de aanvaller eerst hoeft in te loggen.
Dat betekent dat kwaadaardige code met de rechten van het getroffen PHP-proces op de server kan worden uitgevoerd.
De kwetsbaarheden zitten in PHP zelf.
Alleen een WordPress-plugin, thema of andere webapplicatie bijwerken is daarom niet voldoende wanneer daaronder nog een kwetsbare PHP-versie draait.
Eerste fout raakt afhandeling van geheugentekort
CVE-2026-109618 draait om de manier waarop PHP reageert wanneer het proces tijdens een verzoek tegen een geheugentekort aanloopt.
Onder bepaalde omstandigheden stopt PHP een bewerking terwijl interne gegevens nog niet correct zijn opgebouwd.
Tijdens het opruimen van dat verzoek kan vervolgens ongeldige geheugeninhoud worden gebruikt.
De PHP-onderzoekers hebben remote code execution via HTTP bevestigd bij Apache mod_php.
Andere omgevingen kunnen eveneens kwetsbaar zijn, al hangt de precieze aanval af van configuratie, PHP-build en gebruikte software.
Tweede fout kan oude geheugentoestand meenemen
Bij CVE-2026-109619 blijft onder bepaalde omstandigheden interne toestand verwijzen naar geheugen van een eerder verzoek.
Dat geheugen is dan al vrijgegeven.
Een later verzoek kan die verouderde verwijzing opnieuw gebruiken voordat PHP alles correct heeft geïnitialiseerd.
Ook daarmee is remote code execution aangetoond.
Voor sommige aanvalspaden moeten twee verschillende verzoeken uiteindelijk door hetzelfde PHP-workerproces worden afgehandeld. Dat maakt een succesvolle aanval complexer, maar verwijdert het risico niet.
PHP bracht vier beveiligingsversies uit
Het PHP-project publiceerde op 21 oktober patches voor alle ondersteunde hoofdtakken.
De veilige versies zijn:
| PHP-tak | Beveiligingsversie |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
De officiële melding zegt dat er geen volledige tijdelijke oplossing bestaat die het installeren van de patch vervangt.
Voor oudere PHP-versies ligt nog een extra probleem.
PHP 8.1 en eerder zijn uit reguliere ondersteuning en krijgen deze beveiligingsupdates niet. Beheerders van zulke systemen moeten daarom niet alleen patchen, maar naar een ondersteunde versie overstappen.
Cloudflare zette bescherming vóór openbaarmaking aan
Cloudflare hoefde niet tot de publieke aankondiging te wachten.
Het bedrijf schrijft in zijn technische analyse dat het vooraf samenwerkte met onder meer het PHP-project en beveiligingsonderzoekers.
Vanaf 21 oktober om 03.02 uur UTC stonden nieuwe WAF-regels volgens Cloudflare standaard aan voor klanten met de betreffende bescherming.
Dat was ongeveer negen uur vóór de publieke bekendmaking.
Cloudflare zegt ook toen al aanvalspogingen te hebben gezien.
Dat sluit aan op Prince' latere telling dat het verkeer vóór de formele publicatie al begon.
WAF is extra bescherming, geen vervanging voor patch
Cloudflare probeert verdachte verzoeken voor de kwetsbare server tegen te houden.
Het bedrijf ontwikkelde hiervoor ook een methode die niet alleen naar het inkomende verzoek kijkt, maar naar verzoek én antwoord van de server.
Dat helpt bepalen of iets alleen op een exploit lijkt of dat de reactie van de server extra signalen geeft dat er daadwerkelijk iets fout ging.
Toch adviseert Cloudflare klanten nadrukkelijk hun PHP-versie zelf bij te werken.
Een Web Application Firewall staat immers vóór de toepassing.
De fout blijft in PHP aanwezig zolang de kwetsbare versie op de server draait.
Voor cryptobedrijven zit het risico buiten de blockchain
Ook cryptobedrijven kunnen PHP gebruiken.
Denk aan een handelsplatform, klantenportaal, helpdesk, beheeromgeving of API die via een normale webserver draait.
Een fout in die systemen hoeft niets te veranderen aan de onderliggende blockchain.
Een exchange kan bijvoorbeeld een kwetsbare website hebben terwijl het netwerk waarop opnames worden verwerkt technisch normaal blijft functioneren.
Die scheiding is belangrijk.
“Cryptoplatform getroffen” betekent niet automatisch dat Bitcoin, Ethereum of een andere blockchain zelf is gehackt.
Servertoegang kan wel nieuwe aanvalspaden openen
Dat maakt een kwetsbare webserver niet onschuldig.
Wanneer een aanvaller code op een server kan uitvoeren, hangt de vervolgschade af van wat dat proces kan bereiken.
Mogelijke doelen zijn gebruikersgegevens, sessies, interne systemen of configuratiebestanden.
Bij een cryptodienst kan ook informatie rond API's, stortingen of wallets interessant zijn.
Dat betekent niet dat de PHP-fout rechtstreeks wallet-privatekeys blootlegt.
Daarvoor moet de getroffen server daadwerkelijk toegang hebben tot zulke gevoelige gegevens.
Een beschikbare patch beschermt nog geen oude server
Daarmee zit het belangrijkste verschil tussen publicatie en bescherming.
Sinds 21 oktober bestaan gecorrigeerde PHP-versies.
Maar iedere server waarop nog een kwetsbare versie draait, blijft afhankelijk van aanvullende verdediging en zijn eigen blootstelling.
Juist daarom tellen de miljoenen verzoeken van Cloudflare.
Niet omdat ze miljoenen succesvolle inbraken bewijzen, maar omdat ze laten zien hoe snel aanvallers een nieuw openbaar aanvalspad automatiseren.
Voor cryptobedrijven en andere websitebeheerders is de tijd tussen “patch beschikbaar” en “patch daadwerkelijk actief” daardoor geen administratief detail.
Dat is het venster waarin de aanval al loopt.
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
