PHP2Shell: direct actie vereist bij kritieke PHP-kwetsbaarheden

Op 21 oktober 2026 om 14:00 UTC (16u NL tijd) brengt PHP beveiligingsupdates uit voor twee ernstige kwetsbaarheden, samen bekend onder de naam PHP2Shell (CVE-2026-109618 en CVE-2026-109619). Beide lekken scoren een 9,2 op 10 en stellen een aanvaller in staat om op afstand code uit te voeren op een webserver — zonder dat inloggen vereist is. Details lekten een dag voor de officiële release uit, en er zijn inmiddels al aanvallen waargenomen in het wild.

Draait jouw website of applicatie op PHP? Dan is het verstandig om vandaag nog actie te ondernemen. Hieronder lees je wat je nu kunt doen, van de echte oplossing tot tijdelijke noodmaatregelen. Voor de volledige technische achtergrond en een live tijdlijn kun je terecht bij het onderzoek van Sansec.

Waarom dit zo urgent is

PHP2Shell is gevaarlijk omdat het geen authenticatie vereist. Elke bezoeker — of kwaadwillende bot — kan in theorie willekeurige code op je server uitvoeren. De combinatie van een hoge CVSS-score, vroege lekken van technische details en al gemelde aanvallen maakt dit tot één van de urgentste PHP-kwetsbaarheden in jaren. Zeker als je een webwinkel of zakelijke site draait, is snel handelen essentieel — dit sluit ook aan bij de bredere cyberbeveiligingseisen die vanuit de Europese NIS2-richtlijn op bedrijven afkomen.

Stap 1: Update PHP zo snel mogelijk

De enige echte oplossing is een update naar een gepatchte versie van PHP. Alles wat verder in dit artikel staat, vermindert slechts het risico totdat je die update hebt doorgevoerd.

De verwachte gepatchte versies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Deze nummers zijn afkomstig van beveiligingsonderzoekers en trackers van Linux-distributies — PHP bevestigt ze pas officieel bij de release zelf.

• Oudere versies zoals 8.1, 8.0, 7.x en 5.x ontvangen geen officiële patch meer. Plan een upgrade naar een ondersteunde versie en zorg dat je de tijdelijke maatregelen hieronder in ieder geval treft.
• Controleer of de fix daadwerkelijk in jouw pakket zit. Distributies backporten regelmatig beveiligingsfixes, waardoor een versienummer alleen niets zegt. Zoek het CVE-nummer op in de changelog: via apt changelog php8.3-cli op Debian/Ubuntu of rpm -q --changelog php op RHEL, Alma of Rocky.
• Herstart PHP na de update — anders draait de oude, kwetsbare code gewoon door. Gebruik bijvoorbeeld systemctl restart php8.3-fpm.
• Op gedeelde hosting? Neem contact op met je hostingpartij en vraag wanneer zij de gepatchte versie uitrollen. Bekijk ook onze vergelijking van de beste WordPress-hostingproviders als je overweegt over te stappen naar een meer proactief beveiligde omgeving.

Stap 2: Schakel session upload progress uit

Uit vroege analyses blijkt dat de kwetsbaarheid verband houdt met PHP’s ingebouwde functie voor het bijhouden van uploadvoortgang in sessies. Deze staat standaard aan. Door hem uit te zetten en strikte sessiemodus te activeren, verklein je de aanvalsoppervlakte — al waarschuwen onderzoekers dat dit mogelijk maar één van de twee bugs blokkeert.

Voeg het volgende toe aan php.ini, .user.ini of de PHP-instellingen van je hostingpanel:

session.upload_progress.enabled = Off
session.use_strict_mode = 1

Gebruik je PHP-FPM, dan kun je dit ook per pool instellen:

php_admin_flag[session.upload_progress.enabled] = off

Herlaad PHP na de wijziging. De meeste websites maken geen gebruik van uploadvoortgangsbalken die op deze feature steunen, dus de kans dat dit iets breekt is klein.

Stap 3: Blokkeer uploads op webserverniveau (nginx)

De bekende aanvalspaden maken gebruik van multipart-verzoeken — het formaat dat browsers gebruiken bij het uploaden van bestanden. Door deze verzoeken al op webserverniveau te blokkeren, bereiken ze PHP helemaal niet meer. Sansec raadt dit aan als tijdelijke maatregel.

