PHP is considered an insecure language to develop in not because of secret backdoors put in by the PHP language developers, but because it was initially developed without security as a major concern and compared to other languages/web frameworks its difficult to develop securely in it.
E.g., if you develop a LAMP/LAPP (linux+apache+mysql/postgresql+PHP) web app, you have to manually code in input/output sanitation to prevent SQL injection/XSS/CSRF, make sure there are no subtle calls to
eval user-supplied code (like in
preg_replace with a '/e' ending the regexp argument), safely deal with file uploads, make sure user passwords are securely hashed (not plaintext), authentication cookies are unguessable, secure (https) and http-only, etc.
Most modern web-frameworks simplify many of these issues by doing most of these things in a secure fashion (or initially doing them insecurely and then getting secure updates).
The risk of there being a secret backdoor in an open-source PHP is small; and the risk is present in every piece of software (windows/linux/apache/nginx/IIS/postgresql/oracle) you use -- both open-source and closed-source. The open-source ones at least have the benefit that many independent eyes look at it all the time and you could examine it if you wanted.
Also note in principle, even after fully examining the source code and finding no backdoors and fully examining the source code of your compiler (finding no backdoors), if you then recompile your compiler (bootstrap by using some untrusted existing compiler) and then compile the safe source code with your newly compiled "safe" compiler, your executable code could still have backdoors brought in from using the untrusted existing compiler to compile the new compiler. See Ken Thompson's Reflections on Trusting Trust. (The way this is defended against in practice is by using many independent and obscure compilers from multiple sources to compile any new compiler and then compare the output).