WPScan Vulnerability Database a New WordPress Security Resource

Researcher Ryan Dewhurst released the WPScan Vulnerability Database, a database housing security vulnerabilities in WordPress core code, plug-ins and themes. It’s available for pen-testers, WordPress administrators and developers.

WordPress’ popularity as a content management system (44 percent of CMS market share) is matched in parallel by the number of security vulnerabilities afflicting the open source platform, as well as its versatile plug-ins and themes.

It’s not unlikely that a developer may be at a loss as to the security of a particular plug-in, or the disclosure of a devastating flaw in the core WordPress code that could expose a website to attack. During last weekend’s BruCon in Belgium, U.K.-based security researcher Ryan Dewhurst released the WPScan Vulnerability Database, a one-stop shop for the latest WordPress, plug-in and theme vulnerabilities that he hopes becomes an indispensable resource for pen-testers, administrators and WordPress developers.

Dewhurst told Threatpost that the genesis for the databases was the creation of WPScan, a Ruby-based WordPress vulnerability scanner he wrote in 2011. WPScan, he said, filled a gap because at the time there were no automated tools that scan for security issues in the context of the platform. WPScan is at version 2.5 as of this weekend and scans in the background for bugs, outputting any issues it finds, Dewhurst said. Around the time he built WPScan, Dewhurst said he began working on the vulnerability databases as well. That part of the project was this year pushed over the top by £5,000 in funding from BruCon’s 5by5 Project.

“As WPScan detected WordPress versions, plug-ins and themes installed on a WordPress blog, it was easy enough for us to then output any vulnerabilities associated to that version, plugin or theme if we kept the issues in a database,” Dewhurst said.

Originally, the database—actually three databases, one for the core code and one each for plug-ins and themes—was populated manually by one of the four people on the WPScan team. Someone would manually edit the XML files and commit them to the team’s Github repository, Dewhurst said. Now the vulnerabilities are entered into a Web interface as they’re reported from a number of online sources, including mailing lists, contributors or researchers.

“The new database helps us manage the vulnerabilities much easier too as we can view the data from a high level overview if we wish,” Dewhurst said. “This should also increase the quality of or database entries.”

The database is a potential gold mine of WordPress vulnerability information collected in a centralized location.

“I think the audience is broad but I hope that the database is useful to security professionals during penetration tests. For example, if they come across a particular WordPress plug-in during an audit, they can quickly check if we hold any vulnerabilities for that particular plugin. They can even do this via our API,” Dewhurst said.

He hopes WordPress administrators find the database useful to check the security of blogs and sites based on the platform, or to check the security of a plug-in or theme. WordPress developers, he said, can also benefit.

“I hope that some developers make use of the API to create new ways for users to access the data; maybe a WordPress plug-in that can warn users if they are running a vulnerable plug-in or theme,” Dewhurst said. “Any commercial usage of the data would require a commercial license though. But it is free to anyone who wants to use it in their own open source software or projects.”

Dewhurst said the databases can affect some changes improving the overall WordPress ecosystem.

“I hope that WordPress users will be more aware of the security issues which can affect older versions of WordPress, Plugins and Themes. Hopefully this will result in the increase of security in self-hosted WordPress blogs,” Dewhurst said. “Maybe WordPress themselves might take some further action in ensuring that some Plugin and Theme developers don’t share vulnerable code. One example might be using automated static code analysis on the Plugins and Themes submitted to them before they are released to the public. This is not a perfect solution but it could be workable.”

Suggested articles