PHP: negenentwintig jaar de deur open laten staan

PHP2Shell, deze week

Op 21 oktober 2026 bracht het PHP-project vier releases tegelijk uit, 8.5.12, 8.4.27, 8.3.36 en 8.2.35, om twee kritieke fouten in de interpreter zelf te dichten¹. Niet in WordPress. Niet in een plugin. In PHP.

Beide krijgen 9,2 op CVSS 4.0. Beide maken remote code execution mogelijk zonder login. De onderzoekers die ze vonden zeggen het bereik zonder omwegen: “Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4.”²

De eigen advisory van het PHP-project zegt de rest:

En het werd al gebruikt voordat iemand het te horen kreeg. Het honeypotnetwerk van Amazon registreerde een poging op 17 oktober, vier dagen voor de bekendmaking³. watchTowr zag het op de 21e in het wild, en werkende proofs of concept waren binnen enkele uren na de patch openbaar⁴.

Beide bugs zijn geheugenveiligheidsbugs. De ene zit in hoe de interpreter opruimt nadat het geheugen op is. De andere is een use-after-free: geheugen van het ene request wordt vrijgegeven en daarna opnieuw gelezen, en het volgende request op dezelfde worker kan het zien⁵⁶. Onthoud die tweede. Hij komt later terug.

Niets hiervan is nieuw. Daar gaat deze post over. PHP2Shell is geen ongeluk dat een zorgvuldige taal overkwam. Het is de nieuwste bladzijde in een dossier van bijna dertig jaar, en elk getal erin is openbaar.

Eén proces houdt alles vast

Van november 2014 tot april 2017 was ik third-line Linux-engineer op het cloud- en hostingplatform van Pulsant. Een deel van dat werk was het inrichten van PHP-FPM-omgevingen voor e-commerceklanten en die afstellen op snelheid.

Inbraken via PHP waren gewoon. Niet af en toe. Gewoon. En ze kwamen neer op twee oorzaken: slechte inrichting, en geen scheiding tussen de front end en de back end.

De taal maakt die tweede de standaard. Een typische PHP-site is één proces. De paginatemplate, de bedrijfslogica en de SQL zitten allemaal in dezelfde request handler, vaak in hetzelfde bestand. Dat proces draait als één gebruiker van het besturingssysteem. Het kan het databasewachtwoord lezen, want dat wachtwoord staat in een bestand naast de code. En het kan meestal naar zijn eigen webroot schrijven, want zo werken uploads en updates.

Dat is niet mijn mening over hoe PHP wordt ingericht. Het is wat PHP en WordPress zelf documenteren.

Lees die laatste rij nog eens. De leverancier vertelt je hoe least privilege eruit zou zien, en vertelt je daarna het niet te doen, omdat updates het schema veranderen.

Vergelijk de gesplitste versie. De front end rendert pagina’s en heeft geen geheimen. De back end is een aparte service met een eigen gebruiker, een smalle API en geen schrijfrechten op zijn eigen code. Het database-account kan wat de back end nodig heeft en verder niets. De richtlijn van OWASP zegt hetzelfde in eigen woorden: “The application’s backend database should be isolated from other servers”, op “a dedicated internal network segment”¹². De eigen handleiding van PHP zegt dat applicaties “should never connect to the database as its owner or a superuser”¹³.

Niets daarvan is exotisch. Zo ziet een fatsoenlijk proces eruit. Waarom het hier telt is eenvoudig. In het gesplitste model levert een bug in de front end een aanvaller een front end op. In het gebruikelijke PHP-model levert een bug waar dan ook de templates, de code, de credentials en de data op, in één keer.

PHP-FPM helpt, en de installatiegids van PHP noemt het nu de aanbevolen manier om PHP onder Apache te draaien⁸. De pools kunnen workers starten “with different uid/gid/chroot/environment”¹⁴. Maar een pool per site is nog steeds één site per proces, met alles wat die site heeft. Het is een betere muur tussen klanten. Het is geen muur binnen de applicatie.

Houd dat beeld vast bij elke sectie hieronder. Elke bug in het dossier komt op dat proces terecht.

Negenentwintig jaar CVE’s

De National Vulnerability Database zet elke CVE tegen de PHP-interpreter onder één productidentificatie, cpe:2.3:a:php:php. Vraag het, en het antwoord is 757¹⁵.

