Kort gezegd: Cloudflare heeft volgens eigen opgave sinds 21 oktober 2026, 03:02 UTC, beschermingsregels tegen PHP2Shell actief, ook voor klanten met het gratis abonnement. De regels verlagen het risico voor verkeer dat via Cloudflare loopt. Ze werken niet als de oorspronkelijke server rechtstreeks bereikbaar is, en ze vervangen de PHP-update niet. Wie Cloudflare gebruikt, moet regelmodus, bescherming van de oorspronkelijke server en patchstatus controleren.
Het begin: bescherming al vóór de patch
Cloudflare was bij PHP2Shell ongebruikelijk vroeg. Volgens de Cloudflare-blog draaiden de beschermingsregels al enkele uren vóór de officiële publicatie van de PHP-updates om 14:00 UTC. Cloudflare meldde bovendien aanvalspogingen op klanten te hebben waargenomen en dat aanvallers hun patronen veranderden om de regels te omzeilen.
Veel beheerders hebben daaruit geconcludeerd: „We zitten achter Cloudflare, dus we zijn beschermd.” Dat klopt maar gedeeltelijk. Deze bijdrage legt uit wat de regels daadwerkelijk dekken. Een algemene afweging tussen firewall en update biedt de bijdrage WAF of update?.
Wat Cloudflare tegen PHP2Shell heeft uitgerold
Volgens de opgaven in de Cloudflare-blog zijn er drie bouwstenen:
| Abonnement | Bescherming volgens Cloudflare | Wat u moet doen |
|---|---|---|
| Free | nieuwe regels in de Managed Free Ruleset, automatisch actief | controleren dat het domein via Cloudflare loopt |
| Pro, Business, Enterprise | passende regels in de Managed Ruleset | zorgen dat de Ruleset op „Block” staat |
| alle abonnementen | standaardregel in de nieuwe response-firewall | niets uitschakelen, gebeurtenissen volgen |
De derde bouwsteen is nieuw. Cloudflare noemt hem „full transaction detection”: de WAF beoordeelt niet alleen het verzoek, maar ook het antwoord van de server. De reden volgens Cloudflare: het verzoek alleen volstaat niet altijd om een aanval betrouwbaar van normaal verkeer te onderscheiden. PHP2Shell is de eerste toepassing van deze functie in de beheerde regels.
De grenzen van de Cloudflare-regels
Hoe nuttig de regels ook zijn, ze hebben duidelijke grenzen, die Cloudflare deels zelf noemt:
- Alleen verkeer via Cloudflare: De regels controleren wat door Cloudflare stroomt. Is de oorspronkelijke server onder zijn IP-adres rechtstreeks bereikbaar, dan kan een aanvaller de bescherming omzeilen.
- Niet ongedaan te maken: Volgens Cloudflare kan een regel aan de antwoordzijde het antwoord tegenhouden, maar niet ongedaan maken wat er op de server al is gebeurd.
- Wisselende aanvalspatronen: Cloudflare past regels voortdurend aan, omdat aanvallers hun verzoeken veranderen. Tussen een nieuwe variant en een nieuwe regel kan een gat zitten.
- Geen vervanging van de update: Cloudflare adviseert uitdrukkelijk PHP ondanks de WAF bij te werken. Ook een update van toepassingscode of plug-ins verhelpt de lekken niet.
- Bijzonder geval CVE-2026-115560: Volgens de aanvulling van Cloudflare van 23 oktober werkt de regel niet als de naam voor session upload progress in de configuratie is gewijzigd. Meer over deze melding onder CVE-2026-115560.
Wat geblokkeerde verzoeken wel en niet zeggen
Veel klanten kijken na de melding in hun beveiligingsgebeurtenissen en vinden daar geblokkeerde verzoeken. Dat toont in eerste instantie alleen dat uw domein is gecontroleerd en de regel heeft gewerkt. Een inbraak is daarmee niet aangetoond. Omgekeerd is een lege gebeurtenissenlijst geen geruststelling: liep een aanval rechtstreeks op de oorspronkelijke server of vóór 21 oktober, dan verschijnt hij bij Cloudflare helemaal niet.
Betrouwbaarder is de vergelijking met de logs van de webserver zelf. Verzoeken die daar aankomen maar niet van Cloudflare-adressen afkomstig zijn, wijzen op directe toegang. Stel deze logs veilig vanaf 20 oktober, zoals de vakpers aanraadt. Cloudflare wijst er bovendien op dat beperkingen voor uploads het risico kunnen verkleinen, maar de PHP-update niet vervangen.
De meest voorkomende zwakke plek achter Cloudflare is niet de regel, maar de weg eromheen: een oorspronkelijke server die onder zijn IP-adres of via een onbeschermd subdomein rechtstreeks antwoordt.
Controlelijst voor Cloudflare-klanten
Deze stappen kunt u of uw dienstverlener op korte termijn uitvoeren:
- Abonnement en regelmodus controleren: Bij betaalde abonnementen in het dashboard nagaan dat de Managed Ruleset in de modus „Block” actief is.
- Beveiligingsgebeurtenissen bekijken: Onder de Security Events nagaan of er geblokkeerde verzoeken opduiken. Dat toont of uw domeinen al doelwit waren.
- DNS-records doorlopen: Elk record dat naar de webserver wijst maar niet via Cloudflare loopt, is een mogelijke omweg. Typisch zijn subdomeinen voor staging, FTP of mail op dezelfde server.
- Oorspronkelijke server afschermen: De webserver zo configureren dat hij HTTP en HTTPS alleen van Cloudflare accepteert, bijvoorbeeld via een firewall met de door Cloudflare gepubliceerde adresbereiken of via een tunnel. Hoe dat in het algemeen werkt, beschrijft de bijdrage Firewall voor webservers.
- Directe toegang testen: Van buitenaf controleren of de oorspronkelijke server zonder Cloudflare antwoordt.
- PHP bijwerken en herstarten: De regels zijn de tweede linie. De eerste is PHP op een verholpen stand met herstart van alle PHP-processen.
Voor stap 5 volstaat een onschuldige test die alleen de headers opvraagt. Het IP-adres is een plaatsaanduiding voor uw oorspronkelijke server:
# Antwoordt de oorspronkelijke server rechtstreeks, langs Cloudflare heen?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Komt hier een regulier antwoord van uw website, dan is de oorspronkelijke server rechtstreeks bereikbaar en de Cloudflare-bescherming te omzeilen.
Hoe helpt PHP SOS concreet?
- Configuratiecontrole: Wij controleren regelmodus, DNS-records en de directe toegang tot de oorspronkelijke server.
- Oorspronkelijke server beveiligen: Wij beperken de webserver tot verkeer via Cloudflare zonder uw website te onderbreken.
- Patch en bewijs: Wij werken PHP bij, herstarten alle processen en documenteren de status.
- Gebeurtenissen analyseren: Wij bekijken geblokkeerde verzoeken en vergelijken ze met de serverlogs.
Hoe wij WAF-regels en tussentijdse maatregelen combineren, beschrijft WAF en virtueel patchen.
Conclusie
De Cloudflare-regels tegen PHP2Shell zijn een echte winst, vooral omdat ze vroeg kwamen en ook in het gratis abonnement. Maar ze zijn een schild voor de deur, geen slot op de deur. Wie achter Cloudflare zit, moet drie dingen waarborgen: regels in de Block-modus, geen weg langs de proxy en PHP op een verholpen stand.
Veelgestelde vragen
Ben ik met het gratis Cloudflare-abonnement beschermd tegen PHP2Shell?
Volgens Cloudflare krijgen ook Free-klanten de beschermingsregels automatisch. Ze werken echter alleen voor verkeer dat via Cloudflare loopt en vervangen de PHP-update op de server niet. Is de oorspronkelijke server rechtstreeks bereikbaar, dan werkt de bescherming niet.
Wat moet ik bij betaalde Cloudflare-abonnementen instellen?
Cloudflare adviseert klanten met een Pro-, Business- of Enterprise-abonnement te controleren of de Managed Ruleset in de modus Block draait. Staat hij alleen op Loggen, dan worden aanvallen wel vastgelegd, maar niet tegengehouden.
Wat is full transaction detection?
Een nieuwe functie van de Cloudflare-WAF die niet alleen het verzoek, maar ook het antwoord van de server beoordeelt. Zo is te herkennen of een aanvalspoging effect heeft, en kan het antwoord worden tegengehouden. Wat op de server al is uitgevoerd, maakt ze volgens Cloudflare niet ongedaan.
Dekt Cloudflare ook CVE-2026-115560 af?
Cloudflare heeft zijn bijdrage op 23 oktober over CVE-2026-115560 aangevuld. Volgens Cloudflare werkt de bijbehorende regel niet als de naam voor session upload progress in de PHP-configuratie is gewijzigd. Los daarvan adviseert php.net session.upload_progress.enabled=0 in te stellen.