PHP-beveiligingslek 2026: zo controleer en patch je kwetsbare webservices

De alarmmelding correct interpreteren

De bewering dat een PHP-beveiligingslek „het halve internet“ zou kunnen treffen, is een sensationele uitspraak, maar geen onderbouwde schatting. Er is geen bewijs dat de helft van alle internetdiensten kwetsbaar is of al is gehackt. Het daadwerkelijke risico is niettemin aanzienlijk, omdat PHP als runtime-omgeving wordt gebruikt in veel websites, webwinkels, API's en beheerinterfaces.

Het is niet van belang of een website PHP gebruikt, maar welke PHP-versie de webverzoeken verwerkt. De beveiligingsupdates van 21 oktober 2026 hebben in principe betrekking op niet-gepatchte installaties van de ondersteunde takken, voor zover deze verzoeken via een webservice verwerken. Een lokale PHP-installatie voor ontwikkelingsdoeleinden moet daarom anders worden beoordeeld dan een van buitenaf toegankelijk klantenportaal.

De Zichtbaarheid op internet De urgentie is hierbij van groot belang. Een openbaar toegankelijke webshop met formulieren en uploadmogelijkheden biedt meer potentiële toegangspunten dan een afgeschermde interne dienst. Maar ook een interne dienst is niet automatisch veilig: VPN-toegang, gehackte accounts of andere systemen in het netwerk kunnen ervoor zorgen dat deze toegankelijk wordt. Bereik alleen is daarom geen vervanging voor een technische risicobeoordeling.

Net zo belangrijk zijn de bedrijfsmodus en Patchstandaard. PHP kan bijvoorbeeld via PHP-FPM, als Apache-module, via php-cgi of ingebed in een product draaien. Meerdere domeinen op dezelfde server kunnen daarbij verschillende versies en updateprocedures hebben. Een algemene geruststelling voor alle PHP-websites zou even onjuist zijn als de veronderstelling dat elke installatie direct kwetsbaar is.

Wat de PHP-kwetsbaarheden technisch mogelijk maken

A Uitvoering van code op afstand (RCE) houdt in dat een aanvaller onder bepaalde omstandigheden code op een extern systeem kan uitvoeren. Volgens het beveiligingsbericht is voor deze PHP-kwetsbaarheden geen voorafgaande aanmelding vereist. De code zou in eerste instantie worden uitgevoerd met de rechten van het webproces, en niet automatisch met onbeperkte beheerdersrechten. De mogelijke gevolgen hangen daarom sterk af van bestandsrechten, toegangsgegevens en de serverscheiding.

CVE-2026-109618 heeft betrekking op foutpaden bij Tekort aan opslagruimte. Als PHP een verzoek afbreekt vanwege een ‘out-of-memory’-situatie, kunnen interne gegevensstructuren onvolledig blijven. Als dergelijke situaties bij het opruimen van het verzoek worden hergebruikt, kan dit leiden tot geheugenbeschadiging. In de officiële beschrijving worden met name multipart-verzoeken, het uploaden van bestanden en het geheugengebruik bij het parseren van geneste invoer genoemd als relevante technische contexten.

CVE-2026-109619 heeft daarentegen betrekking op een aan een verzoek gekoppelde interne status waarvan het geheugen al is vrijgegeven. Als een hergebruikte worker daarna een volgend verzoek verwerkt, kan PHP toegang krijgen tot deze verouderde status voordat de normale initialisatie van kracht wordt. Het beveiligingsbericht verwijst daarbij onder andere naar de voortgang van het uploaden van sessies en foutpaden. Dit beschrijft de foutklasse, niet een handleiding voor misbruik.

• Dit kan gevolgen hebben voor webverzoeken via PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed.
• De fouten zitten in de PHP-runtime, niet in de eerste plaats in WordPress, Joomla, Shopware, thema’s of afzonderlijke plug-ins.
• CMS’en en frameworks beïnvloeden de beschikbare functies, zoals het uploaden van bestanden, maar zijn geen vervanging voor een update van de interpreter.

Waarom niet elke installatie even groot risico loopt

