Your website was built once. The software running underneath it changes every month, and someone has to own that job. That job is website maintenance for a small business, and it’s easy to assume someone else has it covered.<\/p>\n
Last week gave us a good reminder of why. On October 21, the PHP project released emergency fixes for two critical security flaws, nicknamed PHP2Shell (PHP.net<\/a>). PHP runs nearly 70% of websites whose server-side programming language can be identified, including WordPress, which runs about 40% of all websites (W3Techs<\/a>). Both flaws were rated 9.2 out of 10 for severity. In plain English, an attacker could use them to run their own software on an unpatched web server.<\/p>\n This one also showed how much faster things move now. The flaws were uncovered through security research involving Calif, OpenAI and Wiz, with AI tools playing a significant role in the research (Wiz<\/a>). Details leaked before the fix was ready. Amazon’s threat team saw attackers going after the flaws four days before the patch even shipped, and by October 24 researchers had confirmed successful code execution against deliberately vulnerable honeypot servers (BleepingComputer<\/a>). The patch came out on a Wednesday. By the weekend, the race was on.<\/p>\n The good news is that most large hosting companies moved fast. The more useful question for a business owner is a simpler one: if this happened to your website, who would have handled it?<\/p>\n For many established businesses, the website story goes something like this. A web designer or a nephew with good taste built the site five or six years ago. It looked great, it launched, and everyone moved on to running the business. The designer may have moved on too.<\/p>\n The site kept running, so it felt finished. Under the hood, though, a website is a stack of software that each needs its own updates:<\/p>\n PHP2Shell was a good example of how easy it is to look in the wrong place. Updating WordPress did nothing for this flaw, because the fix lived in PHP on the server (WordPress.org<\/a>). A WordPress security plugin wasn’t a substitute for patching PHP either. Some hosts and firewall services blocked known attacks while they patched, but they were clear that patching PHP was still required (Cloudflare<\/a>). A business owner who dutifully clicked “update” in the WordPress dashboard could still have been exposed.<\/p>\n Age matters too. About 35% of reporting WordPress sites run PHP versions that no longer receive security fixes from the PHP project (The Repository<\/a>). PHP 8.2, a common version, reaches end of life on December 31, 2026 (PHP.net<\/a>). It’s not uncommon to see a business site that hasn’t had its server version reviewed since the day it launched.<\/p>\n The window to react is also shrinking. Mandiant found that the average time between a flaw becoming public and attackers using it dropped to five days in 2023, down from 32 days in the prior two years (Google Cloud \/ Mandiant<\/a>). With PHP2Shell, attackers were already probing before the patch was released, and successful code execution was confirmed three days after it.<\/p>\n The short answer is “it depends on your setup,” which is exactly why so many sites fall through the cracks. Here is how the pieces usually split:<\/p>\nThe website nobody owns<\/h2>\n
\n
So who is actually responsible?<\/h2>\n