Your Drupal website has a backdoor

I estimate hundreds of thousands of Drupal websites now have backdoors; between ten and ninety percent of all Drupal websites. Automated Drupageddon exploits were in the wild within hours of the announcement. Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal. Backdoors give attackers admin access and allow arbitrary PHP execution.

If your Drupal 7 (and 8) website is not updated or patched it is most likely compromised. If your website was not updated within a day of the announcement, it is probably compromised. Even if your website was updated within a day, it may be compromised.

If you did not know, Drupageddon is the highly critical SQL injection vulnerability in Drupal core announced 15 October. It is also known as Drupalgeddon (with an "L"), CVE-2014-3704, Drupal SA core 2014 005 and #DrupalSA05. Drupageddon (no "L") is the original name selected by Stefan Horst, who initially reported to the Drupal security team. See

I have drafted this flowchart to help Drupal website administrators understand their options for recovering from Drupageddon. Review, feedback and collaboration is welcome.

The flowchart is a living document. Currently version is number 7.


How to fix a Drupal site compromised by Drupageddon

Creative Commons License

How to fix a Drupal site from Drupageddon, second draft.png399.63 KB
How to fix a Drupal site from Drupageddon, draft 3.png470.95 KB
How to recover from Drupageddon, draft 4.png581.75 KB
How to recover from Drupageddon, transparent draft 5.png542.35 KB
How to recover from Drupageddon, draft 6.png643.95 KB
How to recover from Drupageddon, draft 7.png651.82 KB
How to recover from Drupageddon, version 8.png634.21 KB
How to recover from Drupageddon, version 9.png639.57 KB


acquia didn't automatically

acquia didn't automatically patch installs, it modified settings.php to load a custom database driver that incorporates the patch.

Additionally, as far as I know this wasn't implemented for Drupal 8 installs on Acquia hosting (or potentially ones with more than one database connection etc.)

This means if you ever move that code base elsewhere, or if they eventually remove that workaround, then the site would still be vulnerable.

So sites on Drupal hosted platforms that did some kind of mitigation still need to upgrade/patch.

FYI. Drupal 6 sites are also

FYI. Drupal 6 sites are also vulnerable to the same vulnerability as 7 and 8 sites if they have the DBTNG module installed but not updated.

Severity and even if it is an

Severity and even if it is an issue at all depends on the use of DBTNG; is it accepting input from users? If you only use it for migrate, there may be no exposed query to abuse.

DBTNG vulnerability

Interesting - there was no SA about that - or did I miss it?

Hacked Module

Wouldn't the Hacked module also be helpful in evaluating the validity of the Core & Contrib code base?

Missing: core update from some flows

For version #2, in the section on fixing compromised code, you don't make it clear that in the case of reverting to VCS or restoring a backup, core also needs to be updated to 7.32 before going to the next step.

Great resource

Thanks for this Bevan, we've been looking for comprehensive playbook for Drupal users who didn't update in time, so this is very valuable. I passed this around our tech team and got positive feedback, there was a mention that it's not sufficiently clear that those restoring code form backup or VCS also need to update to 7.32 - FWIW.

Video on what to do if you're hacked

I just published a video showing what to do if you were hacked. I hope it helps someone get their site back in order! :)

What I'm missing here is that

What I'm missing here is that you will need to do a complete reinstall. Perhaps your OS hasn't been touched. But in my experience back doors are common. You simply can't trust anything on this server anymore.

So decommission hardware, and start from scratch is highly recommended instead of taking "we hope the OS hasn't been compromised".

Thank you all for feedback.

Thank you all for feedback. I have incorporated it into the third draft. Please review.

Brian; Please link to the video. I could not find it.


Sure, I thought I put it inline in the last comment. Here it is:

Thank you! Where can

Thank you! Where can administrators of Drupal 6 websites using DBTNG find out more detail? These websites are a minority compared to the compromised Drupal 7 websites out there. I have included it in this flowchart only for thoroughness.

Other sites on the same server?

I might have missed something, but the flowchart doesn't seem to cover the case of the other sites hosted on a server where a site was compromised. It should be a matter of going through the same flow chart for all the sites hosted on that server, for example "Does your server host other Drupal sites?" --yes--> "Audit each site follow this flowchart".

"Stop reading this flowchart" doesn't really make sense since they should definitely come back to the flowchart, they have a lot of work to do. There is also no much more sense of urgency at this point since it's been so long since exploits have started. People should just follow the chart (including the step to patch their site).

"Widespread automated attacks were in the wild within a day": it was less than a day, more like within 7 or 8 hours.

"Continued access to the server": should clarify that it's server access (e.g. SSH or SFTP), not HTTP.

"Is there a backup of code from before October 15?" is missing the "no" label (minor)

"Restore core's .htaccess in the public and and private files directories":
- double "and"
- instructions needed as this not obvious: in theory Drupal should restore them automatically for you (at least if you go to the files settings form and save the form).

"Note the 'L' typo in the name": I find this note confusing. It's not a typo, that's how the module is name. I don't think this note is necessary, just give the URL :) maybe you could have a list of links at the bottom of your posts with links to Drush command, etc.

New version; number 6

Thank you for the detailed comments and review scor. Version 6 (light blue background) has changes as per your comments as well as new steps relating to managing the likelihood of compromised data, a decision point for websites that are on private networks or protected by HTTP Basic Authentication, and other minor enhancements.

Feedback round #2

Thanks for applying my initial feedback.

