# WAF of update: waarom u beide nodig hebt

> WAF in plaats van update bij PHP2Shell? Wat een Web Application Firewall doet, waar ze ophoudt en waarom alleen de PHP-update met herstart het lek dicht.

Bron: https://phpsos.de/nl/blog/waf-oder-update/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** WAF in plaats van update werkt niet bij PHP2Shell. Een Web Application Firewall, dus een filter vóór de website, controleert verzoeken en kan bekende aanvalspatronen blokkeren. Het lek zelf zit echter in de PHP-interpreter en verdwijnt pas met de update en de herstart van alle PHP-processen. Een WAF is een zinvolle extra laag en een brug voor enkele dagen, niet de oplossing.

## Waarom de vraag juist nu zo vaak wordt gesteld

Veel beheerders lazen in de PHP2Shell-week een ogenschijnlijk goed bericht: Cloudflare heeft volgens eigen opgave sinds 21 oktober 2026, 03:02 UTC, beschermingsregels actief, ook voor klanten met het gratis abonnement. Wie toch al achter Cloudflare of een andere WAF zit, vraagt zich begrijpelijkerwijs af of de update dan nog haast heeft.

Het eerlijke antwoord is ja. Cloudflare zelf relativeert: regels op basis van alleen de verzoekgegevens volstaan niet, daarom controleert de dienst bovendien het antwoord van de server. Cloudflare heeft bovendien gewijzigde aanvalspatronen waargenomen. En de bescherming werkt alleen voor verkeer dat daadwerkelijk via Cloudflare loopt. De details over deze aanbieder beschrijft [Cloudflare-beschermingsregels tegen PHP2Shell](https://phpsos.de/nl/blog/cloudflare-waf-php2shell/). Hier gaat het om de principiële afweging, los van de aanbieder.

## Wat een WAF ziet en wat een update verandert

Een WAF staat vóór de toepassing. Ze ziet elk verzoek, vergelijkt het met regels en laat het door, blokkeert het of logt het. Ze weet niet hoe PHP het verzoek intern verwerkt. De twee PHP2Shell-lekken ontstaan echter precies daar: CVE-2026-109618 bij een out-of-memory-toestand terwijl verzoekgegevens maar gedeeltelijk zijn geïnitialiseerd, CVE-2026-109619 door interne toestand die na een verzoek in dezelfde worker blijft bestaan.

De update corrigeert deze code. Daarna is de oorzaak weggenomen, hoe een verzoek er ook uitziet. Wie wil begrijpen op welk punt in het verloop van een verzoek dit gebeurt, vindt de basis onder [De request-levenscyclus in PHP](https://phpsos.de/nl/php/request-lebenszyklus/).

## WAF in plaats van update: de eerlijke vergelijking

| Criterium | Web Application Firewall | PHP-update met herstart |
|---|---|---|
| Wat wordt verholpen? | Niets, bekende patronen worden onderschept | De oorzaak in de PHP-interpreter |
| Bescherming bij nieuwe aanvalsvarianten | Alleen als regels tijdig worden aangepast | Ja, het lek bestaat niet meer |
| Omzeilen mogelijk? | Ja, bijvoorbeeld via directe bereikbaarheid van de oorspronkelijke server | Nee, mits alle PHP-processen zijn herstart |
| Snelheid | Vaak direct actief | Afhankelijk van versie, toegang en onderhoudsvenster |
| Bijwerkingen | Valse alarmen, verstoorde formulieren of uploads | Zelden, bij versiesprongen zijn compatibiliteitstests nodig |
| Nut bij het volgende lek | Hoog, indien onderhouden | Geen, elk lek vraagt zijn eigen update |
| Helpt bij PHP 8.1 en ouder? | Als overbrugging | Alleen via backport of migratie |

De tabel laat zien waarom beide maatregelen bij elkaar horen. De WAF is snel en breed, maar nooit volledig. De update is volledig, maar alleen voor een bepaald lek en niet altijd direct mogelijk.

Eén punt wordt in de praktijk vaak over het hoofd gezien: een WAF verandert het gedrag van de website. Strenge regels kunnen legitieme bestellingen, contactformulieren of bestandsuploads blokkeren zonder dat iemand het direct merkt. Wie in een crisis een WAF scherp zet, moet daarom de belangrijkste processen van de website zelf eenmaal doorlopen en de logs van de eerste dagen controleren op geblokkeerde maar gerechtvaardigde verzoeken.

## Zo combineert u beide zinvol

1. **Direct:** controleren of er een WAF is en of de passende regels actief zijn. Bij Cloudflare in betaalde abonnementen de Managed Ruleset volgens de aanbieder op Block zetten.
2. **Direct:** zorgen dat de oorspronkelijke server alleen via de WAF bereikbaar is, bijvoorbeeld met een firewallvrijgave alleen voor hun adresbereiken. Anders loopt de bescherming ongebruikt.
3. **Binnen het eerstvolgende onderhoudsvenster:** PHP bijwerken naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of de bevestigde backport van de distributie installeren.
4. **Direct daarna:** alle PHP-workers en -processen herstarten en controleren dat er geen oud proces meer draait. Nieuwe bestanden alleen volstaan niet; meer daarover onder [Na de update: PHP-FPM en alle workers herstarten](https://phpsos.de/nl/php2shell/php-fpm-neustart/).
5. **Daarna:** WAF-regels behouden, valse alarmen analyseren en uitzonderingen gericht instellen in plaats van regels globaal uit te schakelen.

Met een eigen WAF op basis van ModSecurity en de OWASP Core Rule Set is iets vergelijkbaars te bereiken; de basis beschrijft [ModSecurity en OWASP Core Rule Set inzetten](https://phpsos.de/nl/blog/modsecurity-owasp-crs/). Een bijzondere vorm is het door vakauteurs voorgestelde filteren van uploadverzoeken buiten echte uploadpaden. Het is onofficieel, kan formulieren breken en hoort alleen na een test in bedrijf.

> **Belangrijk:**
> Noch WAF noch update verwijdert schadelijke software die eerder is binnengebracht. Controleer na de patch of er sinds 17 oktober 2026 bijzonderheden zijn opgetreden.

## Wanneer u geen WAF nodig hebt en wanneer geen dienstverlener

Een WAF is niet voor elke website verplicht. Een kleine bedrijfswebsite bij een hoster die PHP tijdig patcht en dat bevestigt, is zonder eigen WAF vaak voldoende beschermd, als CMS en plug-ins actueel zijn. Ook wie zijn server binnen korte tijd zelf kan bijwerken, heeft de WAF niet als brug nodig.

Zinvol wordt ze bij shops, portalen en toepassingen met veel formulieren, bij oude systemen die niet direct kunnen worden bijgewerkt en waar meerdere websites centraal moeten worden beschermd. Een dienstverlener hebt u daarvoor alleen nodig als inrichting, tests en lopend onderhoud intern niet zijn gedekt.

## Hoe helpt PHP SOS concreet?

- Wij controleren of uw WAF daadwerkelijk vóór alle toegangen staat en of de oorspronkelijke server rechtstreeks bereikbaar is.
- Wij richten regels in of passen ze aan en testen formulieren, uploads en koppelingen op bijwerkingen.
- Wij installeren de PHP-update, herstarten alle processen en documenteren de stand.
- Waar de update tijd kost, overbruggen wij met [WAF en virtueel patchen](https://phpsos.de/nl/leistungen/waf-virtuelles-patching/) en een vaste datum voor de echte patch.

## Conclusie

De vraag „WAF of update“ is verkeerd gesteld. De update dicht het lek, de WAF levert tijd op en vangt veel anders op. Wie alleen op de WAF vertrouwt, vertrouwt op regels die aanvallers kunnen omzeilen. Wie alleen patcht, staat bij het volgende lek weer zonder brug.


## Veelgestelde vragen

**Volstaat een WAF als bescherming tegen PHP2Shell?**  
Nee. Een WAF controleert het dataverkeer en kan bekende aanvalspatronen blokkeren. Het lek zelf zit in de PHP-interpreter en blijft bestaan totdat PHP is bijgewerkt en herstart. Cloudflare benadrukt uitdrukkelijk dat zijn regels de update niet vervangen.

**Ben ik achter Cloudflare automatisch beschermd?**  
Alleen voor het verkeer dat daadwerkelijk via Cloudflare loopt. Is de oorspronkelijke server rechtstreeks vanaf internet bereikbaar, dan wordt de bescherming omzeild. Bij betaalde abonnementen moet u volgens Cloudflare controleren of de Managed Ruleset op Block staat.

**Loont een WAF ook na de update nog?**  
Vaak wel. Een WAF kan massale scans, bekende aanvallen op plug-ins en misbruik van inlogpagina's onderscheppen en levert bij het volgende lek tijd op. Ze vraagt wel onderhoud en tests, anders verstoren valse alarmen het bedrijfsproces.

**Wat is virtueel patchen?**  
Daarmee wordt bedoeld een kwetsbaarheid tijdelijk met regels vóór de toepassing af te schermen, in plaats van de code te wijzigen. Het is een brug naar de echte update, geen vervanging.

## Bronnen

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