PHP-related vulnerabilities on the National Vulnerability Database

The CVE is a dictionary of vulnerabilities maintained by the MITRE Corp. A unique identifier is associated to security vulnerabilities found for reference. The full database can be downloaded or searched online.

One can query the database for keywords (e.g. PHP) and dates. It is a little bit crude:

However a quick manual check through the search results show that the returned vulnerabilities are indeed mostly related to PHP, so although the precision may not be down to the percent, the overall picture and trend are sincere.

On the whole database, about 25% of vulnerabilities (CVE) are related to PHP, although about 17% of products (CPE) are related to PHP.

Data generated on 2016-10-12:

	year	php	cve	pc
	2016	352	5102	6.9%
	2015	678	6379	10.6%
	2014	1063	7545	14.1%
	2013	462	5007	9.2%
	2012	776	4806	16.1%
	2011	802	4151	19.3%
	2010	1154	4639	24.9%
	2009	2128	5733	37.1%
	2008	2218	5632	39.4%
	2007	2594	6516	39.8%
	2006	3140	6608	47.5%
	2005	1501	4932	30.4%
	2004	507	2451	20.7%
	2003	204	1527	13.4%
	2002	245	2156	11.4%
	2001	98	1677	5.8%
	2000	21	1020	2.1%
	1999	5	894	0.6%
	1998	0	246	0.0%
	1997	5	252	2.0%
	1996	1	75	1.3%

The network access vector shows that 99% of PHP-related vulnerabilities can be exploited remotely. PHP vulnerabilities account for about 29% of vulnerabilities which allow a remote access.

Why?

Here are possible explanations for these facts, dealing with developers, hackers, and the PHP language:

PHP application devs do not make a good job at securing their code: they do not care, or they do not know how, or they try but fail. PHP is often a self-taught first and only programming language for non professional devs, whose codes will stay online forever. Also, as PHP is easy and popular, more bugs are written with it.

PHP bugs may be intensely sought for because, when found, a flaw often allows to hack into many servers: a big reward for hackers, a huge pain for system admins hosting these applications. For instance, 64 vulnerabilities are listed in 2014 for the popular Joomla!, Drupal and Wordpress CMS, while million instances of these are deployed worldwide. Every such vulnerability means checks, updates, tests for the sysadmins, or leaving the servers open to hackers.

The PHP language and its libraries are not immune to security issues, as any other software. However, as the codes are running online, consequences are dear. There are 31 core-PHP vulnerabilities published in 2014, to which issues from key libraries such as PEAR or PCRE may be added. The PHP language itself does not help developers: a taint mode which could help prevent many issues by detecting bad programming has been rejected several times. RIPS is a static analysis tool available to detect such PHP issues from the source code. Earlier versions of PHP had default settings (e.g. register_globals or magic_quotes) which made it very easy to write insecure code. These features are now off by default (since 4.2), marked as deprecated (5.3) and scheduled for removal (6.0).

The situation is somehow worsened by the poor state of PHP installations.

Who?

The editor of this page is Fabien Coelho. I'm a researcher and teacher in computer science. I'll try to update the figures cited here from time to time. The scripts and queries used to compute these figures are available upon request. Feel free to suggest other possible explanations or to improve the precision of the analysis.