"Notify the host or the person who manages the server that it may have been compromised. They should consider rebuilding": It's not only the folks who manage the server, but any other site owner using that server too. I don't see anything about co-hosted sites in the chart.

"Check you have the latest version of this flowchart…" if people have to type the URL by hand, you might want to offer a URL.

Thanks scor; The flowchart is

Thanks scor;

The flowchart is intended for each website, not each server. Each website's administrator should apply the chart starting from the beginning for each website, since the process may be unique for each one. Since I have not seen details of the cross-website exploits that you have, I am not sure how it affects the flowchart.

Would something like this handle it? "Other Drupal websites on the same server may also be compromised, even if they are (??? on a private network, protected by HTTP Basic Auth, running Drupal 6, not even running Drupal...???). Administrators of any other [Drupal] website hosted on the server should be notified." (Please correct and add the appropriate detail.)

No way to detect a compromised server?


I can restore my site and my db with a backup before 15.10.2014. However asking the hoster to setup his hardware new without having a hint whether the site was attacked or not is quite unrealistic.
Is there no way to check whether the site was attacked?
As an example I updated to drupal 7.32 within 12 hours. The only folder not touched was the "site" folder. Can I not compare all files from site folder with a backup from before 15.10.2014? And then check in the DB for any "strange" user? And do some other checks?

thanks for help

Al; Yes; But you probably

Al; Yes; But you probably won't think of all the places where an attacker could have hidden a backdoor, so you will never be able to have certainty that you have removed them all. For example backdoors could be in the database, files directory, or code, other websites on the same server, or other services of the same operating system. In the database alone I can easily think of a dozen places backdoors can be hidden, and I am sure there are more.

Change the password for the MySQL user Drupal uses.

This should be done even if you don't manage the server.

tiny tweak....

You can try

The reason why people give you the advice to wipe the server is that they have battled with servers which they thought they had cleaned, but infections keep coming back.

If your OS is supported, you were up-to-date with patches (you patched against bash right?), and you indeed do what you propose, you can give it a try. But it all depends on time versus risk. Not important site, you have plenty of time, just try what you propose. And be prepared to reinstall at some point.

But if you got infected, it indicates you were not security aware, you probably were not up-to-date with patches, so probably shouldn't be hosting yourself, and this may be a good time to move to managed hosting.


My Drupal websites are in Jailkit chroot. Is it really possible that the host server be compromised? DBTNG has DBTNG has no stable release.

@JM: Good point. Thanks! I'll correct in next version.

@Berend: Have you seen evidence of that with Drupageddon? I have not. I added as a precautionary measure and based on Scor's advice (perhaps he has seen it too). Great advice about managed hosting. Drupageddon really highlights that.

@Pyc: I don't know what that is and can not make a recommendation sorry.

@Pyc: it's probably unlikely

@Pyc: it's probably unlikely to have escaped your chroot. So you probably would be fine by just recreating your jail with a copy before the attack.

@Bevan: have not seen reports if attacks going beyond database/drupal site changes. Obviously won't be easy as you run as the apache account, so you need to escape that first.

Re: Jail

@Berend de Boer: thank you for advises!

This is insane.

I appreciate all the hard work you've done here, and I'm sure it's all legitimate and necessary...but it's been 2 weeks. Many institutions deliberately hold off on installing patches for a day or two because of the frequency of the patches themselves causing further problems. The White House runs on Drupal. The state of Georgia runs on Drupal. The University of Minnesota runs on Drupal. Restoring from a day or two ago is one thing, but from 2 weeks ago? That's asking an awful lot, especially for large, complex sites which may have further issues from the restoration process itself, it seems to me.

Again, if that's all that can be done, fine, but how about resetting the individual MySQL user passwords (along with all other passwords, flushing the caches, truncating the tables etc)? Is a full pre-10/15 restoration really necessary?

@Charles; You can never be

@Charles; You can never be certain you have found all the backdoors, there are probably hundreds of places I can think of to put them to hide them between the database, code and filesystem, and I'm only one person. There are many attackers.

(sigh) I understand that, I guess I'm just wondering

...why it took 2 full weeks for the true seriousness of this to go public. If hackers were pouncing all over within just a few hours, shouldn't the cry have gone out within 2-3 days at most?

Not criticizing, just trying to understand.

Is it safe for fresh install of Drupal 7.32?

This is a noob question. I just started my first Drupal development several days ago.

It is fresh install with 7.32 version. So is it still vulnerable?

"Check timestamps of custom code files"

Timestamps are not reliable. I've seen altered timestamps in recent WordPress compromises, so I have no doubt they could be used in this one.

Charles; The Drupal security

Charles; The Drupal security team does its PSAs and SAs on Wednesdays. I don't know why they chose Wednesdays. As for why it took TWO Wednesdays instead of one; Maybe they did not have enough confirmed reports of widespread automated attacks. There may have been an element of disbelief or shock. I know that my encouragement definitely helped things happen faster. In fact much of the PSA's wording is unchanged from my original suggestions (which are not public).

Fung; 7.32 is not vulnerable. I will update the flowchart to handle scenarios like yours. Thank you.

JM; Thank you for pointing that out. Timestamps nevertheless can help find backdoors. But I will make it clear this is not a thorough check in the next version of the flowchart.

I tried to install the module

I tried to install the module and the page dont let me. It says that the module dont have a .info archive. What can I do? I dont have a backup pre oct15 and I dont want to lose my work.

Vulnerability Since 2011

