How many sites are likely affected?

Drupal 8, 7, and 6 sites are affected. According to the Drupal project usage information this represents over one million sites or about 9% of sites that are running a known CMS according to Builtwith.

How dangerous is this issue?

Drupal security advisories include a risk score based on the NIST Common Misuse Scoring System. This helps give an objective sense of the risk of different issues. The risk of SA-CORE-2018-002 is scored 24/25 (Highly Critical) AC:None/A:None/CI:All/II:All/E:Exploit/TD:Default.

In the long form this means:

How difficult is it for the attacker to leverage the vulnerability? None (user visits page).

What privilege level is required for an exploit to be successful? None (all/anonymous users).

Does this vulnerability cause non-public data to be accessible? All non-public data is accessible.

Can this exploit allow system data (or data handled by the system) to be compromised? All data can be modified or deleted.

Does a known exploit exist? Exploit exists (documented or deployed exploit code already in the wild).

What percentage of users are affected? Default or common module configurations are exploitable, but a config change can disable the exploit.

Note on the last point that while a configuration change can theoretically mitigate the issue, it would have to be a drastic configuration change. The Security Team strongly recommends that the best solution is for sites to upgrade.

Who found this issue?

The issue was identified by Jasper Mattsson (Jasu_M) as part of general research into the security of Drupal. Jasper works for Druid who provide a variety of services including security audits of Drupal sites.

Over the years, security issues in Drupal have been found a variety of ways including researchers with personal motivation and through paid penetration tests or security audits. Drupal site owners concerned about security are encouraged to hire security firms to review their site.

What could an attacker do on a vulnerable site?

A successful exploit of the vulnerability can have a dramatic impact on the site. See the description of the risk score for details.

Is the issue being exploited?

Exploits have been developed. Sites not patched by Wednesday, 2018-04-11 may be compromised. This is the date when evidence emerged of automated attack attempts. It is possible targeted attacks occurred before that.

Simply updating Drupal will not remove backdoors or fix compromised sites. Site builders should therefore update their sites immediately and then investigate to see if their site was compromised, perhaps following the guide for fixing a compromised site. See Drupal Core - Highly Critical - Public Service announcement - PSA-2018-002.

My site has been hacked, what should I do now?

Whether it was exploited via this issue or some prior issue, there is a general guide for "hacked" sites.

I manage a Drupal 6 site, is a fix available?

Yes, Drupal 6 is also affected and the Drupal 6 Long Term Support project has patches available.

What other security measures might I put in place to improve my site's security.

A few general suggestions include:

The Security Review which looks for weak configurations.

2 Factor Auth to improve the security of logins.

Password Strength which helps enforce stronger passwords.

Paranoia which provides a mix of tools to increase the security of sites.

I manage a Drupal 8.0/8.1/8.2 site, is a fix available?

Previous minor versions of Drupal 8 are not supported after a new minor release is created. If your site is currently on a Drupal release prior to 8.3.8, there are other disclosed security vulnerabilities that may affect your site. For this reason, you should immediately update to at least Drupal 8.3.9 or 8.4.6, then plan to update to Drupal 8.5.1 or higher within the next month.

I can't update my site, what can I do to mitigate the problem?

There are several solutions, but they are all based on the idea of not serving the vulnerable Drupal pages to visitors. Temporarily replacing your Drupal site with a static HTML page is an effective mitigation. For staging or development sites you could disable the site or turn on a "Basic Auth" password to prevent access to the site.

List of updates

This FAQ may be updated and any updates will be summarized here.