Drupal 7's user login form (and I dare say others) can be tampered with client-side, to cause Drupal to throw an unhandled exception.

All you need to do is change the input fields, appending [] to the name of the name field, and Drupal will create invalid SQL and throw that at the database.

Is this considered a problem? Surely it's Drupal's job to ensure user input is sanitised to the point that it won't generate invalid SQL - is it a DOS risk/security issue?

e.g. Visit drupal.org's login page. Open firebug. Change the <input name="name".../> to <input name="name[]" .../> and add another one just like it. Put some values in both name fields and the password and submit. You get the "This website has encountered an error." page of death.

(I can vouch for this under Drupal 7.35, and on drupal.org which I presume is 7.36)

screenshot from drupal.org


screenshot 2 from drupal.org

  • Can you give some examples of these queries? I'm going to assume they're related to esoteric character sets? You need to remember that Drupal uses PDO - so at best, it's PDO's job to ensure user input is sanitised
    – Clive
    Apr 20, 2015 at 9:50
  • Edited question. This is to do with Drupal accepting an array where it should require a string, so it's generating SQL like "WHERE user = :user_0, :user_1". (so passing invalid SQL to PDO). Apr 20, 2015 at 10:44
  • If it's passing invalid SQL to PDO then yes, definitely a bug. Are you sure it definitely is, though? i.e. are you sure that PDO isn't expanding the arguments, and that Drupal is? Have you confirmed that the invalid SQL query is actually being run on the server, and that the fatal error doesn't come from a point in code before the query is run?
    – Clive
    Apr 20, 2015 at 10:46
  • Yep I'm sure. I've seen the SQL issued (PDO does not expand array params, that's one of the things Drupal's API does). Apr 20, 2015 at 10:54
  • I've edited the input name and pass iin a Drupal 7 fresh installation adding [] to the name of each elem and I only get some PHP warnings (mb_sterlen and addcslashes functions expect string insted of array) but no blank page of death.
    – sanzante
    Apr 20, 2015 at 10:57

1 Answer 1


No, user input shoulnd't cause and unhandled exception. Not only because is a nasty reponse form server but it reveals an error condition not handled so it may head to security issues. A non-handled error means that developers are not aware of that error (or they are too lazy, what may be worst).

All error conditions should be handled to minimize problems related to that uncontrolled error.

I've tried to reproduce the bug (with two input name fields with name="name[]" as you have shown in your images) without getting reported error. So I think this particular case you mention seems to be a drupal.org bug or a module bug of a module used in the Drupal site. You can report the bug in the Drupal.org infrastructure issue queue

  • Weird you can't reproduce. I've tried three sites and they all behave the same (admittedly not a fresh install). FWIW, the reason I'm looking into this is that I have detected several malicious attack attempts on one of my sites using this method. I presume they're trying to probe for the drupalgeddon thing (which I patched for ages ago). Apr 20, 2015 at 12:23
  • I have caught an exploit attempt from the wild that is an example and saved the _POST data. Should I post it here or would that be considered bad security practise? Apr 24, 2015 at 8:14
  • If you think you have found a security issue you can find instructions to report it here: drupal.org/node/101494 In short you have to goto he project page of the component affected and follow the "Report a security vulnerability" link. Exploits should be not published until a component is patched for security reasons.
    – sanzante
    Apr 24, 2015 at 8:30
  • It's basically the drupageddon thing. They fixed the security side because an uncaught exception is not considered a security risk. I guess it's an infrastructure queue thing. Apr 24, 2015 at 9:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.