Hi!
So to be super clear: I'm just pointing out that there used to be issues here; sometimes the community's interests do not exactly align. Consider me in the devil's advocate role again: I'd be interested to hear an insider's opinion (Stas?) on how security issues are handled these days and what the future outlook is, https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/PH...
OK, so it's a big topic but I can do some quick survey and we can get deeper if you want to. So:
Despite what you see there, there are not a lot of genuine security issues in PHP. Unfortunately, CVE issuance process is such that it does not involve any consultation with the vendor about classifying the issue and assigning severity. You can just create CVE ID for anything and how they assign severity is kinda mystery to me, but one thing is clear - PHP core team is not consulted about it, at least not in any way I've ever noticed. It doesn't mean those are all wrong, but some probably are, and a lot are misclassified.
Now, for the substance of the issues. Many of them are unserialize() issues. For this, without getting too much into the woods, I can only say this: there seems to be no way to make unserialize() robust against untrusted data, and it has to do with how references, object construction, object destruction (notice the similarity with what Hack intends to drop? It is not a coincidence) and serialization support works in PHP. There is too much internal structure exposed to make it work with untrusted data now. Maybe if we redesigned the whole thing from scratch, it _could_ be possible, but even then I kinda doubt it, at least not without sacrificing some feature support. For now, the best approach to this is consider using any unserialize() on untrusted data inherently insecure. It's just too low-level to be sure no corner case ever does anything strange.
Some of those are genuine security problems, which now mostly concentrate in several extensions, which has been either under-served or have very wide exposed areas. Namely, wddx - obscure format that suffers from issues similar to unserialize() and in addition lack maintainership, phar - which wasn't really designed to deal with untrusted scripts but seem to kinda be moving that direction, and gd - which mostly relies on libgd and every issue there is also automatically extends into PHP. The latest two would probably benefit from a good fuzzing testing, but nobody took on it yet. I suspect if hhvm uses the same or derived code - and it likely does, I don't think they reimplemented libgd from scratch? - many of those would also be present in hhvm if hhvm supports these (no idea).
There are also some long-standing debates about how randomness is handled (basically, there are many ways to get randoms, and most of them are not suitable for security-related randomness) and some DoS issues in PHP hash tables - the latter are mostly resolved, but in kinda temporary way, so there's more work to be done.
Some of these issues - like https://bugs.php.net/bug.php?id=74310 - are definitely not security issues at all. Yes, you can create bad code that hits some corner case and produces segfault. That shouldn't happen, but this being complex C code which is 20 years old, it does. This has absolutely nothing to do with security, and whoever decided to issue CVE to it and assign 7.5 severity (https://www.cvedetails.com/cve/CVE-2017-9119/) has done a very sloppy job. As I said, this is done with zero communication with actual PHP team as far as I know, which is very sad, but this is the state of affairs. Some of those are, I am sorry to say, complete baloney, e.g. https://www.cvedetails.com/cve/CVE-2017-8923/ says:
<<The zend_string_extend function in Zend/zend_string.h in PHP through 7.1.5 does not prevent changes to string objects that result in a negative length, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact by leveraging a script's use of .= with a long string.>>
This is nonsense - unless you run with no memory limit at all (nobody sane does that) and specifically allow your code not only accept infinite untrusted data, but have it fed specifically to certain functions arranged into a specific code pattern, no remote attacker can do it. There are many issues that have similar claims, none of them are actual security issues.
Some are also assigned to PHP despite them being application issues, e.g. https://www.cvedetails.com/cve/CVE-2017-9067/. To add insult to injury, this is 2017 CVE about a version that was EOLed in 2014. The data quality seems to be very sad there. I tried to figure out how to make it better a while ago but pretty much gave up on it because I couldn't find anybody responsible or at least concerned about this sad state of things.
OK, this came out super-long and kinda ranty (sorry!), so I will stop for now, but if you have any questions about it, please feel free to ping me, and I will be glad to discuss it.