Thanks for all the great work. It is very helpful. I have a comment and a question.

Comment: I get all the talk about October 15. But it seems to me the fact that this huge bug has been in Drupal 7 since 2011 is being ignored. Given that it is so easy to exploit this vulnerability without leaving a trace, why is there the assumption out there that anything pre-15 October, 2014 is fine?

Question: I have two sites which were breached for sure. In both cases a user named "Megauser" was created and assigned the role of "drupaldev" which was also created. From the user timestamp I can tell one happened at 14:00 GMT 18 Oct. and the other at 19:00 GMT 18 Oct.

In both cases the user was assigned no permissions, none. Why would someone do that? Why create a user who wouldn't have any perms beyond authenticated user?

Thanks again for the great work.


I have a D6 site with DBTNG installed, but it wasn't enabled. I've deleted it altogether rather than upgrade it. Would the site have been at risk?

Charles: why it took 2 full

Charles: why it took 2 full weeks for the true seriousness of this to go public

You must not have been paying attention. Peopel were screaming all over twitter immediately that you should upgrade NOW. I don't think anything more could have been done to reach people who were not paying attention.


@A stranger: What module? Drupalgeddon? It is not a module. Always read the project page before trying to use new modules/extensions.

@Shai: No one should assume that websites were not attacked using this vulnerability before October 15. However we have seen no evidence of attacks since before this date. So widespread automated attacks that predate 15 October are quite unlikely.

@Shai: I investigated some websites with the Megauser role and drupaldev user. IIRC the user was assigned the role which was granted admin privileges. Users are not assigned permissions in Drupal. They are assigned a role, and a role is assigned permissions.

@thoughtcat: I don't know much about the DBTNG vulnerability so I do not know. Please let us know if you find out.

Thanks for the reply Bevan. I

Thanks for the reply Bevan. I have raised a query on the DBTNG issue queue but had no response so far:

One more key question: One of my D7 sites sits on a server with scores of other files and folders, most of them unrelated to Drupal (e.g. static html pages, image files etc). Do I need to delete all of the non-Drupal files and folders from that server and reupload those too, or is it only the Drupal files I need to worry about?

Documentation of attacks


When I said the user was assigned no permissions, I mis-wrote. I meant to say the role, "drupaldev" wasn't assigned any permissions.

So the same question stands: why would an attacker create a new user and assign that user to a new role that had no permissions?

Is there any place where attacks are being documented?

You wrote:

In the database alone I can easily think of a dozen places backdoors can be hidden, and I am sure there are more..

As different back doors are discovered that have been used by exploiters of the Drupalgeddon bug, they should be documented. Since the attacks that would affect the most web sites are automated ones, any backdoor discovered would likely affect a lot of sites. Having a central place where people can share their discoveries could save folks a lot of time.

Thanks again for all your work.

@Shai; I don't know why the

@Shai; I don't know why the role would not have been assigned permissions. In the sites I checked it was.

@Shai; A central place to log certain exploits would indeed be useful. Currently the Drupalgeddon issue queue is probably the best candidate for such a place to do that.

@Thoughtcat: Yes. Attackers

@Thoughtcat: Yes. Attackers may have installed backdoors into any web-accessible directory, even if it is not usually a PHP-executable directory. They may also have installed non-web backdoors into directories that are not web-accessible, or made new directories web-accessible for the purpose of hiding their backdoor.

Drupageddon, small business and limited resources

Some of this is a rehash of a post in a Drupal group discussion on responsibly following up on Drupageddon. I wanted to thank you, Bevan for your guidance on how to manage the fallout of this SA. The flow diagram and strategic/practical discussion of the problems has been really useful.

I have a small web design and development business in the UK - the datacentre where my sites are hosted only keeps backups for 7 days - and I now have around 20 compromised sites. Stupidly of course I didn't subscribe to the SA newsletter or I guess I would have heard of the issue sooner. As it was I first heard about it from the BBC over the weekend just gone. Am painfully aware that I've been caught napping but in all honesty I doubt very much whether I would have caught any of this in anything like good time even if I'd had a little more notice as I don't have the resources to continually monitor and update some 30+ sites on a daily basis. With hindsight of course I see that I can't afford not to.

I have updated all my sites and removed the megausers that had appeared in half of them, and begun changing passwords where it is a simple task (only a handful of users) - but am still left with the sure knowledge that all of them remain compromised and I have no option but to physically rebuild on new servers (which the datacentre will obviously charge me to create) and then transfer just those elements that I am reasonably sure are free of back doors - so really just the theme files that I hold locally and the contents of the files folder. Even then, as I understand it, my sites may not be safe?

I'm thinking that if I recreate the domains on a new server with a fresh install of D7.32 and all associated libraries, modules and themes then the only files I need to copy over are custom theme files, and the contents of sites/default/files. I will try and find any .php files in sites/default/files but is it possible for malicious code to be squirelled away in .css files? Presumably it could be in tpl.php files? But can it also masquerading as .png or .jpg files? Apologies if I come across as a complete newb on this - but I'm just not sure what I can reasonably trust and what I can't.

One article I read suggested auditing the database tables before transfer. To be honest though - I've no idea what I'm looking for. I've scoured the menu_router table and can't see anything that screams hack at me - but with my state of knowledge I could be standing in a pile of it and still not smell it... so to speak. So - some tables will have to be transferred - notably node and field tables - but can I trust them? How down and dirty do I need to get when rebuilding... should I be cutting and pasting from one site to another? Difficult - especially if I am really supposed to disable the server that I am transferring from. Maybe larger organisations can remove the server from having a web presence but still keep it live for internal audit/transfer purposes - but I am a long way from that so I'm thinking I will have to chance it and keep the old server live - which is a kind of website Russian (possibly literally!) roulette.

