The method used here to determine whether a site is patched can't detect manual patching, it can only detect a full upgrade to Drupal Core. And even then it can only do that if the CHANGELOG.txt is left in the root folder, which some people explicitly remove.
The patch for the security flaw was just a single line of code, manually patching is rather easy in this case.
This test demonstrates that at least 42.5% of sites have been patched, and probably a lot more manually, which is pretty good going for a piece of software that doesn't automatically update itself or have a license that requires a technical content who can be notified.
I'd guess the percentage of Wordpress sites running a version that needs a critical update is a lot higher.
Exactly the case for my site. I have patched the line 12hour after public disclosure. I have not updated Drupal Core, nor CHANGELOG.txt because there was nothing more than the patched line.
For me, one interesting aspect of this vulnerability and mitigation is how it illustrated the hierarchy of the Drupal community.
The Acquia blog post about this [1] is up-front with the fact that major companies who participate in the Drupal Security Team had a 7-day lead time on everyone else for this vulnerability. 7 days! Everyone else learned about it at the same time the bad guys did, and it turns out they had about 7 hours before attacks came flooding in. [2]
Particularly for folks in Europe, this was potentially disastrous, because the vulnerability and patch were released at about 10pm their time.
The Acquia blog post concludes by thanking the "all-volunteer Drupal Security Team." But the reward for participation is obvious: advance warning. If I ran a big Drupal shop, I would direct one of my engineers to spend time on, and try to join, the Drupal Security Team. It's just good insurance.
I am a Drupal user, and I have made sure that we are doing business with at least one of those companies, for the same reason. I was warned on Tuesday that a critical patch was coming on Wednesday; we were ready to go and patched everything within an hour of release.
Does that seem fair? I have to think that there is a better way to release these sorts of critical patches. I can't think of any reason the Security Team could not have posted a public announcement on Monday or Tuesday saying "get ready--critical patch coming Wednesday." Instead we got a PSA 2 weeks afterward, telling people that they should have been faster.
Shameless plug: if you're a shared hosting provider you should check out http://www.patchman.co.
Approximately 30% of your hosting accounts run an outdated version of WordPress, Joomla or Drupal with serious security vulnerabilities. These vulnerabilities can be easily exploited to run malicious code. But you already know that, since you're getting sick of all the spam runs and DoS attacks that are continuously being launched this way from your platform. Not to mention the more serious attacks. Aren't you tired of cleaning up after your customers?
Patchman runs on your platform and automatically detects and patches vulnerabilities in WordPress, Joomla and Drupal core (without breaking the application!). It will also automatically remove malware. On top of that, it takes care of all communication with your customers. It integrates with all the popular control panels, such as cPanel, Plesk and DirectAdmin. Saves you a lot of headaches and puts you in control of this mess :)
I heard a story of the vulnerability being exploited on several sites, a new backdoor created, and then the hax0r applied the drupal update to close the door behind them. So, don't just check if the site was updated, check if the site maintainer applied the update.
Yea, if you're just checking based on the 7.32 version I don't think your results would be accurate. There are sites that applied that patch to their 7.X version.
The patch for the security flaw was just a single line of code, manually patching is rather easy in this case.