Tussen de ontdekking van de PHP2Shell-kwetsbaarheden en de officiële release van de PHP2Shell patch zit een spanningsveld: je kunt niet alles volledig blokkeren met alleen een workaround. Wat je wél kunt doen, is de kans op succesvolle aanvallen verkleinen door je blootstelling te beperken, je bereik te reduceren en klaar te staan om direct te updaten zodra de fix beschikbaar is.
In dit artikel zetten we de belangrijkste lessen op een rij—zonder veiligheid te beloven waar niemand die garantie kan geven.
Waarom de PHP2Shell patch je beste bescherming blijft
De kern van het verhaal is simpel: de mitigatie die online rondging, wordt door de betrokken onderzoekers later teruggebracht tot “niet genoeg”. PHP zelf benadrukt volgens de bron dat de echte mitigatie patchen of upgraden is. Dat betekent dat je tijdelijke maatregelen vooral moeten gelden als risicoreductie, niet als definitieve oplossing.
De geplande release is op 14:00 UTC op 21 oktober. Tot die tijd is er in de praktijk één doel: ervoor zorgen dat een eventueel gecompromitteerde server zo weinig mogelijk kan doen en dat aanvallers je niet makkelijk kunnen bereiken.
“session.upload_progress.enabled=0” is geen complete fix
Een instelling die veel genoemd werd, is één regel in een PHP-configuratie: session.upload_progress.enabled=0. Die zet Session Upload Progress uit, een PHP-feature die standaard aan staat en die bij uploads bijhoudt hoever een upload is.
De onderzoekers die deze optie eerder noemden, zeggen later dat je dit niet moet zien als een volledige verdediging. Er wordt verwacht dat aanvallen er omheen kunnen; bovendien is niet door iedereen bevestigd dat de kwetsbaarheid precies in die upload-progress flow zit. Kortom: zelfs als de instelling iets remt, is het geen schild waar je op kunt leunen.
Als je de instelling al hebt gezet: laat hem staan, maar reken er niet op
Er wordt niet gezegd dat je de wijziging moet terugdraaien. Wel is het advies helder: beschouw het niet als bescherming tegen PHP2Shell. Daarnaast meldt de bron dat PHP’s eigen documentatie al aangeeft dat je Session Upload Progress uit moet zetten wanneer je app er geen gebruik van maakt, omdat opgeslagen gegevens (zoals bestandsnamen en veldnamen) niet worden gevalideerd en PHP-code zouden kunnen bevatten.
Het praktische gevolg als je de feature uitschakelt: upload-progress bars werken mogelijk niet meer. Dat is een kostenpost die je kunt accepteren als daarmee je risicoprofiel daalt—mits je intussen wel klaarmaakt om te patchen.
Controleer of je wijziging echt geldt op je webserverproces
Let op: configuratie-instellingen zijn niet altijd “global”. De bron geeft aan dat session.upload_progress.enabled=0 een INI_PERDIR-instelling is. Dat betekent dat je de waarde kunt zetten in verschillende configuratiebestanden (zoals php.ini, .htaccess of .user.ini), maar dat het effect kan verschillen per setup.
Belangrijke checkpunten uit de bron:
- Test op de juiste manier: controleer de waarde op het proces dat webverkeer bedient (bijvoorbeeld PHP-FPM of mod_php), en niet alleen met commando’s in de shell.
- Als je met .user.ini werkt: die wordt alleen gelezen door CGI/FastCGI, niet door de Apache-module.
- PHP herleest .user.ini standaard pas elke 300 seconden. Dan kan de wijziging dus enkele minuten later zichtbaar zijn.
Tot de PHP2Shell patch live is: verlaag je bereik en aanvalslijn
Omdat exploit-activiteit al vroeg werd gemeld door Cloudflare, is “wachten” geen strategie. De bron noemt meerdere risicobeperkende maatregelen die je kunt treffen voordat je PHP echt is gepatched.
Richt je op drie principes: minder blootstelling, minder mogelijkheden en snelle opvolging.
Haal internetblootstelling terug of zet controles op scherp
Een terugkerend advies: isoleer internet-facing applicaties tijdelijk van het publieke netwerk totdat je kunt patchen. Kan dat niet volledig, beperk dan de route naar je origin server. Denk aan:
- Toegang achter VPN
- Alleen geautoriseerde of “allowlisted” clients
- Authenticatie of toegangscontrole aan de edge (zodat traffic niet direct tot de server komt)
Het idee hierachter: stel dat een aanvaller je webserver kan bereiken of beïnvloeden, dan wil je dat hij zo min mogelijk direct kan doordringen.
Kleinere “impact radius”: data, rechten en credentials beperken
De bron noemt aanvullend een aanpak om de schade bij een mogelijke overname te verkleinen:
- Beperk wat er op de server wordt opgeslagen
- Verminder privileges (minimale rechten)
- Verwijder of reduceer opgeslagen credentials, inclusief cloud-roles
- Zorg dat logging aanstaat en op een veilige locatie terechtkomt
Dit helpt niet tegen de kwetsbaarheid zelf, maar maakt het voor een aanvaller lastiger om door te pakken én maakt achteraf onderzoek eenvoudiger.
Isoleren aan de serverkant: wat je wél en níet mag verwachten
De bron noemt dat sommige onderzoekers een “sterker stopgap” zien in het blokkeren van aanvragen met multipart/form-data voordat die bij PHP aankomen. Omdat het vermoedelijke probleem in het lezen van de request body zit, kan zo’n filter de entry-route remmen.
Maar ook hier geldt: dit is risicoreductie, geen bevestigde waterdichte barrière. Bovendien is de impact op je app reëel: file uploads en sommige formulieren kunnen tijdelijk niet meer werken zolang je het blok niet verfijnt.
Daarnaast wordt gewaarschuwd dat POST-only regels kunnen worden omzeild: PHP 8.4 introduceerde een functie (request_parse_body()) die ook andere methodes kan laten lezen. Dus als je dit toepast, vergt het testen en afstemming op jouw verkeer.
WAF of noodregels: handig, maar niet hetzelfde als patchen
Cloudflare heeft volgens de bron emergency rules uitgerold voor sites die via hun platform draaien. Die regels worden expliciet gezien als stopgap totdat de echte fix live staat.
Een belangrijk nadeel van dergelijke noodmaatregelen is dat ze alleen verkeer zien dat via Cloudflare passeert. Bovendien kunnen nieuwe aanvalspaden opduiken die de noodregels niet afdekken.
Als je WAF gebruikt: zie het als extra laag. Plan tegelijk je PHP2Shell patch zonder uitstel.
Als je niet direct kunt patchen: reduceer direct je omgeving
Wanneer je op korte termijn geen update kunt uitvoeren, adviseert CERT-EU volgens de bron om internet-facing applicaties tijdelijk te isoleren tot de fix er is. Binnen het PHP-project wordt dezelfde insteek genoemd: een korte shutdown kan bij veel organisaties zinvoller zijn dan hopen dat mitigaties genoeg zijn.
Realistisch voor de meeste teams is isoleren of afschermen via toegang aan de edge. Controleer daarbij ook of traffic je origin überhaupt kan bereiken buiten die controles.
WordPress en andere apps: let op het verschil tussen applicatie en PHP-runtime
Een veelgemaakte fout: het updaten van WordPress, Laravel of een andere applicatie betekent niet automatisch dat je PHP-runtime ook gepatcht is. De PHP versie komt uit je serverpakket, hostingomgeving of container image.
Als je shared of managed hosting gebruikt: vraag je provider wanneer een fixed PHP build beschikbaar komt en laat ze paraat staan voor snelle doorlevering. Controleer bovendien bij backports in Linux-distributies: de versienummer is soms misleidend. Vergelijk daarom niet alleen het nummer, maar check de changelog of de distributie-advisory voor de CVE-informatie.
Wat je moet nalopen zodra de PHP2Shell patch is vrijgegeven
De bron benadrukt dat exploit-activiteit vroeg en nog niet volledig bevestigd was. Dat maakt het extra belangrijk om na de release gericht te controleren.
- Welke fixed versies gelden voor jouw PHP-branch?
- PHP vermeldt welke versies het risico lopen—klopt dat voor jouw installatie?
- Controleer of PHP bevestigt of afwijst dat een ini-setting als mitigatie geldt.
- Bekijk of er aan sessie/upload-code is gesleuteld. Dat kan ook helpen bij de discussie over waar het probleem precies zit.
Tot slot: kijk na het patchen naar je logs van vóórdat je update werd toegepast. Dat kan inzicht geven in vroege probes of verdachte requests.
Wil je meer context over het beheren van patches en veiligheidsmaatregelen rond PHP-lekken? Lees dan ook eens PHP-kwetsbaarheden: bereid je voor op patchen.
Conclusie
De belangrijkste takeaway is dat de PHP2Shell patch de enige echte bescherming is. Tijdelijke maatregelen—zoals het uitschakelen van Session Upload Progress—kun je gebruiken om je risico te verlagen, maar je moet ze niet zien als een vervanging van patchen. Door internetblootstelling te beperken, bereik te reduceren en je omgeving klaar te zetten voor een snelle upgrade, vergroot je je kans om veilig door de periode tot de release heen te komen.
Zodra de fix beschikbaar is, update je direct de PHP-runtime die je webverkeer bedient en controleer je versie- en loggegevens. Zo maak je van “wachten” een gecontroleerde overgang naar echte veiligheid.
Bron: https://thehackernews.com/2026/10/php2shell-what-actually-protects-you.html
