Kort gezegd: Veel PHP2Shell-tips die nu in forums en op sociale netwerken rondgaan, beschermen niet of schaden zelfs: verzoeken met sessiecookie blokkeren, foutmeldingen verbergen, instellingen via .user.ini zetten of alleen het CMS bijwerken. php.net is eenduidig: er zijn geen volledige tussentijdse maatregelen, de PHP-update met herstart van alle processen is de enige veilige weg.
Waarom valse tips in deze situatie gevaarlijk zijn
Bij een kritiek lek met veel aandacht ontstaat een markt voor snelle oplossingen. Adviezen worden gedeeld, ingekort en doorgegeven, vaak zonder de beperkingen van de oorspronkelijke bron. Bij PHP2Shell komt erbij dat details volgens berichten al vóór de officiële datum bekend werden en de situatie in de eerste dagen onoverzichtelijk was.
Een verkeerde tip schaadt dubbel. Hij laat het lek open en wekt het gevoel dat er iets is gedaan. Precies dat gevoel leidt ertoe dat de eigenlijke update blijft liggen. Sommige adviezen leggen bovendien de eigen website lam.
Negen adviezen in de factcheck
De volgende tabel vat samen wat wij de afgelopen dagen vaak hebben gelezen, en zet er de uitspraken van de primaire bronnen tegenover.
| Rondgaande tip | Waarom hij niet houdt | Wat in plaats daarvan geldt |
|---|---|---|
Alle verzoeken met PHPSESSID blokkeren |
Door vakauteurs uitdrukkelijk afgewezen; legt logins en winkelwagens lam | PHP bijwerken |
session.upload_progress.enabled=0 volstaat |
Dicht volgens vakberichten niet beide lekken | Zinvolle tussentijdse maatregel, update blijft verplicht |
Waarden via ini_set() of .user.ini instellen |
php.net raadt dat uitdrukkelijk af | Aan de serverzijde in php.ini, FPM-pool of serverconfiguratie |
| Foutmeldingen verbergen | Volgens php.net helpen error_reporting, display_errors of @ niet |
Update; foutuitvoer toch niet openbaar tonen |
Geheugen beperken via RLIMIT_AS of RLIMIT_DATA |
php.net waarschuwt dat juist dat de kwetsbare situatie kan uitlokken | Grens via container of cgroup |
| WordPress of plug-ins bijwerken | Het lek zit in de PHP-interpreter, niet in het CMS | PHP-runtime bijwerken |
| Cloudflare of een andere WAF volstaat | Bescherming alleen voor verkeer via de dienst; rechtstreeks bereikbare servers blijven open | WAF als extra laag, niet als vervanging |
| Dienst herladen in plaats van herstarten | Volgens Red Hat volstaat een reload niet, bestaande workers kunnen de oude toestand behouden | Alle workers volledig herstarten |
| Gepatcht betekent schoon | Een patch verwijdert geen eerder binnengebrachte schadelijke software | Logs vanaf 20 oktober veiligstellen en op sporen controleren |
De drie meest voorkomende misvattingen nader toegelicht
Het cookieverbod
De tip om alle verzoeken met het sessiecookie PHPSESSID af te wijzen, klinkt technisch en vastberaden. Vakauteurs wijzen hem uitdrukkelijk af. In de praktijk breekt hij alles wat een sessie nodig heeft: klantaccounts, winkelwagens, beheerdersgedeelten, formulieren met bescherming tegen vervalsing. Een bescherming tegen het lek is hij niet.
De ene instelling die alles oplost
session.upload_progress.enabled=0 staat in de aanbevelingen van php.net en is tegen CVE-2026-115560 de genoemde oplossing. In sommige bijdragen werd daar „PHP2Shell uitgeschakeld” van. Volgens vakberichten dicht deze instelling alleen echter niet beide lekken. Ook memory_limit=-1 neemt volgens php.net alleen de stuurbare aanleiding weg; een geheugenfout op een dieper niveau kan het kwetsbare pad nog steeds bereiken. Op PHP 8.5 blokkeert fatal_error_backtraces=0 volgens php.net alleen de bevestigde route via backtraces.
Hoe u de instelling toch juist en duurzaam instelt, beschrijft de bijdrage session.upload_progress uitschakelen. De volledige lijst van tussentijdse maatregelen staat onder Directe maatregelen zonder patch.
Het schild ervoor
Cloudflare heeft volgens eigen opgave sinds 21 oktober beschermingsregels actief, ook voor klanten met het gratis abonnement. Cloudflare wijst zelf echter op grenzen: de bescherming werkt alleen voor verkeer dat via Cloudflare loopt. Is de oorspronkelijke server rechtstreeks bereikbaar, dan wordt ze omzeild. Bovendien beoordeelt Cloudflare aanvullend het serverantwoord, omdat het verzoek alleen niet altijd volstaat. Waarom een WAF de update niet vervangt, legt de bijdrage WAF of update uit.
Een tip met risico: uploadverzoeken aan de rand filteren
Niet elk ongemakkelijk advies is fout. Vakauteurs stellen als tijdelijke, onofficiële maatregel voor multipart/form-data-verzoeken buiten echte uploadpaden bij de proxy of in de WAF te blokkeren. Dat kan het aanvalsoppervlak verkleinen, maar breekt formulieren en uploads als de lijst met toegestane paden onvolledig is.
Wie deze weg bewandelt, moet hem vooraf in een testomgeving controleren, afstemmen met de vakafdelingen en als tijdelijke maatregel documenteren. Ook hij vervangt de update niet.
Veel WAF-oplossingen bieden hiervoor een observatiemodus, waarin regels eerst alleen loggen in plaats van blokkeren. Laat een nieuwe regel enkele dagen zo draaien en analyseer welke legitieme verzoeken zouden zijn getroffen. Pas daarna schakelt u over op blokkeren. Zo voorkomt u dat sollicitatieformulieren, klantenportalen of beeldupload in de webshop onopgemerkt uitvallen.
Zo toetst u een tip voordat u hem uitvoert
Vier vragen scheiden bruikbare van gevaarlijke adviezen:
- Bron: Komt het advies van php.net, uw distributie, het BSI of een bij naam genoemde vakauteur?
- Claim: Wordt de maatregel beschreven als overbrugging of als oplossing? Bij PHP2Shell is alleen de update een oplossing.
- Neveneffect: Wat breekt er als de maatregel werkt? Een tip zonder aanwijzing over neveneffecten is onvolledig.
- Plaats van uitvoering: Wordt de instelling aan de serverzijde en niet-overschrijfbaar gezet, gevolgd door een herstart van alle workers?
Leg vast welke tussentijdse maatregelen u wanneer hebt ingesteld. Zo kunt u ze later gericht controleren en herkennen of een vermeende bescherming de eigenlijke update heeft vertraagd.
Hoe helpt PHP SOS concreet?
- Wij controleren de maatregelen die bij u al zijn uitgevoerd en scheiden werkzame van werkingsloze.
- Wij spelen de PHP-update in, herstarten alle processen en leggen de stand vast.
- Waar een update nog niet mogelijk is, stellen wij tussentijdse maatregelen volgens php.net aan de serverzijde en gedocumenteerd in.
- Met WAF en virtueel patchen vullen wij de bescherming aan de rand aan, zonder de update te vervangen.
Veelgestelde vragen
Beschermt het om verzoeken met PHPSESSID te blokkeren?
Nee. Vakauteurs wijzen deze rondgaande tip uitdrukkelijk af. Ze legt aanmeldingen, winkelwagens en formulieren lam zonder het lek in de interpreter te dichten.
Volstaat session.upload_progress.enabled=0 tegen PHP2Shell?
Nee. De instelling is een van meerdere tussentijdse maatregelen en dicht volgens vakberichten niet beide lekken. Ze is zinvol, maar vervangt de PHP-update niet.
Helpt het display_errors uit te schakelen?
Voor PHP2Shell niet. php.net wijst erop dat het verbergen van diagnoses via error_reporting, display_errors of de @-operator niet helpt. In productie hoort display_errors om andere redenen toch uit te staan.
Waaraan herken ik een serieuze tip?
Een serieuze tip noemt zijn bron, beschrijft grenzen en benoemt tussentijdse maatregelen als zodanig. Wie belooft dat één enkele instelling de update overbodig maakt, zit bij PHP2Shell fout.