Dat aantal is alleen de interpreter. Geen WordPress, geen Drupal, geen plugins, geen frameworks. Alleen het programma dat je PHP draait.

Twee pieken springen eruit. De eerste is maart 2007, toen een voormalig lid van het PHP-securityteam de Month of PHP Bugs hield en fouten in de Zend Engine, de PHP-kern en de extensies “on a day by day basis” openbaar maakte¹⁶. Hij had het PHP Security Response Team opgericht, was eruit gestapt, en zei waarom: “I dislike the ways bugs are handled”¹⁷. Als de oprichter van het securityteam van een project vertrekt en elke dag een bug publiceert, weet je hoe het er van binnen aan toe ging.

De tweede piek is 2016: 120 CVE’s, 65 daarvan geheugencorruptie. Daarover hieronder meer.

Het geheugencijfer is een ondergrens, geen schatting. NVD geeft een flink aantal oudere bugs het label “Other” in plaats van een type zwakte, waaronder een paar van de use-after-frees in de volgende sectie. Het echte cijfer ligt hoger. Ik gebruik het cijfer dat ik kan laten zien.

De engine is in C geschreven

Hier moet het argument over geheugenveiligheid zorgvuldig worden gemaakt, want een PHP-ontwikkelaar wijst er terecht op dat zijn code nooit malloc aanroept. PHP-scripts beheren geen geheugen met de hand. Je kunt in PHP geen buffer overflow schrijven zoals in C.

Dat hoeft ook niet. De interpreter die je script draait is in C geschreven, en de extensies ook. Elke byte onvertrouwde invoer die je site ontvangt, elke header, elke upload, elk formulierveld, elke cookie, wordt door die C geparsed voordat jouw code hem ziet. Als die C fout is, maakt je zorgvuldige PHP niet uit. PHP2Shell bewees het: de advisory zegt dat de aanval kan afgaan “before any application code runs”¹.

Het dossier laat zien wat die C fout heeft gedaan:

Dat zijn de klassen die de veiligheidsdiensten bedoelen als ze het over geheugenveiligheid hebben. In november 2022 adviseerde de NSA organisaties “to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible”¹⁸. In december 2023 plakte CISA er een getal op, met het Britse National Cyber Security Centre onder de medeauteurs: “two-thirds of reported vulnerabilities in memory unsafe programming languages still relate to memory issues”¹⁹.

Geen van beide documenten noemt PHP. Dat hoeft ook niet. Ze noemen de taal waarvan PHP gebouwd is.

Het ergste herhaalde voorbeeld is unserialize(), de functie die een opgeslagen string weer in PHP-objecten omzet. Die heeft dezelfde klasse bug, op dezelfde plek, meer dan eens gehad:

De PHP-handleiding weet het. De pagina van de functie draagt de waarschuwing: “Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes.”²³ Dat is een taal die je vertelt dat een van zijn eigen ingebouwde functies niet veilig is voor precies datgene waar de meeste webcode de hele dag mee werkt.

Dan is er PHP-FPM, de procesmanager die de installatiegids van PHP zelf aanraadt boven mod_php. In oktober 2019 liet CVE-2019-11043 zien dat “in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers … opening the possibility of remote code execution”²⁴. De configuratie in kwestie was een gangbare nginx-opstelling. Het werd op 24 oktober 2019 opgelost²⁵. CISA zette het later in zijn catalogus van kwetsbaarheden waarvan misbruik bekend is, gemarkeerd als gebruikt in ransomwarecampagnes²⁶.

De PHP Foundation heeft wel een echte securityaudit van de broncode van de interpreter laten doen, en dat verdient lof. De resultaten, gepubliceerd op 10 april 2025, vonden 27 problemen, 17 daarvan met gevolgen voor de veiligheid²⁷. Dat is goede praktijk en het zou normaal moeten zijn. Het zijn ook 17 extra, in een audit van een codebase die al bijna drie decennia aan openbare bugrapporten achter de rug had.

De taal maakte dezelfde fouten een verdieping hoger

De C is één laag. De taal erbovenop maakte in zijn ontwerp dezelfde soort fout: invoer vertrouwen die het niet had mogen vertrouwen, en er jaren over doen om daarmee te stoppen.

