Twee kritieke PHP-lekken, en waarom we Justflows in TypeScript bouwen

Op 21 oktober 2026 publiceerde het PHP-project twee kritieke beveiligingsadviezen, CVE-2026-109618 en CVE-2026-109619. Beide scoren 9,2 op 10. Met beide kan een aanvaller zonder account en zonder wachtwoord eigen code uitvoeren op je webserver. Elke ondersteunde PHP-versie is getroffen.

Wij bouwen Justflows in TypeScript, dus deze bugs raken ons niet. Toch hebben we ze goed gelezen, omdat ze iets over PHP laten zien dat groter is dan één slechte week. Maar eerst het deel dat ertoe doet als je vandaag PHP draait.

Het eerste advies (GHSA-w8hw-w9fx-j79w) heet "RCE via OOM corruption". Als een PHP-verzoek zonder geheugen komt, stopt PHP het met longjmp(), een C-instructie die direct terugspringt naar een foutafhandeling en alles daartussen overslaat. Gebeurt dat terwijl een deel van het verzoekgeheugen pas half is ingericht, dan leest de opruimcode die daarna draait geheugen dat nooit geldig was. De mislukte allocatie hoeft niet eens iets met het kapotte geheugen te maken te hebben.

Een aanvaller heeft dus alleen een manier nodig om PHP op het juiste moment zonder geheugen te laten komen. Een uploadformulier is genoeg. Het advies noemt meerdere ingangen:

Het PHP-team bevestigde remote code execution via gewoon HTTP tegen mod_php, met de standaardlimieten van PHP voor geheugen en invoer. PHP-FPM en FrankenPHP lijken op basis van de broncode kwetsbaar, al is daar geen volledige exploit voor getoond. Meer workers betekent dat een aanval meer pogingen nodig heeft. Het houdt hem niet tegen.

Het tweede advies (GHSA-6wmf-4rv5-p3rp) heet "RCE via stale global state". PHP beschrijft zichzelf graag als shared-nothing: elk verzoek begint schoon. In de praktijk is een PHP-worker een langlopend proces dat tussen verzoeken globale state bewaart, voor fouten, sessies, objecten en extensies. De engine hoort dat allemaal na elk verzoek te resetten.

Sterft een verzoek halverwege, door een fatale fout, een time-out of geheugentekort, dan kan een deel van die state blijven wijzen naar geheugen dat al is vrijgegeven. Het volgende verzoek op dezelfde worker gebruikt het dan. Dat is een use-after-free, de klassieke bug in geheugenveiligheid, en hier leidt die tot het uitvoeren van code.

De bevestigde aanval gebruikt de voortgang van sessie-uploads, een functie die standaard aan staat. Die bleek te werken tegen zowel mod_php als PHP-FPM. Zelfs een waarschuwing over een verkeerde instelling in php.ini of een Apache-bestand .htaccess kan de stap zijn die de oude state leest. error_reporting lager zetten helpt niet.

Elke taal heeft beveiligingsbugs, dus het is een terechte vraag waarom deze twee iets over PHP zelf zeggen. Kijk naar wat ze gemeen hebben:

Niets hiervan is een recente fout. Het is het verzoekmodel waarop PHP in de jaren negentig is gebouwd, voor een web van kleine scripts. PHP heeft sindsdien veel toegevoegd: een JIT, types, enums, readonly properties. Maar de engine eronder werkt nog steeds op dezelfde manier, en deze adviezen laten zien hoe dat er in 2026 uitziet.

Toen we met Justflows begonnen, kozen we TypeScript op Node.js voor de hele stack: server, admin, editor, plugin-SDK en thema's. Deze adviezen laten goed zien waarom.

TypeScript is geen beveiligingsgarantie, en we gaan niet doen alsof. Node.js en V8 zijn in C++ geschreven en hebben hun eigen CVE's. npm heeft supply-chain-aanvallen gehad. Je kunt in elke taal een injectiebug schrijven.

Wat verandert, is waar het risico zit. In een TypeScript-app is het geheugenonveilige deel de JavaScript-engine zelf: V8, die in miljarden browsers draait en dag en nacht wordt gefuzzd en aangevallen door een paar van de beste securityteams ter wereld. Je applicatiecode, en elke plugin, kan geen geheugen beschadigen of een losse pointer achterlaten voor het volgende verzoek. In PHP zit dat risico in een engine en een berg C-extensies die de levenscyclus van een verzoek elke keer precies goed moeten afhandelen.

Voor het web waarvoor het is gebouwd, heeft PHP het geweldig gedaan, en een groot deel van het web draait er nog steeds op. Maar voor een nieuw project in 2026 vinden we niet dat het nog de standaardkeuze moet zijn. Een geheugenveilige taal met een echt typesysteem, één taal voor server en browser, en een runtime die niet voor elk verzoek een frisse start hoeft na te bootsen, is gewoon een beter fundament.

Draai je PHP, patch dan vandaag. Als je je volgende site plant, kijk dan eens naar de stack eronder. We zouden het leuk vinden als je naar Justflows kijkt.