The CVE is a dictionary of vulnerabilities maintained by the MITRE Corp. A unique identifier is associated to security vulnerabilities found for reference. The database can be searched on NIST NVD (National Vulnerability Database) page.
One can query the database for keywords (e.g. PHP) and dates. It is a little bit crude:
there may be PHP-related vulnerabilities without the PHP keyword in them (say a bug in the PCRE library may affect PHP)
some vulnerabilities may have the keyword without being directly related to PHP (a description may contain a reference to a PHP web page).
a vulnerability report may indicate many vulnerabilities or they may be scattered into several reports.
However a quick check through the search results show that the returned vulnerabilities are indeed mostly related to PHP, so although the precision is not down to the unit, the overall picture seems sincere.
It returns the following figures:
Year PHP-related Total Ratio
2000-2009 11469 38230 30.0%
2010-S1 884 2551 34.7% 2009 1912 5733 29.9% 2008 1962 5634 34.8% 2007 2346 6517 36.0% 2006 2840 6603 43.0% 2005 1396 4928 28.3% 2004 490 2450 20.0% 2003 183 1515 12.0% 2002 240 2156 11.1% 2001 80 1677 4.7% 2000 20 1017 1.9%
By selecting the network access vector, one can also figure out that 7493 out of 7601 (98.5%) PHP-related vulnerabilities can be exploited remotely.
One can also play with the vulnerability category, although most vulnerabilities do not seem to be explicitely tagged: only 964 out of 7601 (up to 2008) are tagged. Among these, 790 (81.9%) are directly or indirectly related to a lack input of sanitization (code/command/SQL injections, input validation, cross site scripting, path traversal).
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, 127 vulnerabilities are listed in 2008 and 144 in 2009 for the Joomla! CMS and its many components. 110 of which in 2008, and 115 in 2009, are given a High severity. According to the software website, 100,000s instances are deployed worldwide... Other popular CMS also got significant vulnerabilities in 2008 and 2009: Drupal 79 and 145, Wordpress 61 and 31. 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 about 19 core-PHP vulnerabilities published in 2008 and 22 in 2009 (note that they may have numbers from another year, possibly because they were not disclosed immediatly). The PCRE library used by PHP also had 4 vulns in 2008. The PHP language itselft does not help developers: a taint mode which could help prevent many issues by detecting bad programming has been rejected several times. 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 editor of this page is Fabien Coelho. I'll try to update the figures cited here from time to time. Feel free to suggest other possible explanations.