Of een dienst daadwerkelijk gevaar loopt, hangt af van verschillende factoren. Voornaamste risico’s zijn een niet-gepatchte PHP-webruntime en een toegankelijke webservice. Daarnaast spelen de bedrijfsmodus, hergebruikte processen, functies voor uploads of complexe formulieren, en de rechten van het webprocesaccount een rol. Een dienst met uitgebreide schrijftoegang tot webbestanden of toegang tot andere diensten kan ernstigere gevolgen hebben dan een strikt geïsoleerd project.

Bij Apache met mod_php Het PHP-project benadrukt met name het risico: een gedocumenteerde aanval kan al worden uitgevoerd voordat de eigenlijke applicatiecode wordt uitgevoerd. Een goed onderhouden CMS biedt dan geen bescherming tegen de kwetsbaarheid tijdens de uitvoering. Dit betekent niet dat PHP-FPM, php-cgi, FrankenPHP of LiteSpeed als ongevaarlijk worden beschouwd; ook deze moeten bij een niet-gepatchte versie met voorrang worden gecontroleerd.

Daarnaast verdienen producten met ingebedde PHP. Hieronder kunnen containerimages, appliances, NAS-beheersystemen of netwerkproducten vallen waarvan de gebruikersinterface intern gebruikmaakt van PHP. In die gevallen geeft een commando op de host vaak niet de daadwerkelijk gebruikte runtime weer. Het updaten van het besturingssysteem verhelpt ook niet automatisch een kwetsbare PHP-component in een image of een product van een fabrikant.

Een firewall, webapplicatie-firewall of strikte uploadlimieten kunnen afzonderlijke verzoeken bemoeilijken en het aanvalsoppervlak beperken. Ze vormen echter geen vervanging voor de fix, omdat ze het foutieve geheugen- en statusbeheer in de interpreter niet corrigeren. Zelfs een foutloos CMS is afhankelijk van een veilige runtime. Het is daarom van cruciaal belang om de patchstatus van de PHP-versie die daadwerkelijk de webverzoeken verwerkt, te controleren en bij te werken.

De status van beveiligingspatches en ondersteuning vergelijken

Voor beide beveiligingslekken is in eerste instantie de patchstatus binnen de gebruikte PHP-tak van belang. Het PHP-project noemt voor de ondersteunde series specifieke, gecorrigeerde releases. Eerdere patchversies van dezelfde reeks worden als kwetsbaar beschouwd; een upgrade naar de aangegeven of een nieuwere versie van deze tak is de beoogde volledige oplossing.

A Patch-update blijft binnen dezelfde ontwikkelingsreeks, bijvoorbeeld van 8.3.35 naar 8.3.36. Deze update is bedoeld om de beveiligingsfix te leveren en heeft een beperktere compatibiliteitsreikwijdte dan een overstap van 8.2 naar 8.4. Dat laatste is een migratie: afhankelijkheden, uitbreidingen, applicatiecode en eventueel de implementatie moeten hiervoor afzonderlijk worden gecontroleerd.

PHP 8.2 kan nog steeds worden gebruikt voor het oplossen van acute problemen, mits ten minste versie 8.2.35 wordt gebruikt. De ondersteuning voor deze branch loopt echter af op 31 december 2026. Daarom moet je niet bij deze noodoplossing blijven steken: plan de overstap naar een branch met langere ondersteuning, nadat de applicatie in een geschikte omgeving op compatibiliteit is getest.

Bij PHP 8.1 en ouder is bijzondere voorzichtigheid geboden. Het PHP-project biedt hiervoor geen reguliere, actuele release aan; minimale backports van de broncode zijn niet hetzelfde als een algemeen beschikbaar, onderhouden pakket. Een door de leverancier van het besturingssysteem gedocumenteerde beveiligings-backport kan geschikt zijn, maar vereist een vermelding in het beveiligingsadvies of de changelog van het pakket. Ontbreekt deze, dan is een migratie nodig in plaats van louter cosmetische aanpassingen aan de versie.

De werkelijke looptijd van de website controleren

De versiecontrole begint met een inventarisatie, maar mag niet bij de shell ophouden. Op een zelfbeheerde server tonen de volgende commando's de versie van het daar aangeroepen PHP-commando en de configuratiebestanden die bij deze aanroep worden gevonden. Ze wijzigen noch pakketten, noch de configuratie en zijn daarom geschikt als eerste, risicovrije controlepunt.