Voeg het volgende toe aan je server { }-blok, buiten een location-blok:

if ($http_content_type ~* "multipart/form-data") {
    rewrite ^ /__upload_blocked last;
}

location = /__upload_blocked {
    internal;
    default_type text/plain;
    return 403 "Uploaden is momenteel niet mogelijk vanwege een ernstige kwetsbaarheid. We zijn zo snel mogelijk terug.n";
}

Bezoekers die proberen iets te uploaden krijgen een duidelijke foutmelding in plaats van een kale 403-pagina. De regel internal zorgt ervoor dat niemand de foutpagina direct kan openen. Gewone paginabezoeken zonder upload werken gewoon door.

Test en herlaad nginx als volgt:

nginx -t && nginx -s reload
curl -i -F "x=1" https://jouwsite.example/
curl -i -F "x=1" https://jouwsite.example/een/subpagina

Beide tests zouden een 403 met de foutmelding moeten teruggeven. Werkt een subpagina nog wel? Controleer dan of het if-blok direct in server { } staat en niet binnen een location.

Stap 4: Blokkeer uploads op webserverniveau (Apache / .htaccess)

Op Apache 2.4 voeg je het volgende toe aan de .htaccess in je documentroot. Het maakt niet uit waar in het bestand je dit plaatst — ook boven of onder de regels van je CMS werkt het:

<If "req('Content-Type') =~ m#multipart/form-data#i">
    ErrorDocument 403 "Uploaden is momenteel niet mogelijk vanwege een ernstige kwetsbaarheid. We zijn zo snel mogelijk terug."
    Require all denied
</If>

Apache weigert het verzoek voordat herschrijfregels worden uitgevoerd, waardoor alle URL’s gedekt zijn — niet alleen de homepagina. Een aanpak op basis van RewriteRule [F] is foutgevoeliger: als die regel na de CMS-regels staat, worden alleen verzoeken naar de homepagina geblokkeerd terwijl subpagina’s nog steeds PHP bereiken.

• Gebruik de .htaccess die Apache daadwerkelijk inleest voor jouw site. Bij Magento 2 is dat vaak het bestand in de map pub/.
• Submappen met een eigen .htaccess — zoals een aparte WordPress-installatie — hebben mogelijk dezelfde blokkade nodig.
• Krijg je een 500-fout na het opslaan? Dan staat je host waarschijnlijk deze directive niet toe in .htaccess. Vraag hen dit toe te staan of de regel direct in de serverconfiguratie te plaatsen.

Test ook hier zowel de homepagina als een subpagina:

curl -i -F "x=1" https://jouwsite.example/
curl -i -F "x=1" https://jouwsite.example/een/subpagina

Beide moeten een 403 teruggeven. Laadt een subpagina nog normaal? Dan is de blokkade voor die URL niet actief.

Wat werkt er niet meer, en wanneer verwijder je de blokkade?

De webserverblokkade onderschept alle multipart-verzoeken, niet alleen echte bestandsuploads. Houd rekening met het volgende zolang de maatregel actief is:

• Bestands- en afbeeldinguploads, ook in je beheerpaneel of CMS
• Sommige gewone formulieren (zoals contactformulieren of productbewerkingen) die als multipart worden verzonden
• Achtergrond-uploads via JavaScript, die mogelijk een generieke foutmelding tonen

De PHP-instellingen uit stap 2 veroorzaken zelden problemen en mogen gewoon blijven staan. Verwijder de webserverblokkade zodra PHP is bijgewerkt en je in de changelog hebt bevestigd dat de fix aanwezig is. Herlaad daarna nginx of Apache en test een upload om te bevestigen dat alles weer werkt. Als je wilt weten of je site na de update nog correct online is, kan een tool als UptimeRobot je daar goed bij helpen.

Meer informatie en bronnen

• Critical PHP RCE: CVE-2026-109618 en CVE-2026-109619 — Sansec: het volledige advies, mitigaties en een live tijdlijn
• Upcoming Critical PHP Security Release — officiële aankondiging van PHP
• Major security alert: PHP vulnerable to critical RCE — Patchstack
• PHP2Shell: what actually protects you before the patch — The Hacker News

Laatst bijgewerkt op 21 oktober 2026