register_globals verdient een eigen regel. Jarenlang werd elke parameter in het request, ?admin=1 bijvoorbeeld, een variabele in je script, en als je code $admin controleerde voordat hij was gezet, had de aanvaller hem al voor je gezet. De PHP-handleiding noemde het uitzetten ervan zelf “the most controversial change in PHP”²⁹. Tien jaar van standaard uit tot weg. Zo lang duldde het project een feature waarvan het wist dat hij gevaarlijk was, omdat verwijderen sites zou breken.

Het phar-geval is hetzelfde patroon een laag lager. In 2018 liet Sam Thomas op Black Hat zien dat gewone bestandsoperaties op een phar://-pad door de aanvaller aangeleverde metadata zouden unserialiseren, waarmee het probleem van unserialize() bij functies terechtkwam die niemand als gevaarlijk zag³⁶. PHP 8.0 stopte daar eind 2020 mee als automatisme, “to fix potential security vulnerabilities due to object instantiation, autoloading, etc.”³⁴.

Dan type juggling. De == van PHP zet typen om voordat hij vergelijkt, dus strings die op getallen lijken worden als getallen vergeleken. De RFC die er in PHP 8.0 een deel van oploste zei het zonder omhaal: “This results in many surprising comparison results, the most notable of which is that 0 == ‘foobar’ returns true.”³⁵

Die fix was echt. Hij was ook gedeeltelijk. Hier is dezelfde controle in de officiële containers php:7.4-cli en php:8.5-cli, de tweede is 8.5.12, de release die deze week voor PHP2Shell is gepatcht, met de twee uitkomsten naast elkaar:

$ php -r 'var_dump(0 == "foobar");'
bool(true)            # 7.4.33
bool(false)           # 8.5.12

$ php -r 'var_dump("0e462097431906509019562988736854" == "0e830400451993494058024219903391");'
bool(true)            # 7.4.33
bool(true)            # 8.5.12

Twee verschillende strings, gelijk. Beide beginnen met 0e gevolgd door cijfers, dus PHP leest beide als nul maal tien tot een of andere macht, en nul is gelijk aan nul. Beide hebben de vorm van een MD5-hash. Vergelijk een opgeslagen wachtwoordhash met == in plaats van === of hash_equals(), en elke invoer waarvan de hash toevallig zo begint, past. Het is al jaren gedocumenteerd. Het werkt nog steeds in de nieuwste release.

Dat is de taal in één voorbeeld. Een fix die erin ging, de helft van het probleem achtergelaten, en de veilige versie vraagt dat je weet dat er een andere operator bestaat.

Een shell, bijna elk jaar

De vraag die je van elk platform moet stellen is niet hoeveel bugs het heeft gehad. Het is hoe vaak iemand de hele server kon overnemen zonder wachtwoord en zonder dat iemand ergens op klikte.

NVD geeft elke CVE een score. Filter de 757 op de score die precies dat betekent, aanval via het netwerk, geen rechten, geen gebruikersinteractie, hoge impact op vertrouwelijkheid en integriteit, en je houdt er 172 over¹⁵.

172, verspreid over 23 van de 28 jaren die überhaupt een PHP-CVE hebben. Maar vijf zijn leeg. 2016 alleen heeft er 65.

Een ernstscore is een beoordeling, geen inbraak. Dus de tweede helft van het beeld is de Known Exploited Vulnerabilities-catalogus van CISA, die alleen fouten opneemt waarvan misbruik in het wild bevestigd is²⁶. Van de 1.754 vermeldingen op 21 oktober 2026 zijn er 81 PHP zelf of applicaties die in PHP geschreven zijn:

2026 is nu al het slechtste jaar voor PHP in de catalogus, en PHP2Shell staat er nog niet in. Drie van dit jaar zitten in WordPress-core zelf: twee toegevoegd op 21 juli, en een remote file inclusion op 25 september.

En de catalogus telt PHP flink te laag. Hij is opgezet rond Amerikaanse federale systemen en vereist een CVE plus bevestigd misbruik. Er staan 3 WordPress-plugins in. Het pluginecosysteem van WordPress registreerde in 2025 alleen al 11.334 kwetsbaarheden³⁷. De 81 is het deel dat iemand officieel heeft opgeschreven.

WordPress vermenigvuldigt het

WordPress is 39,6% van alle websites, en 58,3% van de sites waarvan het contentmanagementsysteem te herkennen is³⁸. PHP is de server-side taal van 69,3% van de sites waar dat te zien is³⁹. Dus wat het dossier van PHP ook is, WordPress brengt het naar een heel groot deel van het web, en voegt er dan zijn eigen dossier aan toe.

