Kort sagt: Många PHP2Shell-tips som just nu cirkulerar i forum och sociala nätverk skyddar inte eller skadar till och med: blockera förfrågningar med sessionscookie, dölja felmeddelanden, sätta inställningar via .user.ini eller bara uppdatera CMS. php.net är entydigt: det finns inga fullständiga tillfälliga åtgärder, PHP-uppdateringen med omstart av alla processer är den enda säkra vägen.
Varför felaktiga tips är farliga i det här läget
Vid en kritisk sårbarhet med stor uppmärksamhet uppstår en marknad för snabba lösningar. Råd delas, förkortas och förs vidare, ofta utan den ursprungliga källans förbehåll. Vid PHP2Shell tillkommer att detaljer enligt rapporter blev kända redan före den officiella tidpunkten och att läget var oöverskådligt under de första dagarna.
Ett felaktigt tips skadar dubbelt. Det lämnar sårbarheten öppen och skapar känslan av att ha gjort något. Just den känslan leder till att den egentliga uppdateringen blir liggande. Vissa råd lamslår dessutom den egna webbplatsen.
Nio råd i faktakoll
Tabellen nedan sammanfattar vad vi ofta har läst de senaste dagarna och ställer primärkällornas uppgifter mot det.
| Cirkulerande tips | Varför det inte håller | Vad som gäller i stället |
|---|---|---|
Blockera alla förfrågningar med PHPSESSID |
Uttryckligen avvisat av fackskribenter; lamslår inloggningar och varukorgar | Uppdatera PHP |
session.upload_progress.enabled=0 räcker |
Stänger enligt facktidningarna inte båda sårbarheterna | Rimlig tillfällig åtgärd, uppdateringen förblir ett krav |
Sätta värden via ini_set() eller .user.ini |
php.net avråder uttryckligen | På serversidan i php.ini, FPM-pool eller serverkonfiguration |
| Dölja felmeddelanden | Enligt php.net hjälper error_reporting, display_errors eller @ inte |
Uppdatering; visa ändå inte felutskrift offentligt |
Begränsa minnet via RLIMIT_AS eller RLIMIT_DATA |
php.net varnar för att just det kan utlösa det sårbara läget | Gräns via container eller cgroup |
| Uppdatera WordPress eller tillägg | Sårbarheten ligger i PHP-tolken, inte i CMS | Uppdatera PHP-körmiljön |
| Cloudflare eller en annan WAF räcker | Skydd bara för trafik via tjänsten; direkt nåbara servrar förblir öppna | WAF som extra lager, inte som ersättning |
| Ladda om tjänsten i stället för att starta om | Enligt Red Hat räcker inte en omladdning, befintliga workers kan behålla det gamla tillståndet | Starta om alla workers fullständigt |
| Patchad betyder ren | En patch tar inte bort skadlig programvara som tidigare smugits in | Säkra loggar från 20.10. och kontrollera spår |
De tre vanligaste misstagen närmare förklarade
Cookie-förbudet
Tipset att avvisa alla förfrågningar med sessionscookien PHPSESSID låter tekniskt och beslutsamt. Fackskribenter avvisar det uttryckligen. I praktiken bryter det allt som behöver en session: kundkonton, varukorgar, adminområden, formulär med skydd mot förfalskning. Ett skydd mot sårbarheten är det inte.
Den ena inställningen som löser allt
session.upload_progress.enabled=0 står i php.nets rekommendationer och är den angivna åtgärden mot CVE-2026-115560. Av det blev i vissa inlägg ”PHP2Shell avstängt”. Enligt facktidningarna stänger den inställningen ensam dock inte båda sårbarheterna. Även memory_limit=-1 undanröjer enligt php.net bara den styrbara utlösaren; ett minnesfel på djupare nivå kan fortfarande nå den sårbara vägen. På PHP 8.5 blockerar fatal_error_backtraces=0 enligt php.net bara den bekräftade vägen via backtraces.
Hur ni ändå sätter inställningen rätt och varaktigt beskriver inlägget Stänga av session.upload_progress. Den fullständiga listan över tillfälliga åtgärder står under Omedelbara åtgärder utan patch.
Skölden framför
Cloudflare har enligt egna uppgifter haft skyddsregler aktiva sedan den 21 oktober, även för kunder i gratisabonnemanget. Cloudflare påpekar dock själv gränser: skyddet gäller bara trafik som går via Cloudflare. Är ursprungsservern direkt nåbar kringgås det. Dessutom granskar Cloudflare också serverns svar, eftersom förfrågan ensam inte alltid räcker. Varför en WAF inte ersätter uppdateringen förklarar inlägget WAF eller uppdatering.
Ett tips med risk: filtrera uppladdningsförfrågningar i kanten
Inte varje obekvämt råd är fel. Fackskribenter föreslår som tillfällig, inofficiell åtgärd att blockera multipart/form-data-förfrågningar utanför riktiga uppladdningssökvägar i proxyn eller WAF. Det kan minska angreppsytan, men bryter formulär och uppladdningar om listan över tillåtna sökvägar är ofullständig.
Den som går den vägen bör först pröva den i en testmiljö, stämma av med fackavdelningarna och dokumentera den som tidsbegränsad åtgärd. Inte heller den ersätter uppdateringen.
Många WAF-lösningar erbjuder ett observationsläge där regler först bara loggar i stället för att blockera. Låt en ny regel köra så i några dagar och utvärdera vilka legitima förfrågningar som skulle ha berörts. Först därefter växlar ni till blockering. Så undviker ni att ansökningsformulär, kundportaler eller bilduppladdning i butiken obemärkt slutar fungera.
Så granskar ni ett tips innan ni genomför det
Fyra frågor skiljer användbara råd från farliga:
- Källa: Kommer rekommendationen från php.net, er distribution, BSI (den tyska federala myndigheten för informationssäkerhet) eller en namngiven fackskribent?
- Anspråk: Beskrivs åtgärden som övergång eller som lösning? Vid PHP2Shell är bara uppdateringen en lösning.
- Biverkning: Vad går sönder när åtgärden slår till? Ett tips utan upplysning om biverkningar är ofullständigt.
- Genomförandeplats: Sätts inställningen på serversidan så att den inte kan skrivas över, följt av en omstart av alla workers?
Anteckna vilka tillfälliga åtgärder ni har satt och när. Så kan ni senare granska dem riktat och se om ett förmodat skydd har försenat den egentliga uppdateringen.
Hur hjälper PHP SOS konkret?
- Vi granskar de åtgärder som redan har genomförts hos er och skiljer verksamma från verkningslösa.
- Vi installerar PHP-uppdateringen, startar om alla processer och styrker läget.
- Där en uppdatering ännu inte är möjlig sätter vi tillfälliga åtgärder enligt php.net på serversidan och dokumenterade.
- Med WAF och virtuell patchning kompletterar vi skyddet i kanten utan att ersätta uppdateringen.
Vanliga frågor
Skyddar det att blockera förfrågningar med PHPSESSID?
Nej. Fackskribenter avvisar uttryckligen det här cirkulerande tipset. Det lamslår inloggningar, varukorgar och formulär utan att stänga sårbarheten i tolken.
Räcker session.upload_progress.enabled=0 mot PHP2Shell?
Nej. Inställningen är en av flera tillfälliga åtgärder och stänger enligt facktidningarna inte båda sårbarheterna. Den är rimlig men ersätter inte PHP-uppdateringen.
Hjälper det att stänga av display_errors?
Inte mot PHP2Shell. php.net påpekar att det inte hjälper att dölja diagnoser via error_reporting, display_errors eller @-operatorn. I produktion bör display_errors av andra skäl ändå vara avstängt.
Hur känner jag igen ett seriöst tips?
Ett seriöst tips anger sin källa, beskriver gränser och betecknar tillfälliga åtgärder som sådana. Den som lovar att en enskild inställning gör uppdateringen överflödig har fel när det gäller PHP2Shell.