Automated code review of Drupal 6 and Drupal 7

The most used open-source CMS is Drupal, no arguing there. Security of this platform is a de-facto requirement when writing Drupal code. During a lunch meeting with Dries Buytaert, creator of Drupal three years ago we discussed the direction Drupal has to take security-wise and a lot has changed in these three years. Not only we published a whitepaper to discuss the security vulnerabilities in the three most popular open-source PHP CMS we had the opportunity to review third-party modules for Drupal and to security test different web applications created in Drupal. One of our developers even created secure Drupal web applications for a customer in a period of one year! So we know the framework, the security features and what is needed when writing custom code. But we want to take it to a next level...


Checkmarx is an application security company, specialized in Source Code Analysis (SCA). Checkmarx's technology was designed for identifying, tracking and fixing security flaws from the root: the source code.

We used Checkmarx technology to run fully automated source code analysis of the core of Drupal 6 and Drupal 7 . You can find the results below !

The results for Drupal 6

This is a graph from the Checkmarx report, including the most critical vulnerabilities and most vulnerable files

graph 1

An overview of the results:

graph 2

An example that everything is checked:


Examining the Top 10 files reveals that all these files are either used for installation or admin access! Not public-facing!


Code example for the code injection, look at the method names: install_task_list and install_configure_form


For remote file inclusion, in install.php!


Checkmarx handles PHP flow very well, an example of a possible stored cross-site-scripting vulnerability:


Notice that there are 4 method calls before the XSS is output on the screen. Root cause is that the output from the database in menu_get_item is not validated for content, so it is considered trusted. This is normal behavior for a CMS that has a public front-end and a private back-end. Checkmarx follows the entire flow and sees that the parameter is not sanitized or HTML encoded, resulting in a succesful XSS. But mitigated because it requires administrator access to the Drupal database.

Minor issues like hardcoded path look like this:


The results for Drupal 7

There is already a big difference, notice the graphics from the Checkmarx report:


Even less critical vulnerabilities:


Again the same remark like for Drupal 6: all high risk vulnerabilities reside in installation files or back-end CMS files!


Example of a remote file inclusion vulnerability:



The Checkmarx tool gives enough assurance that the Drupal 6 and Drupal 7 core are secure enough, if installed and protected accordingly on a network and infrastructure level (this means no admin access from Internet on CMS and SSH) If we correlate these results with the results from our security testing and manual code reviews of customer projects we can conclude that all vulnerabilities exist in custom code: either external modules, changes to Drupal themes or hacks of Drupal core.

In addition the automated review also confirms the hard work the Drupal Security Team has done the last years to build a robust framework and have a review process in place

Add comment