Core is niet het grootste probleem. De plugins zijn het.

Wordfence telde met een eigen database 8.223 voor 2024, een stijging van 68% ten opzichte van 2023, en vond “Roughly 35% of the vulnerabilities disclosed in 2024 remain unpatched in 2025”⁴¹. Andere databases, andere totalen, dezelfde vorm.

Sta even stil bij de cijfers van 2025. Bijna de helft van de kwetsbaarheden had geen fix van de ontwikkelaar op het moment dat ze openbaar werden. En voor de bugs waar aanvallers echt op afgaan is de mediaan tussen bekendmaking en massaal misbruik vijf uur. De meeste mensen controleren hun plugin-updates niet elke vijf uur. De meeste mensen kunnen dat niet.

Het pluginmodel is de vermenigvuldiger. De veiligheid van een site hangt af van de minst zorgvuldige auteur van alles wat erop geïnstalleerd is, en Wordfence vond dat “over one third of developers are unreachable or unresponsive” als ze over een fout werden ingelicht⁴¹. Patchstack telde 1.614 plugins en thema’s die in 2024 uit de repository zijn gehaald vanwege securityproblemen die niemand oploste⁴⁰. En door het model met één proces draait elke plugin met de volledige rechten van de site.

De incidenten vormen een lange lijst. Dit zijn de gevallen met primaire bronnen erachter:

Met de rij van 2016 ben ik voorzichtig geweest. Wordfence liet zien dat de site van het kantoor een sliderversie draaide die kinderlijk eenvoudig te misbruiken was. Het liet niet zien dat de documenten zo werden weggehaald, en ik ga niet meer beweren dan het bewijs draagt.

Hoe de malware blijft

Binnenkomen is de helft. Binnenblijven is de andere helft, en PHP maakt dat makkelijk om een reden die rechtstreeks teruggaat op het beeld van het ene proces.

De interpreter draait elk .php-bestand dat hij kan bereiken. De webroot is meestal schrijfbaar voor dezelfde gebruiker die de code draait. Dus zodra een aanvaller op welke manier ook een bestand kan schrijven, een uploadformulier, een pluginbug, een bestandsbeheerder, kan hij een script neerzetten dat draait elke keer dat iemand het opvraagt. Dat is een webshell: een klein bestand, in je site, dat commando’s aanneemt.

CISA zegt al jaren in welke talen die meestal geschreven zijn: “The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP.”⁵⁰ De gezamenlijke richtlijn van de NSA en het Australian Signals Directorate noemt ze “a long-standing, pervasive threat that continues to evade many security tools”, en moeilijk te ontdekken omdat ze “easily modified by attackers and often employ encryption, encoding, and obfuscation”⁵¹.

De opschoningscijfers laten zien hoe vaak ze er zijn:

Dus in het meest recente opschoningsjaar had de helft van de gehackte sites nog een weg terug op de schijf staan. Zet de database terug, patch de plugin, en de aanvaller loopt weer binnen via het bestand dat hij achterliet.

Hier bestaat geen slimme oplossing voor. Er is de saaie, fatsoenlijke, en de NSA heeft hem opgeschreven: “web applications should not have permission to write directly to a web accessible directory or modify web accessible code”⁵¹. Die ene zin is het model met gescheiden lagen van het begin van deze post, uitgesproken door een inlichtingendienst.

De hardeninggids van WordPress, voor wat die waard is, noemt nergens het tegenhouden van PHP-uitvoering in de uploadmap¹¹. Daarom citeert de tabel OWASP en de NSA.

Kijk wat er niet in die tabel staat. De eigen hardeninginstellingen van PHP. De handleiding is daar eerlijk over. disable_functions “can be circumvented and should not be considered a sufficient security measure for shared hosting environments”, en open_basedir “is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed”⁵⁵. Als de eigen documentatie van een taal je vertelt dat de veiligheidsknoppen geen veiligheidsgrenzen zijn, geloof het dan. Daarom moet de grens van buiten het proces komen.

Zelfs bij php.net werd ingebroken

Als de eigen infrastructuur van het project degelijk was, zou je kunnen stellen dat het dossier neerkomt op een moeilijk probleem dat goed wordt aangepakt. Er is twee keer ingebroken.

Die van 2021 is degene die telt. Iemand duwde code in de eigen broncodeboom van de taal, en deed zich daarbij voor als de mensen die hem onderhouden. Het werd ontdekt. Het antwoord van het project is het citeren waard, omdat het het juiste is, recht voor zijn raap: “maintaining our own git infrastructure is an unnecessary security risk”, en de repositories verhuisden naar GitHub⁵⁷.

Eer wie eer toekomt: dat was een goede beslissing, snel genomen en in het openbaar uitgelegd. Maar kijk wat het toegeeft. Jarenlang stond de canonieke broncode van een taal die het grootste deel van het web draait op zelf beheerde infrastructuur waarvan het project zelf vond dat het een risico was dat het niet hoorde te dragen.

De helft van het web draait een versie die niemand patcht

Alles hierboven gaat ervan uit dat de site up-to-date is. Heel veel zijn dat niet.

php.net ondersteunt op dit moment vier takken. 8.2 krijgt alleen nog securityfixes, tot 31 december 2026. 8.3, 8.4 en 8.5 zijn de rest⁵⁸. Alles wat ouder is, is end of life: 8.1 sinds 31 december 2025, 8.0 sinds november 2023, 7.4 sinds november 2022⁵⁹.

Nu het gemeten aandeel van wat er echt draait:

PHP 7.4 alleen, al bijna vier jaar zonder support, is ongeveer een vijfde van alle PHP-sites die hun versie laten zien. De vereistenpagina van WordPress zelf vraagt om PHP 8.3, en zegt dan dat WordPress “also works with PHP 7.4+”, terwijl het opmerkt dat die versies “have reached their official End Of Life”⁶³. Een leverancier die nog op een dode versie draait, is een leverancier die heeft besloten je niet te laten overstappen.

Twee eerlijke kanttekeningen. W3Techs ziet de versie alleen op sites die hem tonen. En sommige Linux-distributies backporten fixes in oude PHP-builds, dus “niet ondersteund door php.net” is niet altijd “niet gepatcht”. Maar PHP2Shell is daar de test van. Het project heeft deze keer wel bronpatches voor 7.4, 8.0 en 8.1 gepubliceerd¹, en iemand moet ze nog steeds bouwen, uitleveren en installeren. Op een shared host met een versie waar niemand eigenaar van is, is die iemand niemand.

Ik ben ermee gestopt. Jij zou ook moeten overwegen te vertrekken.

Ik schreef vroeger PHP. Na Pulsant ben ik met de taal gestopt, vanwege de problemen die hij veroorzaakte en het werk dat die problemen opleverden. Niet één slecht incident. Jaren van dezelfde twee oorzaken, site na site, en het opruimwerk dat terechtkwam bij wie er toevallig dienst had.

Dus ik zeg het zonder omwegen. Als de keuze aan jou is, overweeg dan te vertrekken. Er zijn hier nu betere middelen voor, en Go is degene waar ik je als eerste op zou wijzen.

Niet omdat het in de mode is. Omdat het standaard het meeste weghaalt van wat deze post heeft zitten tellen:

Gecompileerd telt twee keer. Het is sneller: Go-programma’s “are compiled ahead of time to native machine code”, zonder virtuele machine eronder, en een van de uitgesproken ontwerpdoelen is “to approach the performance of C for comparable programs”⁶⁶. En het is veiliger, want er zit geen interpreter in het requestpad die tijdens het draaien code parset, en geen C-engine met 757 CVE’s tussen het netwerk en je programma. PHP doet, aan zichzelf overgelaten, het omgekeerde. Zonder OPcache laadt, parset en compileert het elk script bij elk request, nodeloos, duizenden keren per minuut op een drukke site. OPcache bestaat om dat te stoppen, “removing the need for PHP to load and parse scripts on each request”⁶⁴. Maar het staat niet standaard aan. Tot en met 8.4 is het een aparte gedeelde extensie die iemand met zend_extension moet laden en configureren. Pas PHP 8.5 bouwt het in: “The Opcache extension is now always built into the PHP binary and is always loaded”⁷⁰. De eigen RFC van het project voor die wijziging zegt “running PHP in production without OPcache is generally considered a mistake”⁷¹. W3Techs zet 8.5 op 4,5% van de PHP 8-sites⁶⁰, dus voor bijna alles wat vandaag draait is de oplossing voor het compileren van elk script bij elk request nog steeds een add-on die iemand moest onthouden. En zelfs geladen is wat het cachet bytecode die de C-interpreter moet uitvoeren. Go doet het compileren één keer, voordat het programma ooit een request ziet.

