Drupal 7 Security Exploit


Drupal 7.32 is a security release that includes a fix for a SQL injection vulnerability. Unlike typical security advisories released for Drupal, the nature of this vulnerability provides a way for an attacker to create an exploit without needing an account or tricking someone into exposing confidential information.

This vulnerability affects D7, not D6.

The alert was emailed out around 9am MST October 15, 2014. Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement.

  •  Attacks may not leave any trace at all.
  •  It is impossible to think of all the places that attackers might hide a backdoor.

Fixing it involves changing one line of code in includes/database/database.inc
-      foreach ($data as $i => $value) {
+      foreach (array_values($data) as $i => $value) {

If you are interested in the technical details of this exploit and how exactly it could be used, see:

A Lesson in Security

Upgrading to 7.32 does not involve any database queries (i.e., you don't have to run update.php).

If you did not patch/update within hours of the announcement, your site may already be compromised, and you may not be able to find any trace of this.

You can sign up to receive security alert by logging in to your drupal account, going to your user profile page, and subscribe to the security newsletter on the Edit » My newsletters tab. You can start at drupal.org/security, which has instructions for signing up for alerts in the right sidebar.


Guidance from Ben Emmons of UITS on things to look for if you didn't patch within 7 hours:

1. Verify no unexpected modifications were made to .gitignore
2. Run "git status" and verify no untracked files exist
3. Review the .htaccess files in your public and private file directories and ensure the https://www.drupal.org/SA-CORE-2013-003 fix still exists
4. In your public and private file directories, look for php files (which shouldn't be there): find . -type f -name '*.php'
5. Run "drush sql-dump --tables-list=menu_router | grep file_put_contents -o" and verify no results are found
6. Check your site user list for any new or modified users
7. Check your site content for any unauthorized modifications/new content after October 14

Other things to check:

  • files (especially php files) in the site root that don't belong there. Download a fresh copy of drupal 7 and use it to compare.
  • some are reporting php files in random folders in the format xxxx.php where xxxx are four letters.
  • note that newly-created bogus user accounts may have a fudged creation date so that they appear at the bottom of your user list.


  • If you are responsible for patching/updating Drupal sites you should definitely be subscribed to the security alerts.
  • If you are not the one who patches/updates your Drupal sites, know who is, and make sure they are subscribed to the security alerts.
  • Know your sites and monitor them regularly for anything odd.
  • Know who does the backups for your site's database, your site's files, and your site's server, and make sure they are happening regularly.


Followup Public Service Announcement: