# WAF eller opdatering: Hvorfor I har brug for begge dele

> WAF i stedet for opdatering ved PHP2Shell? Hvad en Web Application Firewall kan, hvor den ender, og hvorfor kun PHP-opdateringen med genstart lukker sårbarheden.

Kilde: https://phpsos.de/da/blog/waf-oder-update/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** WAF i stedet for opdatering fungerer ikke ved PHP2Shell. En Web Application Firewall, altså et filter foran websitet, kontrollerer forespørgsler og kan blokere kendte angrebsmønstre. Selve sårbarheden sidder dog i PHP-fortolkeren og forsvinder først med opdateringen og genstarten af alle PHP-processer. En WAF er et fornuftigt ekstra lag og en bro i nogle få dage, ikke løsningen.

## Hvorfor spørgsmålet stilles så ofte netop nu

Mange driftsansvarlige har i PHP2Shell-ugen læst en tilsyneladende god nyhed: Cloudflare har ifølge egne oplysninger siden 21.10.2026 kl. 03:02 UTC beskyttelsesregler aktive, også for kunder i det gratis abonnement. Den, der alligevel står bag Cloudflare eller en anden WAF, spørger forståeligt nok, om opdateringen så stadig haster.

Det ærlige svar er ja. Cloudflare selv indskrænker: Regler alene ud fra forespørgselsdata er ikke nok, derfor kontrollerer tjenesten desuden serverens svar. Cloudflare har desuden observeret ændrede angrebsmønstre. Og beskyttelsen virker kun for trafik, der faktisk løber via Cloudflare. Enkeltheder om denne udbyder beskriver [Cloudflares beskyttelsesregler mod PHP2Shell](https://phpsos.de/da/blog/cloudflare-waf-php2shell/). Her handler det om den principielle afvejning, uafhængigt af udbyder.

## Hvad en WAF ser, og hvad en opdatering ændrer

En WAF sidder foran applikationen. Den ser hver forespørgsel, sammenligner den med regler og lader den passere, blokerer den eller logger den. Den ved ikke, hvordan PHP behandler forespørgslen internt. De to PHP2Shell-sårbarheder opstår dog netop dér: CVE-2026-109618 ved en out-of-memory-tilstand, mens forespørgselsdata kun er delvist initialiseret, CVE-2026-109619 gennem intern tilstand, der består efter en forespørgsel i den samme worker.

Opdateringen retter denne kode. Derefter er årsagen fjernet, uanset hvordan en forespørgsel ser ud. Den, der vil forstå, på hvilket sted i forløbet af en forespørgsel det sker, finder grundlaget under [Forespørgslens livscyklus i PHP](https://phpsos.de/da/php/request-lebenszyklus/).

## WAF i stedet for opdatering: den ærlige sammenligning

| Kriterium | Web Application Firewall | PHP-opdatering med genstart |
|---|---|---|
| Hvad rettes? | Intet, kendte mønstre opfanges | Årsagen i PHP-fortolkeren |
| Beskyttelse mod nye angrebsvarianter | Kun hvis regler tilpasses rettidigt | Ja, sårbarheden findes ikke længere |
| Kan den omgås? | Ja, f.eks. via direkte tilgængelighed af oprindelsesserveren | Nej, forudsat at alle PHP-processer er genstartet |
| Hastighed | Ofte aktiv med det samme | Afhænger af version, adgang og vedligeholdelsesvindue |
| Bivirkninger | Falske alarmer, forstyrrede formularer eller uploads | Sjældent, ved versionsspring kræves kompatibilitetstests |
| Nytte ved den næste sårbarhed | Høj, hvis vedligeholdt | Ingen, hver sårbarhed kræver sin egen opdatering |
| Hjælper den ved PHP 8.1 og ældre? | Som overgang | Kun via backport eller migrering |

Tabellen viser, hvorfor begge foranstaltninger hører sammen. WAF'en er hurtig og bred, men aldrig fuldstændig. Opdateringen er fuldstændig, men kun for en bestemt sårbarhed og ikke altid mulig med det samme.

Et punkt overses ofte i praksis: En WAF ændrer websitets adfærd. Strenge regler kan blokere legitime bestillinger, kontaktformularer eller filuploads, uden at nogen straks opdager det. Den, der skærper en WAF i krisen, bør derfor selv klikke igennem websitets vigtigste forløb én gang og gennemgå protokollerne fra de første dage for blokerede, men berettigede forespørgsler.

## Sådan kombinerer I begge fornuftigt

1. **Straks:** Kontrollér, om der findes en WAF, og om de passende regler er aktive. Ved Cloudflare i betalte abonnementer sættes Managed Ruleset ifølge udbyderen på Block.
2. **Straks:** Sørg for, at oprindelsesserveren kun kan nås via WAF'en, f.eks. med en firewall-frigivelse kun for dens adresseområder. Ellers løber beskyttelsen ud i sandet.
3. **Inden for det næste vedligeholdelsesvindue:** Opdatér PHP til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller indspil distributionens bekræftede backport.
4. **Lige derefter:** Genstart alle PHP-workers og -processer, og kontrollér, at ingen gammel proces kører længere. Nye filer alene er ikke nok; mere herom under [Efter opdateringen: Genstart PHP-FPM og alle workers](https://phpsos.de/da/php2shell/php-fpm-neustart/).
5. **Derefter:** Behold WAF-reglerne, evaluér falske alarmer, og sæt undtagelser målrettet i stedet for at slå regler fra generelt.

Med en egen WAF på basis af ModSecurity og OWASP Core Rule Set kan noget tilsvarende opnås; grundlaget beskriver [Anvend ModSecurity og OWASP Core Rule Set](https://phpsos.de/da/blog/modsecurity-owasp-crs/). En særform er den af fagforfattere foreslåede filtrering af upload-forespørgsler uden for egentlige upload-stier. Den er uofficiel, kan ødelægge formularer og hører kun hjemme i driften efter test.

> **Vigtigt:**
> Hverken WAF eller opdatering fjerner skadelig software, der blev indsmuglet tidligere. Kontrollér efter patchen, om der er opstået påfaldende forhold siden 17.10.2026.

## Hvornår I ikke har brug for en WAF, og hvornår ikke for en leverandør

En WAF er ikke obligatorisk for ethvert website. Et lille virksomhedswebsite hos en hostingudbyder, der patcher PHP rettidigt og bekræfter det, er ofte tilstrækkeligt beskyttet uden egen WAF, hvis CMS og plugins er aktuelle. Også den, der selv kan opdatere sin server inden for kort tid, har ikke brug for WAF'en som bro.

Den bliver fornuftig ved shops, portaler og applikationer med mange formularer, ved ældre systemer, der ikke kan opdateres med det samme, og dér, hvor flere websites skal beskyttes centralt. En leverandør har I kun brug for dertil, hvis opsætning, tests og løbende vedligeholdelse ikke er dækket internt.

## Hvordan hjælper PHP SOS konkret?

- Vi kontrollerer, om jeres WAF faktisk sidder foran alle adgange, og om oprindelsesserveren kan nås direkte.
- Vi opsætter regler eller tilpasser dem og tester formularer, uploads og grænseflader for bivirkninger.
- Vi indspiller PHP-opdateringen, genstarter alle processer og dokumenterer statussen.
- Hvor opdateringen tager tid, overbygger vi med [WAF og virtuel patching](https://phpsos.de/da/leistungen/waf-virtuelles-patching/) og en fast termin for den rigtige patch.

## Konklusion

Spørgsmålet "WAF eller opdatering" er forkert stillet. Opdateringen lukker sårbarheden, WAF'en skaffer tid og opfanger meget andet. Den, der kun satser på WAF'en, stoler på regler, som angribere kan omgå. Den, der kun patcher, står ved den næste sårbarhed igen uden bro.


## Ofte stillede spørgsmål

**Er en WAF nok som beskyttelse mod PHP2Shell?**  
Nej. En WAF kontrollerer datatrafikken og kan blokere kendte angrebsmønstre. Selve sårbarheden sidder i PHP-fortolkeren og består, indtil PHP er opdateret og genstartet. Cloudflare understreger udtrykkeligt, at dets regler ikke erstatter opdateringen.

**Er jeg automatisk beskyttet bag Cloudflare?**  
Kun for den trafik, der faktisk løber via Cloudflare. Kan oprindelsesserveren nås direkte fra internettet, omgås beskyttelsen. Ved betalte abonnementer bør I ifølge Cloudflare kontrollere, at Managed Ruleset står på Block.

**Kan en WAF stadig betale sig efter opdateringen?**  
Ofte ja. En WAF kan opfange massescanninger, kendte angreb på plugins og misbrug af loginsider og skaffer tid ved den næste sårbarhed. Den kræver dog vedligeholdelse og tests, ellers forstyrrer falske alarmer driften.

**Hvad er virtuel patching?**  
Det betyder midlertidigt at afskærme en sårbarhed med regler foran applikationen i stedet for at ændre koden. Det er en bro til den rigtige opdatering, ikke en erstatning.

## Kilder

- [Cloudflare-blog](https://blog.cloudflare.com/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)