The other thing that concerns me is how safe are my D6 sites and Wordpress sites on these servers and should I be treating them with the same suspicion that I now view my D7 sites? Or am I 'reasonably' safe to transfer them as they are?

I know this is a big post Bevan - but if you have any answers to even some of the questions here I would really be very grateful!

PS V small cause for hope is that Drupalgeddon drush tool is telling me that my sites do not test positive for hacking. I know it's not failsafe - but perhaps I have a window before hell breaks loose? Maybe? Please?

Thanks again Bevan. I've

Thanks again Bevan. I've since had a look through the request report in my web server statistics and couldn't see anything that looks like SQL in there. I patched my site within a day of the original security release, so I'm hoping I am safe. This page may be useful for people to know what to look for in their logs:

@Thoughtcat you won't see the

@Thoughtcat you won't see the SQL queries in your regular web server logs, because the vast majority of the attacks are performed via POST requests and the SQL queries are in the POST payload, which is not typically logged.

@thoughtcat; The body and

@thoughtcat; The body and cookie values of POST requests are not usually logged. That is where the payload for many (but not all) attacks is. I would not assume you are safe just because there are no traces in statistics or logs.

@John Jackson; I recommend you hire someone with the appropriate skills and experience to help rebuild your websites and recover the parts that can't be sourced from elsewhere from the compromised server. You should also moving to a host that manage updates for you, such as Drupal-specific hosts with maintenance plans, and fully-managed services like Drupal Gardens.

This will save you time, because someone with the right experience knows that scouring the menu_router table is a waste of time; Just rebuild it: drush cc menu.

