Kort sagt: Cloudflare har efter egne oplysninger siden den 21. oktober 2026 kl. 03:02 UTC haft beskyttelsesregler mod PHP2Shell aktive, også for kunder i den gratis plan. Reglerne sænker risikoen for trafik, der løber via Cloudflare. De virker ikke, hvis oprindelsesserveren er direkte tilgængelig, og de erstatter ikke PHP-opdateringen. Den, der bruger Cloudflare, bør kontrollere regeltilstand, beskyttelse af oprindelsen og patchstatus.
Udgangspunktet: beskyttelse allerede før patchen
Cloudflare var usædvanlig tidligt ude ved PHP2Shell. Ifølge Cloudflare-bloggen kørte beskyttelsesreglerne allerede flere timer før den officielle udgivelse af PHP-opdateringerne kl. 14:00 UTC. Cloudflare rapporterede desuden at have observeret angrebsforsøg mod kunder og at angribere ændrede deres mønstre for at omgå reglerne.
Mange driftsansvarlige har heraf sluttet: „Vi sidder bag Cloudflare, så vi er beskyttet.“ Det passer kun delvist. Dette indlæg forklarer, hvad reglerne faktisk dækker. En generel afvejning mellem firewall og opdatering giver indlægget WAF eller opdatering?.
Hvad Cloudflare har udrullet mod PHP2Shell
Ifølge oplysningerne i Cloudflare-bloggen er der tre byggesten:
| Plan | Beskyttelse ifølge Cloudflare | Hvad I bør gøre |
|---|---|---|
| Free | nye regler i Managed Free Ruleset, automatisk aktive | kontrollér, at domænet løber via Cloudflare |
| Pro, Business, Enterprise | passende regler i Managed Ruleset | sørg for, at rulesettet står på „Block“ |
| alle planer | standardregel i den nye response-firewall | slå intet fra, observér hændelser |
Den tredje byggesten er ny. Cloudflare kalder den „full transaction detection“: WAF'en ser ikke kun på forespørgslen, men også på serverens svar. Begrundelsen ifølge Cloudflare: Forespørgslen alene er ikke altid nok til sikkert at skelne et angreb fra normal trafik. PHP2Shell er den første anvendelse af denne funktion i de administrerede regler.
Grænserne for Cloudflares regler
Så nyttige reglerne er, har de klare grænser, som Cloudflare til dels selv nævner:
- Kun trafik via Cloudflare: Reglerne kontrollerer det, der flyder gennem Cloudflare. Er oprindelsesserveren direkte tilgængelig på sin IP-adresse, kan en angriber omgå beskyttelsen.
- Ingen mulighed for at gøre ugjort: Ifølge Cloudflare kan en regel på svarsiden tilbageholde svaret, men ikke gøre ugjort, hvad der allerede er sket på serveren.
- Skiftende angrebsmønstre: Cloudflare tilpasser løbende reglerne, fordi angribere ændrer deres forespørgsler. Mellem en ny variant og en ny regel kan der ligge et hul.
- Ingen erstatning for opdateringen: Cloudflare anbefaler udtrykkeligt at opdatere PHP trods WAF. En opdatering af applikationskode eller plugins udbedrer heller ikke sårbarhederne.
- Særtilfældet CVE-2026-115560: Ifølge Cloudflares tilføjelse fra den 23. oktober virker reglen ikke, hvis navnet på session upload progress er ændret i konfigurationen. Mere om denne meddelelse under CVE-2026-115560.
Hvad blokerede forespørgsler siger, og hvad de ikke siger
Efter meddelelsen kigger mange kunder i deres sikkerhedshændelser og finder dér blokerede forespørgsler. Det viser først og fremmest blot, at jeres domæne blev kontrolleret, og at reglen greb ind. Et indbrud er dermed ikke dokumenteret. Omvendt er en tom hændelsesliste ingen afblæsning: Løb et angreb direkte mod oprindelsesserveren eller før den 21. oktober, dukker det slet ikke op hos Cloudflare.
Mere pålideligt er afstemningen med selve webserverens logs. Forespørgsler, der ankommer dér, men ikke stammer fra Cloudflare-adresser, tyder på direkte adgang. Sikr disse logs fra og med den 20. oktober, som fagpressen anbefaler. Cloudflare gør desuden opmærksom på, at begrænsninger for uploads kan mindske risikoen, men ikke erstatter PHP-opdateringen.
Den hyppigste svaghed bag Cloudflare er ikke reglen, men vejen uden om den: en oprindelsesserver, der svarer direkte på sin IP-adresse eller via et ubeskyttet subdomæne.
Kontrolliste for Cloudflare-kunder
Disse trin kan I eller jeres serviceudbyder klare på kort sigt:
- Kontrollér plan og regeltilstand: Ved betalte planer kontrolleres i dashboardet, at Managed Ruleset er aktivt i tilstanden „Block“.
- Se sikkerhedshændelserne igennem: Under Security Events kontrolleres, om der dukker blokerede forespørgsler op. Det viser, om jeres domæner allerede har været mål.
- Gennemgå DNS-poster: Enhver post, der peger på webserveren, men ikke løber via Cloudflare, er en mulig omvej. Typiske er subdomæner til staging, FTP eller mail på den samme server.
- Luk oprindelsen af: Konfigurér webserveren, så den kun modtager HTTP og HTTPS fra Cloudflare, f.eks. via firewall med de adresseområder, Cloudflare offentliggør, eller via en tunnel. Hvordan det generelt gøres, beskriver indlægget Firewall til webserver.
- Test direkte adgang: Kontrollér udefra, om oprindelsen svarer uden Cloudflare.
- Opdatér PHP, og genstart: Reglerne er anden linje. Første linje er PHP på en rettet version med genstart af alle PHP-processer.
Til trin 5 er en harmløs test nok, der kun forespørger hovedlinjerne. IP-adressen er en pladsholder for jeres oprindelsesserver:
# Svarer oprindelsesserveren direkte, uden om Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Kommer der her et almindeligt svar fra jeres website, er oprindelsen direkte tilgængelig, og Cloudflare-beskyttelsen kan omgås.
Hvordan hjælper PHP SOS konkret?
- Konfigurationskontrol: Vi kontrollerer regeltilstand, DNS-poster og den direkte adgang til oprindelsesserveren.
- Sikring af oprindelsen: Vi begrænser webserveren til trafik via Cloudflare uden at afbryde jeres website.
- Patch og dokumentation: Vi opdaterer PHP, genstarter alle processer og dokumenterer status.
- Vurdering af hændelser: Vi gennemgår blokerede forespørgsler og afstemmer dem med serverlogs.
Hvordan vi kombinerer WAF-regler og midlertidige foranstaltninger, beskriver WAF og virtuel patching.
Konklusion
Cloudflares regler mod PHP2Shell er en reel gevinst, især fordi de kom tidligt og også i den gratis plan. De er dog et skjold foran døren, ikke en lås i døren. Den, der sidder bag Cloudflare, bør sikre tre ting: regler i Block-tilstand, ingen vej uden om proxyen og PHP på en rettet version.
Ofte stillede spørgsmål
Er jeg beskyttet mod PHP2Shell med den gratis Cloudflare-plan?
Ifølge Cloudflare får også Free-kunder beskyttelsesreglerne automatisk. De virker dog kun for trafik, der løber via Cloudflare, og erstatter ikke PHP-opdateringen på serveren. Er oprindelsesserveren direkte tilgængelig, virker beskyttelsen ikke.
Hvad skal jeg indstille ved betalte Cloudflare-planer?
Cloudflare anbefaler kunder med Pro-, Business- og Enterprise-plan at kontrollere, at Managed Ruleset kører i tilstanden Block. Står det kun på logning, bliver angreb registreret, men ikke stoppet.
Hvad er full transaction detection?
En ny funktion i Cloudflare-WAF'en, som ikke kun ser på forespørgslen, men også på serverens svar. Dermed kan man opdage, om et angrebsforsøg har virkning, og svaret kan tilbageholdes. Hvad der allerede er udført på serveren, gør den ifølge Cloudflare ikke ugjort.
Dækker Cloudflare også CVE-2026-115560?
Cloudflare supplerede sit indlæg den 23. oktober om CVE-2026-115560. Ifølge Cloudflare virker den tilhørende regel ikke, hvis navnet på session upload progress er ændret i PHP-konfigurationen. Uafhængigt heraf anbefaler php.net at sætte session.upload_progress.enabled=0.