Sneller en veiliger, op voorwaarde dat het fatsoenlijk is geprogrammeerd. Die laatste bijzin is het hele onderwerp van de volgende alinea’s.

Het templatepakket van Go zet zijn ontwerp in één regel neer: het genereert “HTML output safe against code injection”, en “The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts.”⁶⁷ De databasegids is net zo duidelijk: “You can avoid an SQL injection risk by providing SQL parameter values as sql package function arguments.”⁶⁸ Dat zijn de standaarden. In PHP zijn het dingen waarvan je moet weten dat je ze moet gaan halen.

De rij die ik zou onderstrepen is het gedropte bestand. De helft van de gehackte sites die Sucuri in 2023 opschoonde had nog een backdoor op schijf⁵³, en dat werkt alleen omdat de interpreter elk script draait dat hij kan bereiken. Een gecompileerde service gaat niet op zoek naar scripts. Er is helemaal niets waar een gedropt bestand op kan inprikken.

Nu het eerlijke deel, want een taal is geen geneesmiddel. Go is geheugenveiliger, niet volmaakt. Het eigen geheugenmodel zegt dat een data race op een slice, een map of een interfacewaarde “can in turn lead to arbitrary memory corruption”⁷², en Go levert het gereedschap om die te vangen. Bouw met -race, of draai go test -race, en de binary wordt gecompileerd met een detector die een race meldt op het moment dat hij gebeurt. Hij vangt races tijdens het draaien in plaats van bij het compileren, en “can’t find races in code paths that are not executed”, dus hij hoort in elke testrun en onder een realistische belasting⁷³. PHP heeft niets vergelijkbaars. Het geheugen van het ene request weghouden van het volgende wordt volledig aan de engine overgelaten, en PHP2Shell is die engine die het fout doet: geheugen vrijgegeven door het ene request, gelezen door het volgende op dezelfde worker⁶. Daarbuiten houdt Go de klasse geheugencorruptie tegen die deze post heeft zitten tellen, en maakt het de veilige weg de makkelijke weg voor nog twee. Het houdt geen kapotte logincontrole tegen, geen ontbrekende rechtencontrole en geen query die aan elkaar is geplakt uit strings als je daar per se op staat. Go publiceert ook zijn eigen security-advisories, via zijn kwetsbaarhedendatabase⁶⁹. En een Go-service die als root draait vanuit een schrijfbare map is nog steeds slecht ingericht.

Wat het verandert is de standaard. De standaard van PHP is één proces dat alles vasthoudt. De standaard van Go is een programma dat één taak doet, en dat is de splitsing van het begin van deze post met het meeste werk al gedaan. Als Go niet bij je team past, is Rust de andere uitweg. Beide worden vooraf naar native machinecode gecompileerd. Rust draait “with no runtime or garbage collector”⁷⁴, en de compiler en runtime van Go zijn sinds Go 1.5 “implemented in Go and assembler, without C”⁷⁵.

C# en Java staan ook op de lijst van geheugenveilige talen van de diensten¹⁸, maar ze zijn geen uitweg uit het probleem waar deze post mee begon. Allebei draaien ze op een virtuele machine die in C++ is geschreven. HotSpot van OpenJDK beslaat “around 3000 C/C++ header and source files, comprising more than 1.2 million lines of code”⁷⁶, en de garbage collector en JIT-compiler van .NET zijn C++-broncode in de CoreCLR-boom⁷⁷. Dat is dezelfde vorm als bij PHP: een grote native engine tussen het netwerk en jouw code. En Java laadt bewust code in een draaiende applicatie. De standaard-classloader is er “to load classes and resources from a search path of URLs referring to both JAR files and directories”⁷⁸, en Log4Shell maakte daar remote code execution van: wie een logbericht in handen had, “can execute arbitrary code loaded from LDAP servers”⁷⁹. Het lek ging regelrecht de catalogus van CISA in²⁶. Het is dezelfde deur als bij PHP, met meer ceremonie ervoor.