If you rebuild the website from scratch (starting with 7.32's install.php) on a new server, restore custom code files from your local machine, copy and paste only text from the hacked websites, then run security review module, then the websites and server will most likely be as safe as they can be. (Remembering nothing is ever safe; security is a process, not a state of being.)


  • If you copy the text you will need to reformat it on the rebuilt website. That is safest. If you copy the HTML inspect it carefully for anything malicious or unexpected. Many attacks inject <script> or <iframe> tags into node bodies, fields, tpl.php or module files. But there are other variations too. (These scripts and iframes then infect the website visitor's PCs with malware via known vulnerabilities in old versions of IE, flash, etc.)
  • If you have a copy of the website on your local machine, that may serve as a backup you can use to restore the website. I will add this to the flowchart, since I see now that it is not obvious.
  • Check the flowchart as I may have forgotten something.

As for the server, it is likely there are attacks which hide backdoors in web-accessible directories that are not Drupal's. Or even create new PHP-executable and web-accessible directories that are hard to find and hide their exploits there. Further, exploits might not have the .php file extension. So yes; every website on that server is possibly compromised. I have heard of such exploits but not familiar with the details, so to be safe the recommendation is to rebuild or restore every website on that server.

As a temporary measure, you could create static copies of the websites and put those on the new secured server while you rebuild or secure the websites. Static copies may still have malicious HTML so you should scan for and remove those from the static HTML files, or from Drupal before you create the static HTML files (security review module helps with that).

Drupalgeddon is woefully out of date and there are known exploits that it does not detect. Until it is updated it is only marginally useful.


@Bevan Many thanks for your response. I appreciate your advice and much of the practical stuff broadly falls in line with what I am considering doing. I must admit that I am struggling a little bit with a rising tide of ire (probably misdirected) at the development community and the drupal experts that will no doubt save my skin if only I were willing to pay them to do so.

My reasons go something like this: 10 years ago I came (admittedly very late) to Jeffrey Zeldman's Designing with web standards. He encouraged me to take control of not only the design but also the framework. It's been a journey that I have learned painfully (I am a designer really, but necessity has made me a developer too) but I have improved year by year. I have been through the managed hosting options and in the interests of full control over my own destiny I have ended up with 3 dedicated servers of my own which I manage and which, until a couple of weeks ago, I believed I was doing a fairly decent job of managing.

One of the attractions of Drupal from the beginning was its logical structure, flexibility and power and also, despite a steep learning curve - usability. I STILL struggle with Wordpress and hate it with a passion - even though I recommend it on occasion to clients that I know will struggle with the options presented by Drupal. But back to Drupal - nothing in the 'promotional material', website explanations or anything, suggests to me that it is the preserve of internet 'Experts'. I can download it, use it, even build my business around it and good luck to me.

So. I can use drush - a year or so ago it revolutionised the way I update and manage my sites. I have just installed it on the server I am building to recover from DG (Drupalgeddon DUDE!). But it too is a powerful piece of software and if I knew that the command to rebuild the menu_router table was drush cc menu - you can bet your bottom dollar (or pound) that I would build that into my recovery strategy. I am not an idiot - I can use the tools available. But this just evidences "You know what you know, and not what you don't". Knowledge is power - but it doesn't make you better than anyone else because - guess what - anyone else can learn it.. though it might take them a while and in the meantime you can offer that as a service. Ahem. I can also use Google.

What is lacking in the development community (which by the way I have an immense amount of respect for and am in no way trying to do down) is an appreciation that many, many people find themselves involved in it tangentially and require a resource (sometimes without having to resort to a forum) that makes no, or minimal, assumptions about the state of knowledge of their audience. Or, if they do make assumptions, can at least target advice to specific audiences. 90% of my time spent troubleshooting issues is trying to ascertain basic criteria for how to address an issue that have been overlooked by an expert because it is considered to be a given. Having said that I have yawned my way through my fair share of tutorials - so I do appreciate it's a fine line.

Believe me, I would love to hand my whole sorry mess over to someone else to sort. But A- as a small business I cannot afford it (I have looked into Acquia hosting... I can't afford it) and B- really, if I do, (particularly at the last minute in response to a crisis like this) what guarantees / confidence can I offer my clients?

So - I'm 46. I have never worked for any one else - always been self-employed - and in my experience, be it plumber, electrician or ISP I am better off digging myself out of holes - and then at least I know who to blame when it all goes to pot. And I won't have to engage in lengthy arguments as to culpability.

Apologies - this seems to be a bit of a rant. @Bevan I am genuinely grateful for the interest that you have shown - and your advice above is good, and useful. (I particularly like your point about security being a process, not a state.) It's just that I find (and I am sure that I can't be alone in this) that I can't just pay someone to make the pain go away. I have to undertake to understand and learn from this.

Insert sad/frustrated/notsurewhatitallmeans emoticon here.

Drupal Camps, playdays, hackathons, meetups


The kind of help and resources you desire already exist.
There are Drupal playdays and hackathons where you can just show up, and someone will probably be able to spend some time with you on something you are trying to understand.
Most formal Drupal meetups and Drupal Camps have a track for Drupal users at various stages of technical expertise.
The best place to find these events is on
There is also the Drupal Ladder project that is designed to take someone inexperienced and guide them to the point where they can contribute to the Drupal project
I started my Web Developer consulting career in earnest a little over 10 years ago in my early 40s. I have been working with Drupal about 8 years. I got some lucky breaks, and for the past few years I have been doing challenging work as a Drupal Developer and then as a Drupal Architect/Engineer for Enterprise organizations.
I go to meetups and camps and other events whenever I can. Some day I dream of going to Drupalcon - illnesses in my family have kept me close to home the past few years.
Learn something every day :D

Bad Behavior, Honeypot, http:BL before 7.32?

Does having these modules installed prior to 7.32 have any affect on exploits?
For example, checking against http:BL IP blacklist or detecting suspicious behavior?
I guess the answer is "maybe, no guarantee"

Small business sites, clubs, schools etc

Small businesses, schools, clubs, personal sites etc, will often have in common: (a) no regular backups, (b) insufficient in-house technical skills to be able to do the necessary detective work to look for backdoors or other bad stuff that might have been installed. That's a big problem. Here are some outline ideas for a partial solution, at least to reduce the risks:

Prevent access to PHP files:
* At the web-server level (e.g. in .htaccess) prevent execution of any PHP files in and below the Drupal root directory other than index.php and cron.php (authorize.php, update.php and xmlrpc.php can be included later, if required).
* Reinstall Drupal 7.32 to make sure the above files are originals..

User accounts:
* Temporarily block outgoing emails so that the password-reset feature cannot be used - the reroute_email module would be one way of doing that.
* Change all passwords and check/set email addresses. In many small sites there are only a handful of user accounts. Not so easy it's a forum site or similar, would need some automated tool.
* Delete any bogus user accounts that may have been created. Again, easy enough if it's a small site with only a handful of user accounts.

* Disable the PHP filter if it's enabled.
* Clear cache.
* What else?

So, not a complete solution, but would reduce the risk quite a lot I think. I wrote an article on my own site (it seems I cant post the link without triggering Mollom, but it's easy to find at - and the research I did for that led me to conclude that many small sites have not patched or upgraded yet. Also from that research, I found that on nginx based sites, typical configurations allow you to read directly (i.e. by visiting [site]/includes/database/ and so check directly whether the vulnerable code is there or not.

Thanks Bevan & Scor. I was

Thanks Bevan & Scor. I was advised to check my logs by a pro Drupal developer and he didn't say what you said. Thanks though.

re John Jackson's post, I'm in a similar position although thankfully have fewer sites to manage. I'm seriously thinking, rather than spend hours rebuilding the individual sites, of moving to a multi-site setup, so that all my Drupal sites run off the same codebase and thus in future can all be updated at once rather than on a site-by-site basis which is what takes so much time. Any comments on the pros and cons of that from more experienced Drupal guys here?


@Thoughtcat let's not get off topic, as this is about security, but in the context of Drupageddon, a multi site installation has one disadvantage: a single backdoor PHP file installed in (for example) a modules directory would be present on all sites of the multi-site setup. For the same reasons, that code could more easily access multiple Drupal databases - the database name and user/password are stored in settings.php per site, so it would be easy to find those (easy enough too, with multiple single-site configurations, but not so easy to know where their settings.php files reside).

I run about 5 small sites on a multi-site setup. Updating them to latest Drupal core (and modules) is a simple matter of running: drush @sites up - so upgrading to fix security issues is a near-trivial exercise (really each site's database should be backed up first, but that's facilitated by drush too).

Same boat as John Jackson

One-person shop. 30 clients - both D6 and D7 - on one dedicated server.
Updated all but one site on afternoon of Oct 15. The one site I missed was a tester in maintenance mode. (Who knew you had to update tester sites in maintenance mode? Now I know... geeez.)
Only learned about this issue with the BBC report on Friday.

Try very hard not to freak out. There are not enough hours in the day or days in the week to handle all of this. So I must do triage.

Only the one late site APPEARS to have been hacked.... drupaldev user added but no sign of unusual permissions to this user. No weird menu_router entries, nothing.

• Completely terminated the suspect account and all of its databases etc.
• Changed whm and all cpanel passwords, mysql passwords, user1 passwords on all accounts.
• Installed and ran security_check module on all sites. Assessed status of backups pre-Oct 15th. Notified clients to hold on.
• Ordered brand-new dedi server with managed service.
• Migrated all non-CMS sites over to new server and prayed that simple .html files that look OK are OK.
• Uploaded pre-Oct 15 versions of those D6 sites that are OK to revert to new server and made critical module and content updates after DNS resolves. (Had to print out all content changes on compromised server first so I can go back and make changes again.)
That's my last 5 days. And I'm only a tiny little bit through this....

@John; Thanks for sharing

@John; Thanks for sharing your thoughts. I am sympathetic with the situation. I agree that it is understated that managing your own software comes with certain risks and responsibilities. Remember Drupal, as all open source software, comes at no cost and has no guarantees. It sounds like what you need is someone to bounce ideas of and get advice from to help you do it yourself, rather than just have them do it for you. Acquia hosting is expensive but there are others out there. It may also be time to consider charging more to your clients in order to provide a more reliable service.

@decibal.places; I am not

@decibal.places; I am not familiar with Honey Pot, Bad Behaviour, or http:BL. But I doubt that any contrib module would have prevented these exploits.; I would recommend those organisations rebuild their website from scratch.

@Thoughtcat; To clarify, checking logs is useful to help you realize the extent of attacks. But a lack of evidence there does not mean the website was not attacked.

@Thoughtcat; There are a lot of arguments for and against this type of configuration. This is not the right place to dive into that, so I'll keep my response short: I think its usually not a good idea, with some very few exceptions. Josh Koenig at Pantheon highlights the problems well:

@K Gates; If you did anything that would cause menu-rebuild after an attack but before you looked in menu_router, such as enabling or disabling a module or clearing all caches, then you would have removed any signs of attacks from the menu_router table.

@K Gates; I applaud you for addressing this responsibly. Use security_review module, not security_check. Security Review module is more mature and complete.

http:BL, Bad Behavior, Honey

http:BL, Bad Behavior, Honey Pot in general provide a first-line of defense against exploits and ddos attacks at the application level, by blocking IPs listed on the http:BL blacklist, and rejecting suspicious requests. After installing these measures on a couple of small sites, they have blocked ~ 2000 IPs, and that's a significant amount of unwanted traffic when you multiply that by 10s or 100s of requests each.
So Drupal still bootstraps, at least partially, before the IP is identified. But it will keep a known - or suspicious - attempt from submitting SQL injection in a login form, for example.
Probably not a protection against Drupageddon, but trusty tools I often deploy on sites slammed by spammers and hacking probes.

I have had to deploy other strategies when the full volume of unwanted traffic exceeds the mysql max_user_questions limit on sites that are not distributed, but that is well beyond the scope of this discussion. I added a sub page to docs at d.o. about randomizing mysql users to avoid exceeding the limit:

Hi John Jackson, not every

Hi John Jackson, not every managed Drupal hosting company charges Acquia prices. Feel free to checkout Xplain Hosting(2 month free trial).

I have updated the flowchart.

I have updated the flowchart. The current version is number 8. The main changes are refactored steps to shorten and simplify the entire workflow and avoid any paths that crossover.

Questions for clarification

OK some questions:

1) When you say that a Drupal 6 website is safe from attack, does that mean they do NOT need to be rolled back to pre-Oct 15? What if they were on the same server as possibly affected sites? Boy that would be a tremendous relief! But I bet you're going to say they're not safe after all (and then you'll have to change your flowchart again).

2) I wonder if the fact that I "jail" SSH on all of the accounts explains why I'm seeing no signs of infection? You suggested that I might not be seeing attacks because I flushed caches. Caches probably did flush when I updated on morning of Oct 16th, would that hide the problems? I have completely shut down SSH access on the entire server now. This kind of hobbles me a bit but maybe also hobbles hackers more? Or am I wrong about this?

3) Although I download DB backups to my local and have them from pre-Oct 15, I keep my FILE backups on the possibly affected server outside of root, in tar.gz form. I pray you're going to tell me those are OK... but you probably will not. (sigh).

Workflow and rebuilds

Picking up on @Bevan's point regarding the need for someone to consult - certainly for me a service provision dedicated to Drupal security - rather than managed hosting - would be a good way to go. @ decibel.places - the drupal hackathons sound interesting, but am not sure whether a more constant source of advice might not be needed? Clearly this episode highlights the requirement for daily server monitoring and technical support that ISPs are generally lacking in (actually, a while back, the ONLY Linux engineer at my ISP left and for a few months I had no Linux / Server support of any kind).

If anyone has any recommendations as to Drupal security service providers I'd be interested in hearing (@Berend de Boer - no offence intended to Xplain Hosting! - thanks for the recommendation but I am fairly committed to local server service provision - the datacentre is based just outside the village I live in - so I think that it would be a security service that I need to add on).

More positively - I have now settled into the routine of reinstalling all the D7 software from scratch on a new server - copying over just the theme files that I held locally - only copying the contents of the files directory (after searching for any suspicious looking files) from the old server - dumping the database from the old site and and then copying over a handful of tables (block_custom, field tables, node tables etc) which I can easily search for php, script, iframe or other non-standard tags. Am a little wary of some of the field config tables that have Blob fields that seem undecipherable - but comparing them with the same table fields in clean installs - they look much the same if not identical in some cases.

I've also made use of the views export feature quite heavily to copy view info from old site to new - it's easy to look through that code and spot anything untoward.

All-in-all - though I'm only a few sites in - am beginning to feel at least that recovery is achievable - whereas a few days ago I was on the verge of giving it all up and retraining as a chimpanzee. Although I must say, working through the night isn't as much fun as I remember it being from way back when...

Finally @Bevan - I have also made use of the Security Review module which is very useful - a good recommendation once again. Although it has been telling me to chmod all the theme files to 644 - which might be very secure but also seems to stop them from working.


Have just got to the DrupalCare bit of the Hooked on Drupal podcast... clearly it exists! In the UK?

@K gates; 1) The bug that

