I mostly disagree on your disagreement unless the entire project was based on top security practices and good code in the first place. The vast majority of these web panels are a security nightmare.
These PHP systems be it cPanel, wordpress or PHP itself are most likely the biggest target besides windows. It's incredibly uncool stack especially here but it is running most of the "independent" small web.
They cannot be that bad if they are managing to be ductape of the internet.
I've done PHP development for over 20 years, including some pretty large projects. I've never had a situation where a security flaw in PHP itself forced me to scramble to patch something before it got hacked.
On the other hand, for my Linux servers, I had to do that twice in the last month with CopyFail and DirtyFrag.
That's a fair point, using 'interpreter' specifically was imprecise language on my part. My main point was php-fpm is developed by the core PHP team and is often the default in how PHP projects deploy these days, and that CVE was very similar to the recent 'fail' LPE vulnerabilities in the kernel.
> They cannot be that bad if they are managing to be ductape of the internet.
Oh, it very much can be that bad. Most "security" relies on the Hungry Tiger Theory of Security(tm).
My system doesn't need to be "secure". My system simply needs to be more secure than yours. As long as there is an easier and/or more valuable target somewhere, I'm "secure". I don't need to outrun the hungry tiger; I only need to outrun you outrunning the hungry tiger.
That theory, of course, doesn't hold anymore when there are enough tigers to simply eat everybody. And that's what AI did; it multiplied the tigers enough that they can just gorge on everything.
Now, people are going to have to put in "actual security" or lose real money over and over and over. And since everybody has outsourced everything, nobody knows how to fix it quickly. The lawyers are going to have a field day.
At the end, however, we'll have real security on our internet facing systems. But man, it's going to be painful for a while.
Every time I venture in the the web server's error log, I see all of the skiddie's attempts at accessing the most common things with most of them being .php files. Lots of /wp/admin.php and /phpadmin/ type requests. Of course, none of those are available which is why the requests are in the error log. I've never paid attention, but I wonder how long (as in how little time) for a new server to come online before it starts to get probed by a skiddie. Whether they are just war dialing IPs or paying attention to new domain announcements but I'd put it on a few hours tops.
Dismissing these as script kiddie attempts is no longer correct. This is a real industry now. It’s not like the large scale actors are going to pass up a valid unpatched vector just because it’s old hat.
Imagine this; ~40% of public websites run wordpress. (based on some AI-gen summary, even if fewer it is still an important percentage).
So you might be spinning up a new instance with 40% probability. It makes sense in mass vulnerability explotation and detection to aim for highest success rate first.
Especially when the IPv4 space is so easy to scan nowadays. And you have services like Shodan that do just that daily.
I’ve tested this recently (this post week). Had a dns entry up and pointing to an nginx server for ~12 hours, zero requests. 17 seconds after the letsencrypt cert was issued, the floodgates opened. Over a dozen of requests per second.
I don't think it's necessarily specific to LE but rather to public certificate transparency logs. LE being free and easy to automate means it's very widely used these days, but if you theoretically go to a "pay" root CA and get a cert that covers thing.com and www.thing.com , the same probing will happen on the same time scale.