Beheerders van websites en applicaties die gebruikmaken van PHP moeten rekening houden met twee ernstige beveiligingskwetsbaarheden. De fouten zouden onder bepaalde omstandigheden kunnen leiden tot het uitvoeren van schadelijke code op een server, zonder dat een aanvaller daarvoor eerst toegang tot het systeem hoeft te verkrijgen. Beveiligingsonderzoekers melden dat er al een proof of concept circuleert. Zolang de officiële technische details en de definitieve beveiligingsupdates niet volledig beschikbaar zijn, is echter nog niet duidelijk onder welke voorwaarden de kwetsbaarheden daadwerkelijk kunnen worden misbruikt.

De ontwikkelaars van PHP hebben een beveiligingsrelease aangekondigd om twee ernstige kwetsbaarheden te verhelpen. Beide fouten zouden een CVSS-score van 9,2 hebben gekregen. Daarmee vallen ze in de categorie kritiek, waarin kwetsbaarheden worden ingedeeld die onder bepaalde omstandigheden zeer ernstige gevolgen kunnen hebben.

PHP is een veelgebruikte programmeertaal voor websites, webapplicaties en serversystemen. Het platform vormt onder meer de technische basis van verschillende contentmanagementsystemen (CMS'en), waaronder WordPress en Joomla. Ook tal van webwinkels, bedrijfsapplicaties en op maat gemaakte websites maken gebruik van PHP.

Een kwetsbaarheid in deze programmeertaal kan daardoor gevolgen hebben voor een breed scala aan systemen. Dat betekent overigens niet automatisch dat iedere website die PHP gebruikt kwetsbaar is. Het daadwerkelijke risico hangt onder meer af van de gebruikte PHP-versie, de configuratie van de server, de betrokken software en de manier waarop de kwetsbare functionaliteit wordt aangeroepen.

Twee kwetsbaarheden met een hoge ernstscore

De twee gemelde beveiligingsproblemen zijn bekend onder de identificatienummers CVE-2026-109618 en CVE-2026-109619. Deze nummers worden gebruikt om afzonderlijke beveiligingskwetsbaarheden eenduidig te registreren en informatie over de risico's, getroffen software en beschikbare oplossingen bij elkaar te brengen.

Volgens de beschikbare berichtgeving zouden beide kwetsbaarheden een CVSS-score van 9,2 op een schaal van 0 tot 10 hebben. Een dergelijke score duidt op een zeer ernstig beveiligingsrisico. De precieze gevolgen zijn afhankelijk van de technische eigenschappen van de fouten en de omstandigheden waaronder een aanvaller ze kan benutten.

Remote code execution (RCE), oftewel het op afstand uitvoeren van code, is een van de meest risicovolle categorieën beveiligingsproblemen. Bij een succesvolle aanval kan een aanvaller ervoor zorgen dat een systeem opdrachten uitvoert die niet door de beheerder zijn bedoeld of toegestaan.

De gevolgen kunnen aanzienlijk zijn. Afhankelijk van de rechten waarmee het getroffen proces draait, kan een aanvaller mogelijk gegevens uitlezen, bestanden aanpassen, kwaadaardige software plaatsen of verdere toegang tot het systeem proberen te verkrijgen. In ernstigere scenario's kan een gecompromitteerde server worden gebruikt als opstap naar andere systemen binnen dezelfde infrastructuur.

Het is daarbij belangrijk onderscheid te maken tussen de ernst van een kwetsbaarheid en de mate waarin deze in de praktijk kan worden misbruikt. Een hoge CVSS-score zegt iets over het potentiële risico, maar bewijst op zichzelf niet dat iedere installatie zonder aanvullende voorwaarden kwetsbaar is.

Technische details nog niet volledig bekend

De PHP-ontwikkelaars hebben aangekondigd later op woensdag 21 oktober 2026 meer informatie bekend te maken over de beveiligingsproblemen en de bijbehorende updates. De publicatie zou aanvankelijk op donderdag plaatsvinden, maar volgens de berichtgeving is het tijdstip vervroegd nadat informatie over de aangekondigde reparaties eerder naar buiten was gekomen.

Door die voortijdige verspreiding is er onrust ontstaan onder beveiligingsonderzoekers en beheerders. Wanneer informatie over een kwetsbaarheid bekend wordt voordat beheerders de gelegenheid hebben gehad hun systemen bij te werken, kan de periode waarin systemen mogelijk onbeschermd zijn extra risicovol worden.

Op het moment waarop deze berichtgeving werd opgesteld, waren de volledige technische details en de definitieve reikwijdte van de kwetsbaarheden nog niet onafhankelijk vastgesteld. Daardoor is voorzichtigheid geboden bij uitspraken over de precieze oorzaak, de vereiste aanvalsstappen en de versies die daadwerkelijk getroffen zijn.

Wel wordt gemeld dat beveiligingsonderzoekers van Watchtowr de kwetsbaarheden hebben gekoppeld aan de identificatienummers CVE-2026-109618 en CVE-2026-109619. Ook zou er al een proof of concept beschikbaar zijn waarmee de vermeende aanval wordt gedemonstreerd.

Proof of concept laat mogelijk misbruik zien

Een proof of concept meestal afgekort tot PoC, is een demonstratie waarmee onderzoekers aantonen dat een beveiligingsprobleem onder bepaalde omstandigheden daadwerkelijk kan worden benut. Zo'n demonstratie kan bestaan uit een klein script, een reeks netwerkverzoeken of een gecontroleerde testomgeving waarin het effect van een kwetsbaarheid zichtbaar wordt.

Volgens de beschikbare berichtgeving circuleert er een videodemonstratie van een aanval die de naam PHP2Shell gebruikt. Daarin zou een relatief eenvoudig Python-script worden ingezet om bepaalde beveiligingscontroles van webapplicaties te omzeilen.

De demonstratie zou onder meer laten zien hoe de aanval mogelijk invloed kan hebben op de authenticatie van websites die gebruikmaken van bekende CMS-platforms, zoals WordPress en Joomla. Daarnaast wordt melding gemaakt van het achterhalen van een wachtwoord binnen een applicatie die gebruikmaakt van het Symfony-framework.

Deze claims moeten zorgvuldig worden geïnterpreteerd. Een demonstratie in een specifieke testomgeving bewijst niet automatisch dat alle installaties van WordPress, Joomla of Symfony kwetsbaar zijn. Het kan bijvoorbeeld gaan om een specifieke combinatie van softwareversies, configuratie-instellingen of aanvullende componenten.

Ook is het belangrijk onderscheid te maken tussen het omzeilen van een inlogcontrole en het uitvoeren van code op de server. Dit zijn verschillende beveiligingsproblemen, hoewel ze in een aanvalsketen met elkaar verbonden kunnen zijn. Een aanvaller die een authenticatiecontrole kan passeren, heeft niet noodzakelijkerwijs ook volledige controle over de server. Omgekeerd kan een succesvolle aanval op de server ernstige gevolgen hebben zonder dat de aanvaller eerst op de gebruikelijke manier hoeft in te loggen.

De precieze relatie tussen de gedemonstreerde effecten en de twee gemelde PHP-kwetsbaarheden moet daarom blijken uit de officiële technische toelichting en verdere onafhankelijke analyse.

Wat betekent PHP2Shell?

De naam PHP2Shell wordt in de gemelde proof of concept gebruikt voor de aanvalstechniek. De naam verwijst naar het mogelijke verkrijgen van toegang tot een opdrachtomgeving op een systeem waarop PHP draait.

Een shell is een omgeving waarin opdrachten aan een besturingssysteem kunnen worden gegeven. Wanneer een aanvaller via een kwetsbare webapplicatie opdrachten op de server kan laten uitvoeren, kan dat een ernstige inbreuk op de beveiliging betekenen.

Afhankelijk van de rechten van het getroffen proces kan zo'n aanval toegang geven tot onderdelen van de applicatieomgeving. Denk bijvoorbeeld aan configuratiebestanden, omgevingsvariabelen, tijdelijke bestanden of gegevens die nodig zijn om verbinding te maken met databases en andere interne diensten.

Dat betekent niet automatisch dat een aanvaller alle gegevens op de server kan bekijken of de volledige infrastructuur kan overnemen. De daadwerkelijke impact hangt onder meer af van de accountrechten van het PHP-proces, de isolatie van applicaties, de toegangsrechten van bestanden en de netwerkbeveiliging.

Toch is juist de mogelijkheid om code op afstand uit te voeren een reden om dergelijke kwetsbaarheden met hoge prioriteit te behandelen. Een aanvaller hoeft mogelijk geen legitiem account te hebben wanneer de kwetsbare functionaliteit vanaf het internet bereikbaar is en geen aanvullende beveiligingsmaatregelen de aanval tegenhouden.

Mogelijk een groot aantal PHP-installaties getroffen

Een van de belangrijkste vragen is welke versies van PHP kwetsbaar zijn. Volgens de beschikbare berichtgeving zouden de problemen aanwezig zijn in versies die teruggaan tot PHP 5.

Als dat voor beide kwetsbaarheden officieel wordt bevestigd, kan het aantal potentieel betrokken installaties aanzienlijk zijn. PHP 5 werd jarenlang op grote schaal gebruikt en is inmiddels verouderd. Ook oudere, niet meer ondersteunde PHP-versies kunnen nog actief zijn op websites en bedrijfsservers die niet regelmatig worden onderhouden.

Het is echter niet verantwoord om zonder de definitieve technische informatie te concluderen dat iedere PHP-versie sinds PHP 5 daadwerkelijk kwetsbaar is. De getroffen versiereeksen kunnen per kwetsbaarheid verschillen. Ook kan de aanwezigheid van een fout in de broncode niet betekenen dat de fout onder iedere configuratie op afstand bereikbaar of exploiteerbaar is.

Beheerders moeten daarom niet alleen vaststellen welke PHP-versie op een server is geïnstalleerd, maar ook nagaan welke applicaties die versie gebruiken, welke componenten actief zijn en of er uitzonderingen of aanvullende voorwaarden gelden.

Daarbij is het verstandig om verder te kijken dan alleen de hoofdwebsite. Een server kan meerdere websites, subdomeinen, API's, achtergrondprocessen en beheertoepassingen hosten. Ook oudere applicaties die niet dagelijks worden gebruikt, kunnen nog steeds een ingang voor aanvallers vormen.

Waarom WordPress, Joomla en Symfony aandacht verdienen

WordPress en Joomla zijn veelgebruikte contentmanagementsystemen waarmee websites kunnen worden gebouwd en beheerd. Symfony is een PHP-framework dat ontwikkelaars gebruiken om webapplicaties te bouwen.

Deze producten zijn niet hetzelfde als PHP zelf. PHP is de programmeertaal en runtime waarop veel van deze applicaties draaien. Een kwetsbaarheid in PHP kan daardoor verschillende applicaties beïnvloeden, maar dat maakt niet automatisch iedere applicatie die PHP gebruikt kwetsbaar.

Voor WordPress- en Joomla-beheerders is het belangrijk om te controleren of hun hostingomgeving een getroffen PHP-versie gebruikt en of er specifieke maatregelen nodig zijn om de kwetsbaarheid te verhelpen. Het bijwerken van alleen het CMS kan onvoldoende zijn wanneer het probleem in de onderliggende PHP-runtime zit.

Voor Symfony-applicaties geldt hetzelfde. Het is verstandig om zowel de PHP-versie als de gebruikte frameworkversie, afhankelijkheden en serverconfiguratie te controleren. Als de gemelde aanval inderdaad gevoelige gegevens uit een Symfony-applicatie kan achterhalen, moeten beheerders bovendien nagaan of wachtwoorden, tokens of andere geheimen mogelijk zijn blootgesteld.

Een wachtwoord dat uit een applicatie kan worden achterhaald, kan namelijk ook buiten die ene applicatie risico opleveren wanneer hetzelfde wachtwoord elders wordt hergebruikt. Daarom kan het na een bevestigde inbreuk noodzakelijk zijn om betrokken inloggegevens te vervangen en actieve sessies of tokens ongeldig te maken.

Wat moeten websitebeheerders nu doen?

Beheerders hoeven niet te wachten tot er daadwerkelijk misbruik is vastgesteld voordat zij voorbereidingen treffen. Wel moeten zij voorkomen dat ongeteste noodmaatregelen zelf nieuwe problemen veroorzaken.

De volgende stappen zijn verstandig.

1. Inventariseer alle PHP-installaties

Breng in kaart welke servers, websites, containers en applicaties PHP gebruiken. Noteer per omgeving de geïnstalleerde versie, het gebruikte besturingssysteem en de manier waarop PHP wordt uitgevoerd, bijvoorbeeld via PHP-FPM, een webservermodule of een container.

Controleer ook omgevingen die niet rechtstreeks vanaf het internet bereikbaar zijn. Interne applicaties kunnen alsnog risico lopen wanneer een aanvaller eerst toegang krijgt tot een ander systeem binnen het netwerk.

2. Controleer welke versies daadwerkelijk zijn getroffen

Raadpleeg de officiële beveiligingsaankondiging zodra de PHP-ontwikkelaars de technische details en getroffen versiereeksen publiceren. Ga niet uitsluitend af op de algemene melding dat oudere PHP-versies mogelijk kwetsbaar zijn.

Controleer daarnaast of de hostingprovider of leverancier van het besturingssysteem eigen beveiligingsupdates beschikbaar stelt. Sommige leveranciers leveren patches terug naar oudere softwaretakken zonder dat het versienummer op dezelfde manier verandert als bij een officiële upstreamrelease.

3. Bereid een snelle update voor

Zorg dat de procedure voor het installeren en testen van PHP-updates gereed is. Controleer of de gebruikte applicaties compatibel zijn met de gepatchte versie en of er een testomgeving beschikbaar is.

Bij een kritieke kwetsbaarheid kan een snelle update noodzakelijk zijn, maar de wijziging moet wel gecontroleerd worden uitgevoerd. Maak waar mogelijk een back-up, leg vast hoe de update wordt teruggedraaid als er ernstige problemen ontstaan en controleer na afloop of websites en achtergrondprocessen correct functioneren.

4. Beperk de blootstelling aan risico

Wanneer een patch nog niet beschikbaar is, kan het nodig zijn tijdelijk aanvullende maatregelen te nemen. Denk aan het beperken van de toegang tot beheerinterfaces, het uitschakelen van niet-noodzakelijke functionaliteit of het aanscherpen van netwerkregels.

Welke maatregel effectief is, hangt af van de technische oorzaak van de kwetsbaarheid. Een algemene firewallregel of een web application firewall (WAF) biedt geen gegarandeerde bescherming tegen iedere vorm van remote code execution. Tijdelijke maatregelen moeten daarom worden afgestemd op de officiële aanbevelingen zodra die beschikbaar zijn.

5. Controleer logbestanden en beveiligingsmeldingen

Onderzoek relevante webserverlogs, applicatielogs en systeemlogs op afwijkende verzoeken, onverwachte foutmeldingen, ongebruikelijke processen en andere signalen van mogelijk misbruik.

Let ook op wijzigingen aan bestanden, onverwachte beheerdersaccounts, nieuwe geplande taken en uitgaande netwerkverbindingen die niet bij het normale gedrag van de applicatie passen. De precieze indicatoren moeten waar mogelijk worden gebaseerd op informatie van de PHP-ontwikkelaars en betrouwbare beveiligingsonderzoekers.

Het ontbreken van verdachte logregels bewijst overigens niet dat een systeem niet is aangevallen. Logbestanden kunnen onvolledig zijn of door een aanvaller zijn aangepast.

6. Onderzoek mogelijke blootstelling van wachtwoorden en tokens

Als er aanwijzingen zijn dat een aanvaller toegang heeft gehad tot gevoelige gegevens, moet worden vastgesteld welke informatie toegankelijk kan zijn geweest. Denk aan databasewachtwoorden, API-sleutels, sessietokens en inloggegevens van gebruikers.

Wanneer blootstelling aannemelijk of bevestigd is, moeten betrokken geheimen worden vervangen en actieve sessies waar nodig worden beëindigd. Doe dit gecontroleerd, zodat ook afhankelijkheden tussen applicaties en externe diensten worden meegenomen.

7. Controleer ook uitbestede hosting

Niet iedere organisatie beheert PHP zelf. Bij gedeelde hosting, managed hosting en cloudplatforms kan de leverancier verantwoordelijk zijn voor een deel van de softwarestack.

Vraag de hostingprovider daarom welke PHP-versies worden gebruikt, of de getroffen componenten zijn bijgewerkt en welke tijdelijke maatregelen zijn genomen. Een website-eigenaar blijft er verstandig aan doen de status actief te controleren, ook wanneer het technische beheer is uitbesteed.

Wat als er nog geen patch beschikbaar is?

Wanneer een kwetsbaarheid ernstig is en er al een bruikbare proof of concept circuleert, kan het risico toenemen doordat meer aanvallers de aanvalsmethode kunnen bestuderen en aanpassen.

Dat betekent niet dat elk systeem onmiddellijk zal worden aangevallen of dat een proof of concept automatisch een volledig betrouwbare aanvalsmethode is. Wel kan de drempel voor misbruik lager worden wanneer de demonstratie eenvoudig uit te voeren is en de relevante systemen rechtstreeks vanaf het internet bereikbaar zijn.

Organisaties die bedrijfskritische PHP-applicaties beheren, doen er daarom goed aan vooraf te bepalen wie verantwoordelijk is voor het beoordelen van de aankondiging, het uitvoeren van updates en het controleren van de resultaten.

Als de officiële patch nog niet beschikbaar is, moet een organisatie op basis van haar eigen risicoanalyse bepalen welke tijdelijke beperkingen nodig zijn. Voor publiek toegankelijke systemen met gevoelige gegevens kan het bijvoorbeeld gerechtvaardigd zijn bepaalde functies tijdelijk uit te schakelen of de toegang verder te beperken.

Het volledig offline halen van een website is niet in alle gevallen nodig of wenselijk. De beslissing moet worden gebaseerd op de daadwerkelijke blootstelling, de mogelijke gevolgen van misbruik en de beschikbare mitigerende maatregelen.

Patchen blijft de belangrijkste structurele oplossing

Tijdelijke maatregelen kunnen het risico verkleinen, maar vervangen geen officiële beveiligingsupdate wanneer het probleem in de PHP-runtime zelf zit. Zodra de PHP-ontwikkelaars de relevante patches publiceren, moeten beheerders vaststellen welke update bij hun omgeving hoort en deze zo snel mogelijk installeren.

Daarna is het belangrijk om te controleren of de patch daadwerkelijk actief is. Dat betekent onder meer nagaan welke PHP-versie de webserver gebruikt, of oude processen opnieuw zijn gestart en of er meerdere PHP-installaties naast elkaar bestaan.

Ook moet worden gecontroleerd of applicaties niet onbedoeld een oudere runtime blijven gebruiken. Op sommige servers kan de opdrachtregel bijvoorbeeld een andere PHP-versie tonen dan de versie die door de webserver wordt gebruikt.

Voor organisaties met veel websites kan automatisering helpen om systemen te inventariseren en updates centraal te volgen. Daarbij moeten ook uitzonderingen, verouderde applicaties en systemen waarvoor geen ondersteunde PHP-versie meer beschikbaar is, expliciet worden geregistreerd.

Door: Drifter