php -v
php --ini

De uitvoer beschrijft alleen het bestand dat via deze shell-opdracht is opgeroepen CLI-looptijd. Een website kan daarentegen worden gehost via PHP-FPM, Apache met mod_php, php-cgi of een container. Deze web-runtime kan een andere PHP-versie en andere configuratiebestanden gebruiken dan het commando php -v op de host. Voor de veiligheidsbeoordeling is het proces dat de daadwerkelijke HTTP-verzoeken verwerkt, bepalend.

Bij Managed Hosting controleer je daarom in het klantenpaneel welke PHP-versie per project of domein is geselecteerd en vraag je indien nodig de patchstatus van de geleverde dienst op. Bij meerdere domeinen moet elke toewijzing afzonderlijk worden gecontroleerd: een hoofddomein kan al gebruikmaken van de gepatchte versie, terwijl een webshop, een staging-omgeving of een subdomein nog een oudere interpreter gebruikt.

Op servers met PHP-FPM horen de serviceconfiguratie, de pakkettenlijst en de implementatiedocumentatie bij elkaar. In containeromgevingen controleer je bovendien de daadwerkelijk geïmplementeerde image en niet alleen een lokaal build-manifest. Het is van cruciaal belang welke revisie in de actieve pod of container webverzoeken verwerkt; een bijgewerkte basisimage biedt geen bescherming voor een reeds actieve, oudere instantie.

Updatepaden plannen per bedrijfsmodus

De juiste manier om een update uit te voeren hangt af van wie de interpreter levert en waar deze wordt gebruikt. Pas als dit verantwoordelijkheidsgebied duidelijk is, kan er op betrouwbare wijze worden bepaald of een paneelwissel, een pakketupdate, een nieuwe image of een update van de fabrikant nodig is. De volgende indeling maakt een onderscheid tussen deze gevallen, zonder de bedrijfsmodi qua risico gelijk te stellen.

Bij shared hosting moet de provider de beveiligde patchstatus voor de gekozen PHP-serie beschikbaar stellen; de beheerder controleert vervolgens de toepassing. Bij PHP-FPM of mod_php werkt de beheerder doorgaans de pakketten bij en start hij daarna de daadwerkelijk verantwoordelijke dienst op gecontroleerde wijze opnieuw op. Een eenvoudige herstart zonder dat de patch is geïnstalleerd, is geen vervanging voor de update.

Linux-distributies leveren beveiligingsupdates vaak als Backport. Het zichtbare versienummer van het pakket kan dan afwijken van de releases op php.net, ook al is de fix wel opgenomen. Vergelijk daarom niet alleen tekenreeksen zoals „8.4.26“, maar lees ook het beveiligingsbericht en de changelog van de distributeur. Het PHP-project wijst erop dat distributies en LTS-aanbieders patches kunnen ontvangen.

Containers vereisen een eigen procedure: een gecorrigeerde image bouwen of bij de leverancier opvragen, deze uitrollen en oude instanties vervangen. Bij NAS-interfaces, netwerkapparaten of kant-en-klare webapplicaties ligt de correctie daarentegen bij het product van de fabrikant. Een patch voor het hostbesturingssysteem bereikt daar niet noodzakelijkerwijs de ingebouwde interpreter; inventarisatie en aanwijzingen van de fabrikant blijven daarom onmisbaar.

Noodmaatregelen zonder vals gevoel van veiligheid

Op de patchdag stel je eerst een robuuste inventaris op: domeinen, API’s, beheerinterfaces, containers en producten waarin mogelijk PHP is ingebed. Noteer voor elke dienst de webmodus, de verantwoordelijke updatemethode en de daadwerkelijk gebruikte PHP-runtime. Vervolgens krijgt elke openbaar toegankelijke of bedrijfskritische dienst voorrang, niet alleen de server met het meest opvallende versienummer.