@K gates;

1) The bug that makes Drupal 7 vulnerable to Drupageddon attacks does not exist in Drupal 6. However if they are on the same server as a Drupal 7 website that was attacked, it is possible attackers hid backdoors in other websites on that server, whether they run Drupal 6, Wordpress, static HTML or whatever.

You should treat the whole server with caution.

If you can roll back the whole server to a pre-October 15 backup, you should do that. If you can't, you should restore from backups to a new server so that you can decommission the compromised one.

2) SSH has nothing to do with this vulnerability or the attacks I have seen. (Except that attackers are likely to try to escalate their access to get SSH access). I am not sure what "jailing SSH" means. There was another commentator who asked about "Jailkit chroot" who got a useful answer (not from me). I don't know if that is the same thing.

3) It is probably possible there are backdoors in the tar.gz backups but that is quite unlikely. I would use that if I were you (assuming there is no pre-15 Oct backup that is not on the compromised server).

@John Jackson; I applaud you

@John Jackson; I applaud you for addressing this responsibly.

If the theme stops working with safe file permissions, something is very unusual with the server. Your host does not seem very committed to Linux. The physical location of your servers is of little relevance these days for most people and most websites. (Have you ever needed to physically go to the data centre?). See also and

I think you're right re: lack

I think you're right re: lack of Linux commitment - while there was no support the line I mostly got was "We're all Windows types here". Well great, I'm so glad I'm paying for your service. But to be fair things have improved a lot. I do occasionally go to the data centre. Though not out of necessity... they've quite a good coffee place there. And I like supporting local endeavours. But i also like the fact I can have a conversation like this, with people around the world ... location simultaneously doesn't matter, and does. If that makes sense.


