Hosting company advised us to avoid PHP for security reasons. Are they right?

It's not so much that PHP itself has security problems (assuming needed security updates), as it is there exists a lot of popular PHP-based software with rampant security problems. You could fault PHP for being a language that gives you enough rope to choke yourself, but the real problem is just how prevalent vulnerable PHP code actually is. One need look no further than the Stack Overflow PHP tag to find PHP newbies writing horrifically vulnerable code based on some atrocity of an old tutorial.

Additionally, a significant number of popular PHP software known for their rampant security flaws is based on very old code and coding practices. Many of these old practices are considered bad-practices because of inherent security problems.

This, to me, sounds about like telling someone to never drive so they won't be in a car accident.

Pretty much yes. Better advice might be along the lines of "don't drive an old car with no airbags".

My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system.

Not necessarily. If a user uses the same password for the WordPress site and cPanel, compromising the WordPress password also compromises cPanel. That would be the fault of the user. Hackers rarely need to get that far though, and just use a PHP shell.

I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?)

Not necessarily true. You could use a 3rd party service to handle the mail sending. Then the service handles the dynamic server scripting and take over the security implications. There are numerous such services available with varying feature sets, and they are popular for powering contact forms on statically generated sites.

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Some, but not much. PHP does involve some active code, in both PHP and the server software which executes it. If there were ever a security vulnerability in that process which did not depend on specific PHP code, it could be exploited. While that risk is tiny, it's a risk a server with no such support does not have.

"Right" might not be the right word, but "wise," "prudent" and "conscientious" come to mind. PHP has, since its inception, adhered to a philosophy that devalues correctness in software. There is a huge number of situations a program can encounter where other languages (e.g. Python) would give up and throw an error to tell you that your program is wrong, but PHP instead chooses to do something nonsensical and carry on as if things were just fine.

Keep in mind that correctness is very important to security. A language that is prone to silently ignoring errors left and right will have more than its fair share of programs with security problems. For example, you may have a piece of code that your programmers think is protecting against a certain attack, but in fact is being skipped because the interpreter ignores an error.

In addition:

• PHP is designed to appeal to the lowest denominator of programmers with the least motivation to get good at their craft. And thus the most likely to write insecure software.
• The PHP team has a history of profoundly flawed attempts at fixing common security problems. Look for example at SQL injection protection, which betrays repeated flawed attempts at fixing the problem: real_escape_string (because the original escape_string was broken, but they didn't remove it until later) vs. addslashes vs. mysql_escape_string/pg_escape_string and so on. Whereas pretty much every other language just went with prepared statements and query parameters and got a design extensible to all databases right on the first try.

So for all the talk in other answers about how you can write secure software in PHP, if you try it you're very much swimming against the current.

PHP's security problems can generally be narrowed down to two categories

Unpatched systems

As of right now, Wordpress stats shows over half of all users are running PHP on versions of PHP that are past End of Life (PHP 5.2 - 5.4). In two weeks, PHP 5.5 goes EOL and then it jumps to about 80% of all installs. Now, to be fair, some Enterprise/LTS Linux installs will backport security fixes, but the vast majority of them are not using backported fixes (or some don't patch their systems). Worse, lots of people refuse to upgrade PHP itself. Either they can't/won't update their code, or they think that older software is more stable.

Wordpress (#1 PHP application used worldwide) made a concerted effort to make sure users stay up to date on the software itself (and they've made great strides), but despite that, only 40% are running the latest version of Wordpress. That means some 60% may have an unpatched security vulnerability. And that's just the base program. Wordpress has a massive ecosystem of plugins, and many of them have security vulnerabilities of their own.

Then there's other issues, like lots of older code using the defunct mcrypt library. And that's just one PHP plugin you can compile.

Now extrapolate this to the servers not running and reporting stats to WP. It doesn't paint a pretty picture. Last summer I found a website running an e-commerce page that was still on Apache 1.3.3 and PHP 4.1.2. It was so old it had SSLv2 enabled...

Bad Practices

If you hang around SO PHP questions long enough, you'll see a lot of people practicing bad code. Some of the problems I've seen over the years

• SQL Injection
• Thinking MD5 is a good way to protect passwords
• Using outdated APIs int their code (i.e. ext/mysql, the old MySQL connector)
• Trusting user input to execute code (i.e. using eval with user supplied data)
• Not turning off security risks in the PHP code (i.e. the exec function)

To the untrained, this looks like a PHP problem, when it's the coders and their ecosystems that produce the problems. Maybe they were in a hurry. Maybe they hired some guy who does this in his spare time and "just made it work".

Can it be secure?

YES! But that security requires some effort. Keep your PHP install up to date. Heck, keep your whole server up to date. Host won't do security and patches? Find another host. (I'm amazed at the people who balk at this). Build your own server (VMs are cheap). But above all, pay attention. Learn all you can about security. Don't just let your website and server go out to sea.

Someone who tells you PHP is insecure is just being lazy.