PHP’s CVE vulnerabilities are irrelevant

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, January 02, 2015

Follow me on Twitter as @mattiasgeniar

ircmaxell wrote a good blog post about usage of PHP versions in the wild, which shows the vast amount of different versions used. The summary is meant to provide an overview of “secure” vs. “unsecure” PHP installations, based on the known CVE’s in previous PHP versions. The conclusion is that less than 25% of the PHP installations are secure. However, I think those numbers are all irrelevant.

I’m unsure if the list is complete, but here’s an overview of known CVE’s for PHP. There’s a lot of them.

I’m active in the hosting sector. I manage and secure servers, used by clients to host their PHP code. Do you know how many hacked sites and servers I’ve seen due to PHP CVE’s? Absolutely zero. How many are caused by outdated Content Management Systems or plugins? All of them.

We still see PHP 5.1 and 5.2 in the wild. They’ve been unsupported for years. They have known security vulnerabilities. But those are not being abused. What’s an unsecure PHP installation? The one with an outdated WordPress or outdated plugins. Or a Drupal installation that isn’t maintained. Or yet another WYSIWYG editor with upload functionality that is installed once, and never updated.

The most common security flaws are still the ones that get websites and servers hacked. The CVE’s in the PHP code aren’t easy to exploit. But a SQL-injection or Remote Code Execution vulnerability in a popular CMS? Those are the real danger.

I gave a presentation at PHP Benelux 2014 titled “Code Obfuscation, PHP shells & more: what hackers do once they get passed your code”. In that talk, I never mentioned PHP CVE’s. During the many discussions afterwards, CVE’s were never the topic.

I love PHP as the language. I still do all my coding in it. Which is why it pains me to say this, but PHP’s security problem isn’t the CVE’s of the core language, it’s the users. It’s in the nonchalance that users install their CMS and not look at it again. That’s what gives PHP (among the many other things) a bad name.

WordPress 3.7+ does a really fantastic job on mass-patching security updates to all installations (if enabled). That still leaves Drupal, Joomla, Magento, …

Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.