CMSs mostly vulnerable through addons says German security agency

The BSI's analysis of known vulnerabilities shows that Joomla and Typo3 have a relatively high share of critical code execution holes
Source: BSI

In a 160-page study, Germany's Federal Office for Information Security (BSI) has taken a close look at security problems in the most common web content management system (CMS) packages, including Drupal, Joomla, Plone, Typo3 and WordPress. They analysed the phases of each program's lifecycle, available log settings, data protection measures and other factors.

Unpatched vulnerabilities not closed by the developers in time or the lack of a crisis communication plan or brute force protection did have the biggest negative impact on the BSI's overall rating, while a clunky integration into existing management software only brought down the score a little. However, the security experts did not conduct a penetration test for the study.

The BSI took on CMS applications because of their high level of exposure; they are often the first target for an attacker who wants to get into a company's internal network. The systems are also often installed and used without any modification, which means that any vulnerability that comes up can put several web sites at risk at once.

One of the – hardly surprising – findings of the study is that far more vulnerabilities are lurking in the plug-ins than in the core CMS code itself. For WordPress, for example, 20 per cent of all bugs were found in the actual CMS, while 80 per cent were in the add-ons. The ratio is even more extreme for Drupal, at five (core) to 95 per cent (extensions).

Overall, the study's authors say that the content management systems generally have a good level of security and that they are satisfied with the individual providers' security-related processes. At the same time, however, they recommend that users never run a CMS in its standard configuration; instead, security options should be adjusted as appropriate. Some of those adjustments should include setting up non-standardised admin accounts, automatic update management and using HTTPS for operating both the frontend and the backend.

(Uli Ries / fab)