Kies dus Go of Rust. Verhuis eerst de back end, één endpoint tegelijk, en laat de PHP-front end niets houden dat het stelen waard is totdat die ook weg kan.

Als je het nog steeds zo inricht, kun je jezelf dan een professional noemen?

Er staat genoeg bewijs hierboven om dit niet langer een mening te laten zijn. Dus hier is de vraag, recht op de man af. Als je PHP nog steeds inricht als één proces dat de code, de credentials en een schrijfbare webroot vasthoudt, kun je jezelf dan een professional noemen?

Het hangt ervan af welke van drie mensen je bent. En weten welke is niet iets wat je overkomt. Ervoor zorgen dat je het weet, is het werk.

Je hebt een echte beperking, en je hebt hem opgeschreven. Een product waar het bedrijf van afhangt bestaat alleen in PHP. Een migratie is begroot en staat in het budget van volgend jaar. Prima. Dat is professioneel, op voorwaarde dat de reden op papier staat met een datum ernaast, de runtimegebruiker de code niet kan schrijven, uploads niet kunnen uitvoeren, het database-account is ingeperkt, en je deze week PHP2Shell hebt gepatcht. Je draait bewust een bekend risico, met de muren die je eromheen kunt zetten.

Niemand heeft het je ooit verteld. Niemand liet je het dossier zien, en de tutorial waarvan je het leerde zette alles in één map. Dat is een gat, en iedereen heeft gaten. Het houdt op een gat te zijn op het moment dat je tot hier hebt gelezen.

Je weet het, en je bouwt het toch. Je hebt de cijfers gezien, of genoeg ervan. Je weet dat het databasewachtwoord in de webroot staat en dat de webroot schrijfbaar is. Je richt het zo in omdat het sneller is, omdat de klant niet voor beter wil betalen, en omdat niemand je heeft laten verantwoorden waarom. Op dat geval is deze vraag gericht. Het falen is niet het gat in je kennis. Het is over een gat heen bouwen dat je al hebt gezien en nooit bent teruggegaan om te dichten.

Iedereen heeft daar ooit gestaan. Er uit eigen keuze blijven staan is het deel dat niet te verdedigen is.

De deur stond altijd open

Wat me opvalt als ik dit dossier lees, is niet dat PHP bugs heeft. Elke taal heeft die. Het is hoe weinig ervan ooit een verrassing was.

Het project wist in 2002 dat register_globals gevaarlijk was en haalde het in 2012 weg. De handleiding zegt je unserialize() niet te vertrouwen, disable_functions niet te vertrouwen, open_basedir niet te vertrouwen. De eigen documentatie zegt dat een script onder mod_php zonder wachtwoord bij de database kan. De diensten zeggen al jaren dat de taal waarvan het gebouwd is de plek is waar twee derde van de geheugenbugs vandaan komt. Elke waarschuwing staat er, op schrift, van de mensen die het zouden moeten weten.

En het bleef toch winnen, omdat het goedkoop was. Goedkoop om te hosten, goedkoop om te leren, goedkoop om te verkopen aan een klant die vrijdag een website wilde. Eén map, één proces, één wachtwoord in een bestand, en een site die werkte. Waarvoor het geprijsd stond was een shared hostingpakket. Wat het kostte stond nooit op de factuur: het opruimwerk, de backdoors die op schijf achterbleven, de kaartnummers van klanten die door kwaadaardige PHP werden weggehaald, het venster van vijf uur tussen bekendmaking en aanval.

Dat is het deel waar ik geen geduld voor heb. Niet de bugs. De beslissing, keer op keer genomen door mensen die beter wisten, dat de goedkope manier goed genoeg was omdat niemand controleerde. Een standaard is wat je aanhoudt als niemand controleert. De splitsing tussen front end en back end, de alleen-lezen code, het ingeperkte database-account: niets daarvan is nieuw, niets daarvan is duur, en alles samen had een flink deel van de incidenten hierboven veranderd in niets wat het opschrijven waard was.

PHP2Shell is niet het einde van dit dossier. Het is alleen de vermelding van deze week. De taal zal het patchen, de hosts zullen de update uiteindelijk uitrollen, en het versieaandeel schuift omhoog zoals altijd, langzaam. Wat bepaalt of de volgende jou iets kost, is niet PHP. Het is of je de muren hebt gebouwd die het je nooit gaf, of bent overgestapt naar iets waar ze bij zitten.