That's an interesting story, and I think highlights that there's a lot to unpack with this recent issue.
Apologies in advance for the big post.
PHP was found to have catastrophic vulnerabilities, but I don't believe that makes it much different than any software or system that has evolved over years/decades. The scale of the emergency is due in part to php's popularity - it's
used by about 70% of internet sites. If it were only 10%, we would have a problem 1/7th the scale. [Side note, php is the engine behind these forums and nearly all of the custom software built for Army.ca.]
In reality, these emergencies are happening about weekly in the Cyber world now, but they rarely make the mainstream media so most are blissfully unaware of the chaos IT folks are currently living.
To split hairs, the vulnerability was not with Drupal (although Drupal has definitely had its share!) One analogy might be a recall on an engine used in many car models - not the fault of the car, probably not even the manufacturer if they just installed the engine. But it's a problem with their 'platform' so it matters to them and affect their product.
To me, the 'tell' is how fast the issue is fixed. In this case, because the vulnerabilities were responsibly disclosed, there were fixes available the day the vulnerabilities were announced. That's not always the case, sometimes because bad actors start exploiting before the vendors know about it, but sometimes because the vendor simply ignores the responsible disclosures for months. The php team was the former, not the latter, which is good, it speaks to their engineering and process maturity.
I'm nearly certain that whatever industry standard solutions were used instead of php/Drupal have their own vulnerabilities, either discovered or latent. There is a very strong case for using common tools across projects though, even if just for a supportability/maintainability approach, so... good call.
PHP is open source, which means literally anyone can aim AI at its source code and find vulnerabilities humans have missed for years. Proprietary solutions such as Microsoft's ASP, .NET, or Apple's XCode, Swift etc. are closed - if Microsoft and Apple are not scrubbing their code (they are) then the vulnerabilities will remain, and remain hidden.
What's really interesting to me is AI's disruption in this field. If you look at
vulnerability statistics, they were on a steady increase since 2018, from about 16k annually to about 48k annually. That means reported vulnerabilities tripled over 9 years. But the stats show that they have almost doubled already in 2026 over 2025 - and we're not done yet!
This does not mean that more sloppy code was produced in 2026 than any previous year, in fact it kinda tells the opposite story. Over 72k vulnerabilities have been found (and the majority presumed fixed) this year, setting a record for strengthening software. Some of these vulnerabilities are literally decades old, and no human had the insight to find them. (Or they remained "NOBUS" weapons for three-letter acronym organizations.
)
So once we fight through the chaos of replacing all the sloppy code with properly engineered code (or sloppy code that's been deeply reviewed by AI), I predict these numbers will go down again. Will 2027 be that drop? Not so sure, but I do believe we'll see it in 2028.
Then again, one job that AI has truly destroyed is predicting the future with any clarity.
thehackernews.com
