Kort sagt: WAF i stället för uppdatering fungerar inte vid PHP2Shell. En webbapplikationsbrandvägg (Web Application Firewall), alltså ett filter framför webbplatsen, granskar förfrågningar och kan blockera kända angreppsmönster. Själva luckan sitter dock i PHP-tolken och försvinner först med uppdateringen och omstarten av alla PHP-processer. En WAF är ett rimligt extra skikt och en bro för några dagar, inte lösningen.
Varför frågan ställs så ofta just nu
Många driftansvariga läste under PHP2Shell-veckan ett till synes gott nyhetsbesked: Cloudflare har enligt egna uppgifter sedan 21.10.2026, 03:02 UTC, aktiva skyddsregler, även för kunder med gratisabonnemang. Den som ändå står bakom Cloudflare eller en annan WAF frågar sig förståeligt nog om uppdateringen då fortfarande är brådskande.
Det ärliga svaret är ja. Cloudflare själv gör en inskränkning: Regler som bara utgår från förfrågningsdata räcker inte, därför granskar tjänsten dessutom serverns svar. Cloudflare har dessutom observerat förändrade angreppsmönster. Och skyddet verkar bara för trafik som faktiskt går via Cloudflare. Detaljerna om den leverantören beskriver Cloudflares skyddsregler mot PHP2Shell. Här handlar det om den principiella avvägningen, oberoende av leverantör.
Vad en WAF ser och vad en uppdatering ändrar
En WAF sitter framför applikationen. Den ser varje förfrågan, jämför den med regler och släpper igenom, blockerar eller loggar den. Den vet inte hur PHP internt behandlar förfrågan. De båda PHP2Shell-luckorna uppstår dock just där: CVE-2026-109618 vid ett out-of-memory-tillstånd medan förfrågningsdata bara delvis är initierade, CVE-2026-109619 genom internt tillstånd som består efter en förfrågan i samma worker.
Uppdateringen rättar den koden. Därefter är orsaken undanröjd, oavsett hur en förfrågan ser ut. Den som vill förstå var i förloppet för en förfrågan detta sker hittar grunderna under Förfrågans livscykel i PHP.
WAF i stället för uppdatering: den ärliga jämförelsen
| Kriterium | Webbapplikationsbrandvägg | PHP-uppdatering med omstart |
|---|---|---|
| Vad åtgärdas? | Ingenting, kända mönster fångas upp | Orsaken i PHP-tolken |
| Skydd mot nya angreppsvarianter | Bara om reglerna anpassas i tid | Ja, luckan finns inte längre |
| Kan den kringgås? | Ja, till exempel via direkt nåbarhet till ursprungsservern | Nej, såvida alla PHP-processer är omstartade |
| Snabbhet | Ofta aktiv direkt | Beror på version, åtkomst och underhållsfönster |
| Biverkningar | Falsklarm, störda formulär eller uppladdningar | Sällan, vid versionshopp krävs kompatibilitetstester |
| Nytta vid nästa lucka | Hög, om den underhålls | Ingen, varje lucka kräver sin egen uppdatering |
| Hjälper den vid PHP 8.1 och äldre? | Som övergång | Bara via backport eller migrering |
Tabellen visar varför båda åtgärderna hör ihop. WAF:en är snabb och bred, men aldrig fullständig. Uppdateringen är fullständig, men bara för en viss lucka och inte alltid möjlig direkt.
En punkt förbises ofta i praktiken: En WAF förändrar webbplatsens beteende. Stränga regler kan blockera legitima beställningar, kontaktformulär eller filuppladdningar utan att någon märker det direkt. Den som skarpställer en WAF i en kris bör därför själv klicka igenom webbplatsens viktigaste förlopp en gång och granska loggarna för de första dagarna efter blockerade men berättigade förfrågningar.
Så kombinerar ni båda på ett rimligt sätt
- Direkt: Kontrollera om det finns en WAF och om rätt regler är aktiva. Vid Cloudflare i betalda abonnemang enligt leverantören ställ Managed Ruleset på Block.
- Direkt: Se till att ursprungsservern bara kan nås via WAF:en, till exempel genom en brandväggsfrigivning enbart för dess adressintervall. Annars löper skyddet ut i tomma intet.
- Inom nästa underhållsfönster: Uppdatera PHP till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller installera distributionens bekräftade backport.
- Direkt därefter: Starta om alla PHP-workers och processer och kontrollera att ingen gammal process längre körs. Nya filer ensamma räcker inte; mer om det under Efter uppdateringen: starta om PHP-FPM och alla workers.
- Därefter: Behåll WAF-reglerna, utvärdera falsklarm och sätt undantag riktat i stället för att stänga av regler generellt.
Med en egen WAF baserad på ModSecurity och OWASP Core Rule Set går det att åstadkomma något liknande; grunderna beskriver Använda ModSecurity och OWASP Core Rule Set. En specialform är den av fackförfattare föreslagna filtreringen av uppladdningsförfrågningar utanför riktiga uppladdningssökvägar. Den är inofficiell, kan bryta formulär och hör bara hemma i drift efter test.
Varken WAF eller uppdatering tar bort skadlig kod som smugits in tidigare. Kontrollera efter patchen om det har förekommit avvikelser sedan 17.10.2026.
När ni inte behöver någon WAF och när ingen leverantör
En WAF är inte obligatorisk för varje webbplats. En liten företagswebbplats hos en hostingleverantör som patchar PHP i god tid och bekräftar det är ofta tillräckligt skyddad utan egen WAF, om CMS och tillägg är aktuella. Även den som själv kan uppdatera sin server inom kort tid behöver inte WAF:en som bro.
Den blir rimlig vid webbshoppar, portaler och applikationer med många formulär, vid äldre system som inte kan uppdateras direkt och där flera webbplatser ska skyddas centralt. En leverantör behöver ni för det bara om inrättande, tester och löpande underhåll inte täcks internt.
Hur hjälper PHP SOS konkret?
- Vi prövar om er WAF verkligen sitter framför alla ingångar och om ursprungsservern kan nås direkt.
- Vi inrättar eller anpassar regler och testar formulär, uppladdningar och gränssnitt med avseende på biverkningar.
- Vi installerar PHP-uppdateringen, startar om alla processer och dokumenterar läget.
- Där uppdateringen dröjer överbryggar vi med WAF och virtuell patchning och ett fast datum för den riktiga patchen.
Slutsats
Frågan ”WAF eller uppdatering” är felställd. Uppdateringen stänger luckan, WAF:en köper tid och fångar mycket annat. Den som bara satsar på WAF litar på regler som angripare kan kringgå. Den som bara patchar står vid nästa lucka åter utan bro.
Vanliga frågor
Räcker en WAF som skydd mot PHP2Shell?
Nej. En WAF granskar trafiken och kan blockera kända angreppsmönster. Själva luckan sitter i PHP-tolken och kvarstår tills PHP har uppdaterats och startats om. Cloudflare understryker uttryckligen att dess regler inte ersätter uppdateringen.
Är jag automatiskt skyddad bakom Cloudflare?
Bara för den trafik som faktiskt går via Cloudflare. Om ursprungsservern kan nås direkt från internet kringgås skyddet. Med betalda abonnemang bör ni enligt Cloudflare kontrollera att Managed Ruleset står på Block.
Lönar sig en WAF även efter uppdateringen?
Ofta ja. En WAF kan fånga massskanningar, kända angrepp mot tillägg och missbruk av inloggningssidor och ger tid vid nästa lucka. Den kräver dock underhåll och tester, annars stör falsklarm driften.
Vad är virtuell patchning?
Med det avses att tillfälligt avskärma en sårbarhet med regler framför applikationen i stället för att ändra koden. Det är en bro fram till den riktiga uppdateringen, ingen ersättning.