PHP2Shell uitgelegd: wie je website moet patchen, en hoe

Op 21 oktober 2026 werd een kritiek beveiligingslek in PHP bekendgemaakt, de programmeertaal achter ongeveer drie op de vier websites. Overheidswebsites in Nederland, Frankrijk en Canada werden uit voorzorg offline gehaald, en het Zuid-Koreaanse KISA (Korea Internet & Security Agency) publiceerde noodrichtlijnen. De beveiligingswereld noemt het PHP2Shell.

Het goede nieuws: de patches zijn uit en de meeste grote hostingbedrijven hebben ze al doorgevoerd. Het probleem is dat wie je website patcht volledig afhangt van hoe die gehost wordt. Deze gids legt uit wie nu meteen moet handelen, welke patches er zijn en hoe de grote hostingpartijen het hebben aangepakt.

De belangrijkste punten

• PHP2Shell bestaat uit twee kritieke lekken voor het op afstand uitvoeren van code in PHP zelf (CVSS 9.2), die zonder inloggen te misbruiken zijn.
• WordPress of plugins bijwerken lost het niet op. PHP zelf moet gepatcht worden.
• Gepatchte versies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35 of nieuwer. Voor PHP 8.1 en ouder is er geen officiële release.
• Bij shared of managed hosting patcht je hostingpartij PHP, maar je moet het wel controleren. Op een VPS of dedicated server moet je zelf patchen en PHP herstarten.
• Voor een derde lek (CVE-2026-115560) is er een tijdelijke oplossing: session.upload_progress.enabled = 0.

Wat is PHP2Shell?

PHP2Shell is de naam voor twee kwetsbaarheden voor het op afstand uitvoeren van code (RCE) die in de kern van PHP zijn gevonden.

• CVE-2026-109618: een geheugencorruptielek dat wordt uitgelokt door situaties met geheugentekort te misbruiken
• CVE-2026-109619: een lek dat al vrijgegeven globale status hergebruikt

Beide hebben een ernst van CVSS 9.2 op 10, en het meest verontrustende is dat ze zonder inloggen en zonder account te misbruiken zijn. De lekken zitten in de verwerking van verzoeken door PHP zelf, niet in WordPress of een plugin. De aanval werkt dus al voordat de code van je website draait. WordPress volledig up-to-date houden helpt niets als PHP niet gepatcht is.

Vermoedelijk is vrijwel elke PHP-versie sinds 5.4 getroffen, en volgens W3Techs gebruikt ongeveer 75% van de websites met een bekende servertaal PHP. De lekken werden ontdekt door de beveiligingsbedrijven Calif en Wiz tijdens een analyse met AI-modellen (OpenAI GPT-5.6 Sol en Google Gemini 4 Argon) en in augustus gemeld aan het PHP-team. Terwijl de patches werden voorbereid, lekten details uit, waardoor de bekendmaking een dag werd vervroegd. Echte aanvalspogingen begonnen al op de dag van de bekendmaking, en Cloudflare meldde er miljoenen. Een geslaagde grootschalige inbraak is nog niet bevestigd, maar de aanvalstools worden steeds beter. “We zijn nog niet getroffen” is dus geen reden om achterover te leunen.

Op 23 oktober werd vervolgens een derde, verwant lek bekendgemaakt: CVE-2026-115560. Dat werkt alleen bij bepaalde combinaties van instellingen, daarom raadt het PHP-team een tijdelijke oplossing aan in plaats van een noodpatch. Meer daarover lees je hieronder in het deel over patches.

Wie moet in actie komen?

Alles draait om één vraag: “Wie beheert PHP op mijn website?” Het antwoord bepaalt wat je moet doen.

Welke patches zijn er?

Officiële patches (21 oktober 2026)

Beheer je je eigen server, dan werk je meestal bij via de pakketten van je distributie. Ubuntu, Debian, AlmaLinux, Amazon Linux en andere hebben al gepatchte pakketten uitgebracht.

# Voorbeeld voor Debian / Ubuntu
sudo apt update
sudo apt upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