See above

Make a Donation

I created the flowchart hoping that it would help the owners of the hundreds of thousands of compromised websites. Initially I thought it would take a couple of hours. But as I dove into it, I realised how many edge cases there are. It has taken dozens of hours to create, research and update. It will take dozens more as more information about Drupageddon attacks becomes available.

A donation shows me that the work is useful and motivates me to keep it up; As new information about attacks slows down I will shift focus to Drupalgeddon, the drush command, which is the next most useful tool for recovering compromised websites.

To make a donation:

Thank you kindly.

Failed attempts?

Hi Bevan,

(Note: I tried posting this to the FAQ for this vulnerability on but am being continually rejected as being a potential spammer. Even my request for the "not a spammer" role failed to post, because it was flagged as spam. Not a great way of encouraging new participants in the community).

I upgraded my site to 7.32 a couple of days after the announcement (I was travelling, and typically this occurred just prior to hiring a third-party to maintain the site). As per your excellent flowchart, I'm in the process of restoring a pre-October 15 version (not trivial, as we add content every day).

In a sense, that makes my question irrelevant. But I wonder if the answer might come in useful for those who are not in a position to restore a pre-October 15 backup and want to establish if their site has been compromised.

In the intervening time between the announcement and the patching of the site, I can see several exploitation attempts in our server logs. However, it looks to me as though these were all unsuccessful.

The majority of them came from our Russian friends over at (who seem to have been very active, judging by others' posts). A typical example looks like this:

(3966766) - - [16/Oct/2014:23:55:22 +0000] "POST /?q=node&destination=node HTTP/1.1" 500 9474 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
(3966767) - - [16/Oct/2014:23:55:23 +0000] "POST /user HTTP/1.1" 500 8692 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
(3966774) - - [16/Oct/2014:23:55:24 +0000] "GET /?q=wthzub HTTP/1.1" 301 2 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
(3966775) - - [16/Oct/2014:23:55:25 +0000] "GET /wthzub HTTP/1.1" 404 22751 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
(3966776) - - [16/Oct/2014:23:55:26 +0000] "GET /wthzub HTTP/1.1" 404 22751 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
(3966782) - - [16/Oct/2014:23:55:26 +0000] "GET /modules/comment/ujac.php HTTP/1.1" 404 22813 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"

It looks to me like our friend was trying to insert a PHP file at /modules/comment/ujac.php - but failed. Probably because the web server didn't have write access to the docroot, or perhaps something simpler like an error in his SQL syntax. Is that a fair intepretation?

I've been through the entire site and found no evidence of an actual breach (though, as I said, I'll be restoring anyway). There are no changes to any core or optional code directories/files, no suspicious files in the sites directory, nothing new in the blocks or views tables, no new users (admin or otherwise), no suspicious sessions, etc.

Is this a typical signature of a failed attempt? Or am I missing something, and could we actually been compromised in the above set of requests?


