Kort sagt: Virtuell patchning för PHP överbryggar tiden tills den riktiga uppdateringen är installerad. Vi kombinerar regler i en Web Application Firewall med de övergångsåtgärder som php.net har publicerat om PHP2Shell, och fastställer genast vägen till den ordinarie patchen. Fullständigt skydd ger det inte, men det minskar risken under övergångstiden.
När virtuell patchning för PHP är meningsfull
BSI (Tysklands federala myndighet för informationssäkerhet) rekommenderar vid PHP2Shell omedelbar uppdatering och, om det inte går, att tillfälligt ta webbservrarna från nätet. För många företag är ingetdera genomförbart genast: En butik måste förbli nåbar, en egenutveckling behöver ett test före uppdateringen, eller så körs servern med PHP 8.1 och äldre, för vilka det inte längre finns officiella uppdateringar.
I dessa fall är virtuell patchning en brygga. Den ersätter inte beslutet om offlinedrift vore lämpligare. Den avvägningen gör ni, vi levererar den tekniska bedömningen.
Varför en WAF ensam inte räcker
Cloudflare rapporterade observerade angreppsförsök och har rullat ut skyddsregler, men varnar för att regler baserade enbart på förfrågningsdata inte räcker. Orsaken ligger i sårbarheternas karaktär. Vid CVE-2026-109618 kan ett out-of-memory-tillstånd avbryta PHP medan förfrågningsdata bara är delvis initierade. Vid CVE-2026-109619 kan internt tillstånd finnas kvar efter att minne frigjorts och användas av en senare förfrågan i samma worker. Sådana fel beror på serverns tillstånd, inte bara på innehållet i en enskild förfrågan.
Därför satsar vi på flera lager: WAF-regler framför servern, övergångsåtgärder i själva PHP och en förstärkt observation av servern. Varje lager fångar upp en del, inget räcker ensamt. Tillsammans ger de er tid att installera uppdateringen ordnat.
Övergångsåtgärderna enligt php.net
php.net anger flera inställningar som sänker risken, uttryckligen utan fullständigt skydd. Viktigt är att applikationer inte kan skriva över dessa värden. Ett exempel på en PHP-FPM-pool med uppladdningar:
; övergångsåtgärder PHP2Shell (inget fullständigt skydd), starta därefter om alla workers
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; bara PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Utan uppladdningar rekommenderar php.net post_max_size = 8M. Eftersom memory_limit upphävs hör en minnesgräns på container- eller cgroup-nivå till, inte via RLIMIT_AS eller RLIMIT_DATA. Inställningen session.upload_progress.enabled=0 hör hemma i php.ini, FPM-pool eller serverkonfiguration, inte i ini_set() eller .user.ini. Den är samtidigt åtgärden för anvisningen om CVE-2026-115560. Alla åtgärder i överblick finns under Akutåtgärder om ni ännu inte kan patcha.
Övergångsåtgärder verkar först efter en omstart av alla PHP-workers. Och de skyddar bara mot framtida angrepp: Om någon redan har tagit sig in besvarar de inte.
När offlinedrift är det bättre valet
Virtuell patchning är inte i varje läge det rätta svaret. I vissa konstellationer råder vi att följa BSI och tillfälligt ta webbservern från nätet tills den är patchad:
- servern körs med Apache och mod_php, där PHP-teamet bedömer risken som högst och en exploit har visats redan innan någon applikationskod körs
- på servern ligger särskilt skyddsvärda data, till exempel hälso-, klient- eller betalningsuppgifter
- det finns ingen möjlighet att lägga fast övergångsåtgärderna i serverkonfigurationen, till exempel vid vissa paket för delat webbhotell
- det finns redan tecken på att servern har angripits
En tillfällig offlinedrift betyder inte att er webbplats har hackats. Några leverantörer har tagit webbplatser offline av försiktighet. En kort, saklig informationssida för besökare är då oftast en bättre lösning än ett oförklarat avbrott.
Hur hjälper PHP SOS konkret?
- Pröva läget: Vi kartlägger PHP-versioner, driftlägen och befintliga skyddslager som CDN, WAF eller reverse proxy. Vid mod_php pekar vi på den förhöjda risk som PHP-teamet ser där.
- Bygga lager: Vi aktiverar eller kompletterar WAF-regler, lägger fast övergångsåtgärderna i serverkonfigurationen och begränsar minnet via container eller cgroup. För Nginx-miljöer utgår vi från Säkra Nginx med PHP-FPM.
- Omstart och test: Alla PHP-processer startas om, därefter kontrollerar vi uppladdningar, formulär, inloggning och kassa.
- Observera: Under övergångstiden är vi extra uppmärksamma på kraschade workers, minnestoppar och ovanliga processer.
- Planera patchen: Vi fastställer när och hur den ordinarie uppdateringen kommer och genomför den via PHP-patchtjänsten.
Vad ni får, vad vi behöver och vad vi inte lovar
Ni får en dokumentation av alla inställda regler och inställningar med motivering, testresultaten och en tids- och åtgärdsplan för den riktiga patchen. Från er behöver vi server- eller panelåtkomst, åtkomst till CDN eller WAF om sådan finns, en teknisk kontaktperson och uppgifter om uppladdningsfunktioner i era applikationer.
Vi lovar inte att virtuell patchning förhindrar ett angrepp. Den sänker risken under en begränsad tid. Vid PHP 8.1 och äldre är den inget permanent tillstånd; här hör migreringen till en version med support till planen.
Vanliga frågor
Vad är virtuell patchning?
Virtuell patchning innebär att avskärma en känd sårbarhet framför applikationen i stället för att ändra själva koden. Det sker oftast via en Web Application Firewall eller konfigurationsändringar. Det är en överbryggning, ingen ersättning för uppdateringen.
Räcker min CDN-leverantörs WAF mot PHP2Shell?
Ensam i regel inte. Cloudflare har rullat ut skyddsregler men varnar själva för att regler baserade enbart på förfrågningsdata inte räcker. WAF:en är ett extra lager vid sidan av övergångsåtgärder och patch.
Hur länge får jag förlita mig på virtuell patchning?
Så kort tid som möjligt. Den ska överbrygga tiden fram till den ordinarie uppdateringen, till exempel tills ett underhållsfönster är ledigt eller en applikation har testats. Vid PHP 8.1 och äldre hör en migreringsplan till.
Kan övergångsåtgärderna störa min webbplats?
Ja, det är möjligt. Lägre uppladdningsgränser kan förhindra stora filuppladdningar, och avstängning av session upload progress påverkar förloppsindikatorer vid uppladdning. Vi testar de viktigaste funktionerna efter varje ändring.