Zonder herstart is de patch niet actief. Als je de pakketten bijwerkt maar PHP-FPM of Apache niet herstart, blijft de oude PHP die nog in het geheugen geladen is de verzoeken afhandelen. De richtlijnen van KISA waarschuwen hier uitdrukkelijk voor. Gebruik je de Remi-repository op een systeem uit de CentOS-familie, houd er dan rekening mee dat Remi op de dag van de bekendmaking nog geen update had. Overweeg dan de standaardpakketten van je distributie of PHP zelf compileren.

PHP 8.1 of ouder: backports

PHP 8.1, 8.0 en 7.4 worden niet meer ondersteund, dus er zijn geen officiële gepatchte releases. Toch heb je opties.

• Het PHP-team heeft minimale broncodepatches (backports) uitgebracht voor 7.4, 8.0 en 8.1. Die kun je toepassen als je PHP zelf compileert.
• De Ubuntu- en Debian-pakketten uit de repository van Ondřej Surý bevatten backports voor 5.6 tot en met 8.1.
• Sommige hostingpartijen (Hostinger, 20i, xCloud en andere) hebben eigen gepatchte builds uitgebracht, ook voor oudere versies. Kijk eerst of jouw hostingpartij een backport aanbiedt.

Backports zijn wel slechts een noodoplossing. Dit is een goed moment om over te stappen naar PHP 8.3 of nieuwer.

Derde lek CVE-2026-115560: tijdelijke oplossing tot de patch er is

Het derde lek, bekendgemaakt op 23 oktober, heeft te maken met de functie voor de uploadvoortgang van sessies (session upload progress) in PHP. Met gangbare instellingen is het moeilijk uit te lokken, dus er komt geen noodpatch. De oplossing zit in de volgende reguliere release. Tot die tijd bestaat de officiële tijdelijke oplossing uit één instelling:

; Toevoegen aan php.ini of de PHP-FPM-poolconfiguratie, daarna PHP herstarten
session.upload_progress.enabled = 0

Tenzij je website een voortgangsbalk voor uploads toont, verlies je vrijwel niets. Zoals de hostingtabel hieronder laat zien, hebben de grote hostingpartijen deze instelling al op serverniveau uitgezet.

Tijdelijke maatregelen vóór het patchen (geen volledige oplossing)

• session.upload_progress uitzetten: zie hierboven. Dit blokkeert een bekend aanvalspad voor CVE-2026-109619.
• WAF-regels van Cloudflare: Cloudflare voerde vlak voor de bekendmaking noodregels in voor alle abonnementen, ook het gratis abonnement. Cloudflare zegt zelf wel dat dit “tijdelijke bescherming is, geen vervanging voor de patch”, en er zijn al pogingen gezien om de regels te omzeilen.
• Firewallregels van je hostingpartij: tools zoals ModSecurity blokkeren aanvalspatronen vóór de server. Ze leveren tijd op, maar lossen het onderliggende probleem niet op.

Het officiële standpunt van het PHP-team is duidelijk: “Er is geen volledige mitigatie. Bijwerken is de enige veilige optie.”

Hoe de grote hostingpartijen reageerden

Gelukkig kwamen de bekende hostingpartijen snel in actie. Hieronder staat de stand van zaken per bedrijf, op basis van hun officiële mededelingen. Het gemeenschappelijke patroon: eerst aanvallen blokkeren met firewallregels en instellingen, daarna de patch op alle servers uitrollen zodra die verscheen.

De stand van zaken per hostingpartij verandert voortdurend. Staat jouw partij er niet bij of twijfel je, bekijk dan direct hun statuspagina en mededelingen. Andersom gezegd: als je hostingpartij stil blijft en helemaal niets heeft gemeld, is dat op zich al een waarschuwingssignaal.

Zo controleer je je website (3 minuten)