shotgun approach

I see requests like these in my logs, also ones that clearly targeting WordPress, Java, anything.
I think they are probing in a shotgun approach. Unless your site is specifically targeted, with specifically crafted attempts, you are likely to see large numbers of probes that could not possibly work - unless you made it possible for them.
This is where the Bad Behavior module can be used to analyze activity and graylist or blacklist IPs that have bad behavior. It uses "behavior driven" analysis. Of course the baddies can just switch to another IP, but in my experience they will go where there are lower hanging fruit.
On my personal site the number of probes shut down the site, it was unable to bootstrap because of too many mysql requests. Once I dealt with that by randomizing mysql users, the Drupal modules Bad Behavior, httpBL, and Honeypot could do their job and begin to block these bad IPs. I also manually blocked many IPs and IP ranges in Drupal and on the Cloudflare CDN, so that the traffic from these IPs did not even reach the Drupal application.

Resource for conducting a test

I have a manged dedicated server that runs cPanel on Centos. I set up a separate cPanel account for each of my clients. My clients don't have access to cPanel or shell, but I do. Shell access server-wide is only accessable via a whitelist of IP addresses.

I understand that accounts with Drupal 7 were vulnerable.

What I'm not sure about is whether the OS was vulnerable. The hosting company that deploys my server and provides management for it says that the OS was not vulnerable. Other resources about Drupalgeddon including this site suggest that it was.

I'd like to create an account on the server running Drupal 7.31 and then exploit its vulnerability to try to write a file to the server at /etc to test if the OS was vulnerable.

Can you provide those instructions or provide a link to a resource which would publish directions on how I could do that.


@NickS; You are correct that

@NickS; You are correct that those attacks seem to have failed because you had correctly configured file permissions (which is surprisingly difficult). But there are other exploits which look like normal requests in most logs and install backdoors in the database, which would be successful regardless of the file permissions. So the recommendation for this scenario still applies; Rollback to a pre-15-October backup.

@Shai; The OS is not vulnerable to Drupageddon directly. Attackers may be able, via a compromised Drupal website, to exploit vulnerabilities in other services to escalate access. If your hosting provicer opted not to rebuild the server or provide a new one, they are confident that no attack on your website was able to escalate access beyond your website, maybe because they are not careful, but probably because they applied security updates (for the OS's services) quickly and have everything securely configured. Either way, if you have told them that your websites were compromised and they have investigated the server, that is all you can and should do about the server. You can restore from backups onto the same server. Ideally you would restore and secure all of your websites on that server before you take any of them online. Your hosting provider may be able to do this for you.

Thank you everyone else for your input.

Is it necessary to revoke the public key?

I'm moving my website to a new server. In my old server, I used an passphrase protected authentication key to login to the server over ssh. The website in question doesn't use SSL (https).

In the chart, is says: "Revoke public keys for any of the server's private keys." I don't really understand what does it means. Does it refers to certificate-authenticated SSL (https://) or does it refers to the authentication keys used to login to the server over ssh? Do I have to generate a new pair of authentication keys?


Revoking private keys

@Charlie; Many security protocols, like SSH and SSL, use a pair of "keys". One component is distributed publicly or fairly freely. The other component is private and must be kept secret.

Anyone with the private key can use it to encrypt and decrypt all data shared via that pair of encryption keys. E.g. SSH to a server with the public key on it, be or impersonate the server identified by an SSL certificate.

If the private component becomes compromised, the pair should no longer be considered secure. Any system configured to trust the private component (by holding a copy of the public component) should revoke access for that private key by removing the public key from its list of trusted pairs.

Sometimes servers are configured with key pairs to SSH into other servers such as for backups. Any private keys stored on a compromised server may have been compromised by Drupageddon, and possible even used to access other servers on the same network.

Likewise, if your website supports HTTPS / SSL, then an attacker may have compromised the private component stored on your server. They could use this to impersonate your website (SSL certificate and all) in combination with a DNS or MITM attack.

I have not seen evidence of Drupageddon attacks that are this advanced. So these are precautionary measures.

Since you do not use SSL, and the private key that allows you to SSH to the compromised server is not on the compromised server (or should not be), there is nothing in your comment indicating that you need to revoke any keys at all.

However you should check for any private keys on the compromised server that might be used by backup systems, for example.

I am curious about what is

I am curious about what is the best practice for restoring site content after rebuilding a "compromised" site. Currently I am reviewing a site which was not patched in time and "should" be considered hacked. It appears that there are no database back ups so the only source of content is directly from the "compromised" site. Specific challenges with this site include:
1) No pre-hack backup of content.
2) Contains a large number of blocks created via the block admin UI which contain HTML in the body field.
3) Site configuration is not in features

Would be good to find out more information on best practice for the content recovery side of things. For example, must all site configuration be restore manually or is there a way of generating features and then sanitizing them some how? How to export and sanitize content, as well as, admin created structural content like blocks?

How to rebuild site content

Thanks for the flow cart. I am wondering if there are any good resources for explaining how to recover site content when rebuilding a site? For example, I am faced with several sites which were potentially compromised by SA-CORE-2014-005 but have not been "fixed". In one case there is no pre-vulnerability DB backup. In the other case, there is a pre-vulnerability DB backup, but since then there is a large number of post-vulnerability new or updated content. I was hoping that there might be similar resources to this page, outlining the process of rebuilding a compromised site (particularly how to recover content or configuration stored in the database).