Installeer vervolgens de beveiligingsupdate die is vrijgegeven door de hostingprovider, Linux-distributeur, image- of productfabrikant. Voor de ondersteunde PHP-takken is de update naar de gecorrigeerde patchversie de volledige oplossing; een WAF, uploadregels of het opnieuw opstarten van de webserver vormen geen vervanging hiervoor. Plan het proces zo dat de update van het pakket, de image of de fabrikant op een traceerbare manier wordt gedocumenteerd en bij problemen kan worden teruggevonden.

Na de update moet alle oude werknemers moeten worden beëindigd en vervangen door processen waarvan aantoonbaar is dat ze de gepatchte runtime hebben geladen. Gebruik een herlaadbeurt alleen als het betreffende servicebeheer deze volledige vervanging garandeert; anders is een gecontroleerde herstart vereist. Controleer vervolgens de starttijden van processen, de servicestatus of de intern vastgestelde web-runtime, in plaats van de vervanging zomaar aan te nemen. Bij containers rol je de gecorrigeerde image uit en verwijder je alle oude instanties.

Controleer vervolgens de belangrijkste gebruiksroutes, zoals aanmelding, formulieren, uploads, afrekenen en API’s. De tests laten zien of de applicatie en uitbreidingen werken met de bijgewerkte patchstatus; ze bewijzen echter op zichzelf noch dat alle workers zijn vervangen, noch dat er geen eerdere inbreuk heeft plaatsgevonden. Deze punten moeten afzonderlijk worden beoordeeld via operationele en beveiligingscontroles.

Als een patch op korte termijn niet mogelijk is, kunnen bepaalde instellingen bekende aanvalsroutes beperken, maar geen volledige beveiliging bieden. Het uitschakelen van de voortgangsbalk bij het uploaden moet van kracht zijn voordat een verzoek wordt geparseerd. Controleer vooraf of applicaties of interfaces deze voortgangsbalk nodig hebben en start daarna elke betreffende PHP-worker opnieuw op. Controleer vervolgens of er geen oud proces is dat nog met de vorige instelling doorwerkt.

session.upload_progress.enabled = 0

Conservatieve limieten voor POST-gegevens en andere opties die in het beveiligingsbericht worden genoemd, kunnen het aanvalsoppervlak eveneens slechts gedeeltelijk verkleinen. Laat gelezen .user.ini-bestanden of een ini_set() binnen de applicatie zijn voor deze instelling niet voldoende. Beschouw dergelijke maatregelen als een tijdelijke risicobeperking en blijf vasthouden aan de beveiligingsupdate als doel.

Dit moet worden onderscheiden van het reguliere beheer van opgeslagen sessies. Het artikel over de Garbage collection voor PHP-sessies legt uit hoe opschoning, bestandstoegang en workers tijdens normaal gebruik op elkaar inwerken. Deze optimalisatie van de werking verhelpt de hier besproken kwetsbaarheden echter niet en vervangt noch de gecorrigeerde PHP-patchversie, noch de daaropvolgende vervanging van de actieve processen.

Controleer na de patch de werking en eventuele afwijkingen

Een succesvol voltooide pakketupdate bewijst in eerste instantie alleen dat er bestanden of pakketten zijn geïnstalleerd. Het bevestigt noch dat het webproces de nieuwe runtime heeft geladen, noch dat de toepassing daarmee foutloos werkt. Controleer daarom na het opnieuw opstarten de voor de dienst relevante web-runtime en documenteer het tijdstip, de versie, de opnieuw gestarte dienst en het resultaat van de functiecontrole.

De functietest moet de belangrijkste kernprocessen omvatten: belangrijke openbare pagina’s, in- en uitloggen, het verzenden van formulieren, het uploaden van bestanden, afrekenen of boeken, evenals API-eindpunten en achtergrondtaken. Test alleen handelingen waarvoor je bevoegd bent en gebruik bij productieve webshops zoveel mogelijk de daarvoor bestemde testgegevens. Controleer tegelijkertijd de webserver-, PHP- en applicatielogboeken op nieuwe fouten, herhaalde crashes of onverwachte statuscodes.