1. Controleer je PHP-versie: ga in WordPress naar Gereedschap → Sitediagnose → Info → Server en bekijk de PHP-versie.
2. Vergelijk met de gepatchte versies: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 of nieuwer betekent dat je gepatcht bent.
3. Ga er niet van uit dat een lager nummer betekent dat je kwetsbaar bent: sommige hostingpartijen, zoals Hostinger, houden het versienummer gelijk en patchen de build. In dat geval is het criterium of de Build Date in de PHP Info van je hostingpaneel 21 oktober 2026 of later is.
4. Bij PHP 8.1 of ouder: bekijk de mededelingen van je hostingpartij of vraag of ze een backport aanbieden. Zo niet, plan dan een upgrade in.
5. Op een VPS of dedicated server: voer php -v uit in de terminal en controleer of dat dezelfde PHP is die je webserver echt gebruikt (volgens phpinfo). Vaak draaien er meerdere PHP-versies naast elkaar op één server.

Patchen is niet het einde: controles achteraf

Een patch blokkeert alleen toekomstige aanvallen. Is je website vóór het patchen al gecompromitteerd, dan draait de patch dat niet terug. Omdat details vóór de patch uitlekten en aanvallen al vóór de bekendmaking begonnen, raadt KISA het volgende aan:

• Controleer de logbestanden: zoek in de logs van de webserver en PHP naar verdachte verzoeken, ook uit de periode vóór het patchen.
• Zoek naar webshells: kijk of er onlangs aangemaakte of gewijzigde PHP-bestanden, onbekende beheerdersaccounts of vreemde cronjobs zijn.
• Wijzig de inloggegevens: wijzig op blootgestelde servers de databasewachtwoorden, API-sleutels en beheerderswachtwoorden.
• Zorg voor back-ups: bewaar geteste, herstelbare back-ups van vóór en na het patchen op een externe locatie.
• Zie je sporen van een inbraak, herstart de server dan niet (dan gaat het bewijs in het geheugen verloren). Verbreek de netwerkverbinding en meld het bij een professional.

Laatste checklist

• Stel vast welke PHP-versie je website draait en wie PHP beheert
• Controleer of je een gepatchte versie draait (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) of dat de builddatum 21 oktober of later is
• Werk op een VPS of dedicated server PHP zelf bij en herstart altijd de PHP-service
• Kijk bij PHP 8.1 of ouder of er een backport is en plan een upgrade naar 8.3 of nieuwer
• Zet session.upload_progress uit vanwege het derde lek (of controleer of je hostingpartij dat heeft gedaan)
• Controleer logs en zoek naar webshells uit de periode vóór het patchen
• Neem vergeten test-, staging- en evenementensites op in je inventaris

Veelgestelde vragen

Beschermt een WordPress-update me tegen PHP2Shell?

Nee. De lekken zitten in PHP zelf, niet in WordPress of plugins. Alleen een gepatchte PHP-build beschermt je website.

Ik heb shared hosting. Moet ik iets doen?

Meestal patcht je hostingpartij PHP voor je, maar controleer het wel. Kijk of je PHP-versie gepatcht is of dat de builddatum van PHP 21 oktober 2026 of later is.

Is Cloudflare genoeg om mijn website veilig te houden?

Nee. De WAF-regels van Cloudflare zijn tijdelijke bescherming en er zijn al pogingen gezien om ze te omzeilen. Je originserver heeft nog steeds de PHP-patch nodig.

Zijn platforms zonder PHP, zoals Wix, getroffen?

Nee. PHP2Shell is een lek in PHP op de server, dus platforms die niet op PHP draaien, zoals Wix, en statische websites zijn niet getroffen.

Hulp nodig?

Beheer je meerdere websites of weet je niet zeker of je hostingpartij al heeft gepatcht? Neem contact op met We Design Orange. We helpen met alles: van het controleren van de PHP-versie en build van elke website tot het patchen van je VPS, het zoeken naar sporen van een inbraak en het testen van je website na een PHP-upgrade.

Dit artikel vat openbare informatie samen zoals bekend op 23 oktober 2026. Het gaat om technische informatie, niet om een beveiligingsanalyse of juridisch advies. De stand van zaken per hostingpartij is gebaseerd op hun officiële mededelingen en kan veranderen. Vermoed je een inbraak, neem dan contact op met een beveiligingsbedrijf of met het nationale computer emergency response team (CERT) van je land.