PHP Flaw Security Guide for UK Small Businesses

PHP Flaws and Your Website: A Plain-English Security Guide for UK Small Businesses

Thirty-two UK government services went dark this week. Not because of a strike, a funding row or a storm, but because of three letters most business owners have never typed: PHP.

If you run a small business website, you are probably thinking this has nothing to do with you. You sell candles, or you book plumbers, or you run a physio clinic. You don’t “do” programming. Fair enough. But there is a decent chance your site runs on PHP anyway, because a huge slice of the web does, including WordPress, Joomla, Drupal and Magento shops. When a flaw like this lands, the size of your company doesn’t protect you. If anything, it makes you easier prey.

This guide skips the jargon. It walks through a simple audit you can run yourself, or hand to your web person with a clear brief.

What actually happened

A critical vulnerability in PHP, the scripting language behind a large share of the internet, forced departments to pull services offline while they scrambled to patch. CNBC explained the situation for a general audience, and the short version is this: attackers can potentially run their own commands on an unpatched server.

That sounds abstract. Here is the concrete version. Someone could use your website as a doorway, steal customer details, or quietly plant malware that redirects your visitors to something nasty. You might not notice for weeks.

Worth it? Absolutely. Checking takes an afternoon.

Step one: find out whether your site uses PHP at all

You don’t need to read any code. Three quick routes:

Ask whoever built the site. A plain email works: “Is our website built on PHP, and which version is the server running?”

Check the platform. If you log in to a dashboard that looks like WordPress, Joomla, Drupal or Magento, you are on PHP. Full stop.

Look at your hosting control panel. Most hosts show the PHP version under a setting called “PHP selector” or “Software”. Take a screenshot and keep it.

One caveat: some small business sites sit on website builders like Wix or Squarespace, where the provider handles the server side for you. In that case your job shrinks to one email asking the provider whether they have patched.

Step two: check the version number

This is where most owners trip up, because they assume “updated” means “safe”. It doesn’t. Updated to what?

Krebs on Security listed the fixed releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your host says you are running 8.2.20, you are behind, and you should ask for the patched version in writing.

Older versions are the bigger problem. If your site is still running PHP 7 because “it works fine”, that version stopped getting security fixes a long time ago. It isn’t a case of being slightly behind. It is unprotected, and no patch is coming. Moving off it is the single most useful thing you can do this month, even if it costs a few hundred pounds in developer time.

Step three: audit your plugins and themes

Here’s the thing about WordPress sites in particular. The core software is rarely the weak link. The plugins are. A contact form plugin you installed in 2021 and forgot about, a slider you stopped using, a theme from a developer who vanished.

Go through your plugin list and ask three questions of each one:

• Do we still use this?
• Has it been updated in the last twelve months?
• Does the developer still exist?

If the answer to any of those is no, delete it. Deactivating isn’t enough, because an inactive plugin can still be exploited. Delete it.

How regulated industries handle this

Small firms often assume that security is something big companies buy their way into. It is more useful to look at how heavily regulated sectors treat it, because they don’t get to skip the boring steps. Banks, insurers and licensed online operators all run web stacks that lean on PHP in places, and they all face audits, patching deadlines and breach-reporting duties set by regulators.

The lesson isn’t that you need their budget. It is that they treat patching as a scheduled routine rather than a panic response. Operators in Europe, for example, work under licence conditions that force documented security processes, regular testing and clear incident logs. Licensed operators across the continent have to keep adjusting their security and compliance practices as obligations shift from one market to the next, and the latest news from European Gaming shows how those operators respond in practice, from tightened verification routines to revised reporting processes.

What you can copy from them costs almost nothing: a written patch schedule, a named person responsible, and a log of what changed and when.

See also: Book Your Bus to Melaka Online: The Ultimate Stress-Free Guide

Step four: sort out your backups

Backups are the difference between a bad afternoon and a business-ending week. Yet the NCSC’s small business guide lists backups as one of its core five steps, and plenty of small firms still treat them as optional.

Check these four things:

1. Are backups running automatically, daily or at least weekly?
2. Are they stored somewhere other than the same server as your site?
3. Has anyone actually tried restoring one?
4. How many days of history do you keep?

The third question is the one people skip. A backup you have never restored is a hope, not a backup. Ask your host or developer to do a test restore onto a spare address and confirm it works.

Step five: know who to call before something breaks

During an incident, nobody thinks clearly. So write the contact sheet now, while you are calm. It needs five lines: your host’s emergency support number, your developer’s mobile, your domain registrar’s login, your cyber insurance policy number if you have one, and the person in your business who decides things.

If you don’t have cyber cover, it is worth a conversation with your broker. Many small firms assume a general business policy covers a hacked website. Often it doesn’t, which is worth checking against the guidance in our piece on business insurance options before you need to claim.

Reporting matters too. The UK’s breaches survey found that 42% of micro businesses and 46% of small businesses reported a breach or attack in the period covered, so this isn’t a rare event. If it happens to you, you will not be the first on your street.

A realistic monthly routine

None of this needs to swallow your week. Once the first audit is done, maintenance looks like this:

First Monday of the month: log in, run all updates, delete anything unused. Twenty minutes.

Quarterly: confirm your PHP version with your host and check that backups still restore. One hour.

Annually: review who has admin access. Former staff and old freelancers are a classic hole. Remove anyone who doesn’t need it today.

That’s it. Not glamorous. Very effective.

Frequently asked questions

How do I know if my website uses PHP?

If it runs on WordPress, Joomla, Drupal or Magento, it uses PHP. Otherwise, ask your developer or check the PHP selector in your hosting control panel. Wix and Squarespace sites are managed by the provider, so a quick email to them covers it.

Do I need a developer to update PHP?

Often your host can switch the version with one click, but sites running older plugins can break afterwards. Back up first, switch on a test copy if possible, and keep a developer’s number handy in case a plugin fails.

Is a small business really a target?

Yes. Attackers use automated scans that hit thousands of sites an hour, and they don’t check your turnover first. Small sites are attractive precisely because they are usually less well maintained than larger ones.

How often should I run backups?

Daily if you take orders or bookings online, weekly if your site rarely changes. Store copies off the server and test a restore every quarter. A backup you have never restored shouldn’t count as protection.

What should I do if I think I have been hacked?

Call your host first and ask them to isolate the site. Change every password, restore from a clean backup, and report it to Action Fraud. Tell affected customers promptly if their data may have been exposed.

The takeaway

The government outage made headlines because of its scale, but the underlying lesson fits a two-person business just as neatly. Know what your site runs on. Keep it patched. Delete what you don’t use. Test your backups. Write down who to call.

None of that needs a security degree. It needs an afternoon this week and twenty minutes a month after that.