Een nieuwe start is nodig om duurzame processen en Werknemer Het laden met bijgewerkte code zorgt echter niet op zichzelf voor een oplossing. Zonder geïnstalleerde update blijft het beveiligingslek bestaan. Bij een hoge belasting moet het onderhoudsvenster zo worden gekozen dat verzoeken op een geordende manier kunnen worden afgehandeld en de gevolgen van het opnieuw opstarten van een worker waarneembaar blijven.

In hoeverre een gecontroleerde herstart de doorvoer beïnvloedt, hangt af van het aantal PHP-processen en hun bezettingsgraad. Bij de planning is het nuttig om rekening te houden met wachtrijen, lopende taken en kritieke transacties, in plaats van processen ongecoördineerd te beëindigen. De handleiding PHP-workers begrijpen legt de rol van deze processen bij parallelle dynamische verzoeken uit.

Als er na de patch afwijkingen optreden, maak dan onderscheid tussen compatibiliteitsfouten van de applicatie en een onvolledige uitrol. Vergelijk de configuratie, de geactiveerde uitbreidingen en de web-runtime met de stand van zaken vóór het onderhoud. Een rollback mag er niet toe leiden dat een openbaar toegankelijke dienst permanent in de kwetsbare toestand blijft; zorg in dat geval snel voor een compatibel, gepatcht updatepad.

Prioriteit geven aan oude en verborgen PHP-installaties

Er moet speciale aandacht worden besteed aan systemen waarop PHP niet zichtbaar is als bewust geïnstalleerde runtime: Docker-images, virtuele appliances, NAS- en netwerkinterfaces, evenals kant-en-klare softwareproducten. Een update van de host zorgt niet automatisch voor een update van een containerimage of van de intern meegeleverde runtime van een fabrikantproduct. Vraag fabrikanten daarom specifiek naar hun beoordeling en naar een beveiligingsupdate voor het betreffende product.

Bij oude branches moeten drie gevallen duidelijk van elkaar worden onderscheiden. Een regulier ondersteunde PHP-release ontvangt de beveiligingsupdates die door het PHP-project worden gepubliceerd. Een backport van een distributie of aanbieder kan de fix bevatten ondanks een afwijkend zichtbaar versienummer, maar dit moet worden gestaafd door het beveiligingsbericht of de changelog van die aanbieder. Zelf onderhouden broncode vereist daarentegen eigen verantwoordelijkheid voor het bouwen, testen en exploiteren; deze is geen gelijkwaardige vervanging voor een regulier updatekanaal.

PHP 8.1 en oudere branches krijgen geen reguliere upstream-releases meer. Voor PHP 8.2 is er weliswaar een gecorrigeerde patch beschikbaar, maar de ondersteuning voor deze tak loopt eind 2026 af. Gebruik een beschikbare oplossing voor de acute situatie, maar plan voor oude of verouderde versies ook een geteste Migratie naar een tak die langer wordt ondersteund.

1. Werk eerst openbaar toegankelijke diensten bij waarvan de PHP-runtime nog niet is gepatcht, vooral als er upload- of beheerfuncties beschikbaar zijn.
2. Behandel Apache met mod_php en bedrijfskritische webwinkels, API’s of klantenportalen onmiddellijk daarna; het officiële beveiligingsbericht wijst op een bijzonder kritiek risico voor mod_php.
3. Containers, appliances en producten van derden registreren aan de hand van images, inventaris en de status van de fabrikant; het ontbreken van zichtbare PHP-pakketten is geen reden om gerust te zijn.
4. Diensten die niet worden ondersteund of waarvoor niet tijdig patches beschikbaar zijn, isoleren en de toegang daartoe beperken, maar tegelijkertijd een bindend plan opstellen voor vervanging, upgrade of migratie.

Netwerksegmentatie, verplichte VPN-gebruik of restrictieve toegangsregels kunnen tijd winnen wanneer beheerinterfaces niet onmiddellijk kunnen worden gepatcht. Ze zijn echter slechts Overgangsmaatregelen, omdat interne gebruikersaccounts, gehackte apparaten en verkeerd geconfigureerde koppelingen nog steeds aanvalsvlakken kunnen vormen. Als er voor een product geen oplossing wordt aangeboden of als de PHP-tak definitief niet meer wordt ondersteund, is vervanging of migratie de meest betrouwbare keuze.