Kort sagt: Cloudflare har enligt egna uppgifter sedan den 21 oktober 2026, kl. 03:02 UTC, haft skyddsregler mot PHP2Shell aktiva, även för kunder i gratisabonnemanget. Reglerna sänker risken för trafik som går via Cloudflare. De verkar inte om ursprungsservern är direkt nåbar, och de ersätter inte PHP-uppdateringen. Den som använder Cloudflare bör kontrollera regelläge, ursprungsskydd och patchnivå.
Utgångspunkten: skydd redan före patchen
Cloudflare var ovanligt tidigt ute vid PHP2Shell. Enligt Cloudflare-bloggen var skyddsreglerna aktiva flera timmar före den officiella publiceringen av PHP-uppdateringarna kl. 14:00 UTC. Cloudflare rapporterade dessutom att man observerat angreppsförsök mot kunder och att angripare ändrade sina mönster för att kringgå reglerna.
Många driftansvariga har dragit slutsatsen: ”Vi ligger bakom Cloudflare, alltså är vi skyddade.” Det stämmer bara delvis. Den här artikeln förklarar vad reglerna faktiskt täcker. En allmän avvägning mellan brandvägg och uppdatering ger inlägget WAF eller uppdatering?.
Vad Cloudflare har rullat ut mot PHP2Shell
Enligt uppgifter i Cloudflare-bloggen finns tre byggstenar:
| Abonnemang | Skydd enligt Cloudflare | Vad ni bör göra |
|---|---|---|
| Free | nya regler i Managed Free Ruleset, automatiskt aktiva | kontrollera att domänen går via Cloudflare |
| Pro, Business, Enterprise | passande regler i Managed Ruleset | säkerställ att regeluppsättningen står på ”Block” |
| alla abonnemang | standardregel i den nya svarsbrandväggen | stäng inte av något, bevaka händelser |
Den tredje byggstenen är ny. Cloudflare kallar den ”full transaction detection”: WAF tittar inte bara på förfrågan utan även på serverns svar. Skälet enligt Cloudflare: förfrågan ensam räcker inte alltid för att säkert skilja ett angrepp från normal trafik. PHP2Shell är den första användningen av funktionen i de hanterade reglerna.
Gränserna för Cloudflares regler
Hur hjälpsamma reglerna än är har de tydliga gränser, som Cloudflare delvis själv nämner:
- Bara trafik via Cloudflare: Reglerna granskar det som flödar genom Cloudflare. Om ursprungsservern är direkt nåbar via sin IP-adress kan en angripare kringgå skyddet.
- Går inte att ångra: Enligt Cloudflare kan en regel på svarssidan hålla tillbaka svaret men inte göra ogjort det som redan har hänt på servern.
- Växlande angreppsmönster: Cloudflare anpassar reglerna löpande eftersom angripare ändrar sina förfrågningar. Mellan en ny variant och en ny regel kan det finnas ett glapp.
- Ingen ersättning för uppdateringen: Cloudflare rekommenderar uttryckligen att uppdatera PHP trots WAF. Inte heller en uppdatering av applikationskod eller tillägg åtgärdar sårbarheterna.
- Specialfall CVE-2026-115560: Enligt Cloudflares komplettering den 23 oktober verkar regeln inte om namnet för Session-Upload-Progress har ändrats i konfigurationen. Mer om det meddelandet under CVE-2026-115560.
Vad blockerade förfrågningar säger och inte säger
Många kunder tittar efter meddelandet i sina säkerhetshändelser och hittar där blockerade förfrågningar. Det visar först och främst bara att er domän har granskats och att regeln har gripit in. Något intrång är därmed inte belagt. Omvänt är en tom händelselista ingen avblåsning: om ett angrepp gick direkt mot ursprungsservern eller före den 21 oktober syns det inte alls hos Cloudflare.
Tillförlitligare är avstämningen mot webbserverns egna loggar. Förfrågningar som anländer dit men inte kommer från Cloudflare-adresser tyder på en direkt åtkomst. Säkra de loggarna från och med den 20 oktober, som facktidningarna rekommenderar. Cloudflare påpekar dessutom att begränsningar för uppladdningar kan minska risken men inte ersätta PHP-uppdateringen.
Den vanligaste svagheten bakom Cloudflare är inte regeln utan vägen förbi den: en ursprungsserver som svarar direkt via sin IP-adress eller via en oskyddad underdomän.
Kontrolllista för Cloudflare-kunder
De här stegen kan ni eller er leverantör genomföra på kort sikt:
- Kontrollera abonnemang och regelläge: Vid betalda abonnemang, kontrollera i dashboarden att Managed Ruleset är aktivt i läget ”Block”.
- Titta på säkerhetshändelserna: Under Security Events, kontrollera om blockerade förfrågningar dyker upp. Det visar om era domäner redan har varit mål.
- Gå igenom DNS-posterna: Varje post som pekar på webbservern men inte går via Cloudflare är en möjlig omväg. Typiskt är underdomäner för staging, FTP eller e-post på samma server.
- Stäng av ursprunget: Konfigurera webbservern så att den bara tar emot HTTP och HTTPS från Cloudflare, till exempel via brandvägg med de adressintervall som Cloudflare publicerar eller via en tunnel. Hur det går till i allmänhet beskriver inlägget Brandvägg för webbserver.
- Testa direktåtkomst: Kontrollera utifrån om ursprunget svarar utan Cloudflare.
- Uppdatera PHP och starta om: Reglerna är andra linjen. Den första är PHP på en åtgärdad nivå med omstart av alla PHP-processer.
För steg 5 räcker ett ofarligt test som bara hämtar rubrikraderna. IP-adressen är en platshållare för er ursprungsserver:
# Svarar ursprungsservern direkt, förbi Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Kommer här ett regelrätt svar från er webbplats är ursprunget direkt nåbart och Cloudflare-skyddet går att kringgå.
Hur hjälper PHP SOS konkret?
- Konfigurationskontroll: Vi kontrollerar regelläge, DNS-poster och den direkta åtkomsten till ursprungsservern.
- Säkra ursprunget: Vi begränsar webbservern till trafik via Cloudflare utan att avbryta er webbplats.
- Patch och bevis: Vi uppdaterar PHP, startar om alla processer och dokumenterar läget.
- Värdera händelser: Vi går igenom blockerade förfrågningar och stämmer av dem mot serverloggarna.
Hur vi kombinerar WAF-regler och tillfälliga åtgärder beskriver WAF och virtuell patchning.
Slutsats
Cloudflares regler mot PHP2Shell är en verklig vinst, särskilt eftersom de kom tidigt och även i gratisabonnemanget. Men de är en sköld framför dörren, inte ett lås i dörren. Den som sitter bakom Cloudflare bör säkerställa tre saker: regler i Block-läge, ingen väg förbi proxyn och PHP på en åtgärdad nivå.
Vanliga frågor
Är jag skyddad mot PHP2Shell med Cloudflares gratisabonnemang?
Enligt Cloudflare får även Free-kunder skyddsreglerna automatiskt. De verkar dock bara för trafik som går via Cloudflare och ersätter inte PHP-uppdateringen på servern. Om ursprungsservern är direkt nåbar gäller inte skyddet.
Vad måste jag ställa in vid betalda Cloudflare-abonnemang?
Cloudflare rekommenderar kunder med Pro-, Business- och Enterprise-abonnemang att kontrollera att Managed Ruleset körs i läget Block. Står det bara på loggning registreras angrepp men stoppas inte.
Vad är full transaction detection?
En ny funktion i Cloudflares WAF som tittar inte bara på förfrågan utan även på serverns svar. Så går det att se om ett angreppsförsök får effekt, och svaret kan hållas tillbaka. Det som redan har körts på servern görs enligt Cloudflare inte ogjort.
Täcker Cloudflare även CVE-2026-115560?
Cloudflare kompletterade sitt inlägg den 23 oktober om CVE-2026-115560. Enligt Cloudflare verkar motsvarande regel inte om namnet för Session-Upload-Progress har ändrats i PHP-konfigurationen. Oberoende av det rekommenderar php.net att sätta session.upload_progress.enabled=0.