Photo by Christopher Gower on Unsplash
Security warnings are only useful if someone acts on them. Research that surfaced recently made that point in the most direct way possible: two serious flaws in PHP, a programming language quietly running on a huge proportion of the world's websites, had been flagged and fixes made available. More than 500 live websites were still running the vulnerable code anyway. The patches existed. The warnings were public. The attacks followed. That is not a story about sophisticated attackers finding something nobody knew about. It is a story about what happens when the gap between a known risk and a dealt-with risk stays open for too long.
What the research actually found
The two PHP vulnerabilities are serious enough to allow an attacker to take meaningful control of an affected website or extract sensitive information from it. The finer technical details of how each one works matter less than one straightforward fact: fixes were available, security advisories were circulating, and over 500 sites were still exposed when researchers went looking. These were not newly discovered zero-day flaws that caught everyone off guard. They were documented, patched, and publicly flagged. The window of exposure was entirely preventable.
Why this keeps happening to business websites
The pattern is not unusual, and the reasons behind it are not mysterious. A vulnerability gets discovered, a fix gets released, the security community raises the alarm, and a meaningful number of websites never apply the update. Three causes come up again and again.
- Owners do not know what their site runs. Many small business websites were built by an agency, a freelancer, or someone who left years ago. The owner knows the site exists and broadly what it does. The underlying technology stack, the programming languages, frameworks, and version numbers, is not something they have reason to think about until something breaks.
- People assume their hosting provider handles it. Some hosting environments do apply certain updates automatically. Many do not, particularly at the application layer where PHP lives. Assuming someone else is managing this is one of the most common ways unpatched software persists.
- The update gets deferred. The site is working. The business is busy. Applying a patch involves some risk of temporarily breaking something. The intention to deal with it becomes next month, then quietly never.
None of these are unreasonable responses from a small business owner who is not a technical specialist. But collectively, they create exactly the kind of exposure researchers keep finding across hundreds of live sites.
PHP is probably on your website whether you know it or not
WordPress powers somewhere around 40 percent of all websites on the internet. WooCommerce, one of the most widely used e-commerce platforms for smaller businesses in the UK, runs on WordPress. Both are built on PHP. If your business has a website, and almost every business does, there is a real possibility PHP is running somewhere in it regardless of whether you have ever thought about that. We have written about this before: your website probably runs PHP, and the time to check its status is not after an incident. A government security agency has already called on businesses to treat PHP patching as urgent. That advice has not changed.
PHP itself is not the problem. It is mature, actively maintained, and genuinely secure when kept current. The problem is running versions the development community has already identified as unsafe, documented the risks for, and released fixes to address. That is a situation with a clear resolution, and it is one that a large number of small business websites are still sitting in.
Three things worth checking right now
You do not need to become a PHP expert. You do need clear answers to a small number of questions about your website.
- What version of PHP is your site running? Your hosting control panel will usually show this. If it is a version past its end-of-life date, it is receiving no security updates at all, not even for critical flaws like the ones described here.
- Who is responsible for keeping it updated? Get a clear, written answer from your hosting provider or developer. Ambiguity here is a risk in itself. "We assumed you handled it" is not an answer that offers any protection after a breach.
- Is anyone looking at your site for known vulnerabilities on a regular basis? Running a business website with no visibility into its security posture is roughly equivalent to leaving a door unlocked and assuming nobody will try the handle. Regular vulnerability scanning gives you that visibility before something goes wrong rather than after.
For any site that does more than display basic information, anything with a login, a contact form handling personal data, or an e-commerce function, the case for a structured approach to patch management is straightforward. Knowing what you are running, knowing when patches are available, and having a reliable process for applying them is how you avoid becoming one of the next 500.
The practical takeaway
The two PHP flaws at the centre of this story were not secret. The fixes were not difficult to apply. The only real difference between the sites that were hit and the sites that were not was whether someone had acted on information that was already publicly available. That is a gap worth closing, and it starts with knowing what your website is actually running. If you want a clearer view of where your business sits from a vulnerability standpoint, vulnerability management is a good place to start that conversation.