PHP Critical Vulnerability: What WordPress Owners Must Do

Security researchers have issued urgent warnings about two critical vulnerabilities in the PHP engine, with severity scores reported at CVSS 9.2. The technical detail matters less than the practical outcome: an unauthenticated attacker can achieve remote code execution on a vulnerable server, and in some cases that happens before your application code runs at all.

If your website runs WordPress or WooCommerce, it runs on PHP. That is the whole reason this advisory deserves your attention this week rather than next month.

This guide is written for business owners rather than server engineers. It explains what the flaw does in plain English, how to find out whether your site is exposed, and what to do in the next 24 to 48 hours depending on who looks after your website.

What a PHP critical vulnerability actually means

PHP is the programming language that runs on your web server and generates the pages your visitors see. WordPress is written in PHP, and so is WooCommerce, along with almost every plugin and theme you have installed.

A remote code execution flaw is the most serious kind of bug a language can have. An attacker can send crafted input to your server and get it to run their own commands. They are not limited to reading a page or changing a form field. They can potentially write files, read data or take control of the hosting account.

Two words in the current advisory carry most of the weight. Unauthenticated means the attacker does not need a login, a password or any account on your site. Before your application code runs means the flaw sits in the engine itself, so WordPress, your theme and your security plugin never get the chance to block it. That second point catches people out, because a well-maintained plugin stack is not automatically a defence here.

This is not a hypothetical category of risk. Security researchers have tracked mass exploitation of PHP flaws before, including CVE-2024-4577, a CVSS 9.8 issue affecting Windows servers running Apache with PHP-CGI, which threat intelligence firm GreyNoise warned was being exploited at scale. Automated scanners find exposed servers quickly. There is no quiet window where nobody notices.

Why WordPress and WooCommerce sites are in the firing line

Anything serving web requests through an affected PHP installation is in scope. That includes small brochure sites, membership sites and busy WooCommerce stores alike. The size of your business has no bearing on whether a scanner finds you.

For shops, the consequences run wider than a broken homepage. A WooCommerce site holds customer records, order history and the workflows that keep the business running. A compromise can mean data exposure, fraudulent changes and a clean-up bill that dwarfs the cost of an hour of developer time.

First, find out what your site is actually running

You cannot make a sensible decision until you know your PHP version. There are three quick routes.

• In WordPress admin, go to Tools, then Site Health, then the Info tab, and open the Server section. The PHP version is listed there.
• Log in to your hosting control panel and look for the PHP version or PHP configuration selector attached to your domain.
• Ask your host directly, in writing, and ask them to confirm whether that version is still receiving security fixes.

Write down the version number and the date it was last changed. If your host cannot tell you, treat that as a warning sign in itself.

Your action plan, depending on who maintains your site

The right next step depends entirely on who holds the keys. Work out which of the following applies to you and act on that section only.

If Soup Digital maintains your site

You do not need to do anything. Patch management is part of the maintenance service, and we monitor the versions your site runs. Where an update carries a risk of breaking something, we test it before it goes live and tell you if a short window of disruption is likely. If you are not sure whether your site sits on a maintenance plan, send a quick message and we will confirm.

If another developer or agency maintains your site

Contact them today, in writing, and ask three specific questions. Which PHP version is the site running? Has it been patched against the latest critical PHP advisories? What date was that applied? A vague answer is not an answer. Ask for confirmation once the work is done, and keep the email.

If you get no clear response by your deadline, assume the site is unpatched and plan accordingly. You can verify the PHP version yourself using the steps above, which gives you a way to check whether anything actually changed.

If you maintain the site yourself

Take a full backup first, including the database, and confirm you can restore it. Check that your theme and plugins are compatible with the version you are moving to. Update PHP through your hosting control panel, then test the front end, the admin area and a test checkout if you run WooCommerce. Watch the error logs for the first hour.

If the update breaks the site, restore the backup and get help. Leaving a site on a vulnerable version because the update caused a layout problem is the wrong trade.

If you cannot patch within 24 to 48 hours

Consider taking the site offline temporarily. This is a serious step and it costs you enquiries or sales, so weigh it honestly. But an unauthenticated remote code execution flaw that is being actively scanned for is a genuine risk, and a day of downtime is usually cheaper than a compromised server, a malware clean-up and a difficult conversation with your customers.

What a temporary takedown looks like in practice

A takedown does not mean deleting anything. It means putting a holding page or maintenance mode in front of the site so visitors cannot reach the vulnerable application while you keep working behind the scenes. Your host may be able to restrict access to specific IP addresses so only you and your developer can reach the admin area.

Tell your customers what is happening and when you expect to be back. If you take orders by phone or email, keep that route open. Restore normal service only once the patch is applied and you have checked for signs of tampering.

After patching, check for signs of compromise

Patching closes the door. It does not tell you whether someone came through it earlier. Spend twenty minutes on the following checks, or ask your developer to.

• Review WordPress users for accounts you do not recognise, particularly administrators.
• Look for files in your uploads folders that should not be there, especially PHP files.
• Compare core WordPress files against a fresh copy of the same version.
• Check for scheduled tasks and cron entries you did not create.
• Review WooCommerce orders and settings for changes nobody on your team made.

If anything looks wrong, restore from a backup you know was clean, then change your WordPress security keys, database password, hosting password and any FTP or SSH credentials. Do that before you announce everything is fine.

Reducing the risk next time

Most of this comes down to routine. Run a PHP version that still receives security fixes and keep it current rather than leaving it for a year. Update WordPress, themes and plugins on a schedule you can stick to. Keep off-site backups and test a restore occasionally. A web application firewall reduces noise and blocks some automated attacks, but it is an extra layer, not a substitute for patching.

If nobody in your business can confidently answer the question “which PHP version are we on”, that is the real problem to solve.

Get help if you are not sure

Soup Digital is a Hampshire based WordPress and WooCommerce consultancy. We handle PHP version management, patching, backups and monitoring as part of ongoing maintenance, and we take on website rescue work for sites that have been left unsupported or have inherited a mess. You work directly with a developer rather than an account manager, so the person answering your question is the person who can fix it.

If you have read this far and still do not know whether your site is exposed, book a call with Soup Digital and we will check. It is a short conversation and it will tell you exactly where you stand.

Frequently Asked Questions

Does this affect my WordPress site if all my plugins are up to date?

Possibly, yes. Up to date plugins are always worth having, but this class of flaw sits in the PHP engine rather than in your WordPress code. An attacker exploiting it can run commands before WordPress, your theme or your security plugin is loaded. The version of PHP on your server is the thing to check.

How do I check which PHP version my site is using?

In WordPress admin, open Tools, then Site Health, then the Info tab, and look at the Server section. Your hosting control panel usually shows the PHP version attached to your domain as well. If neither is clear, ask your host in writing and request confirmation of whether that version still receives security fixes.

Will updating PHP break my WordPress site?

It can, which is why testing matters. Older themes and plugins sometimes rely on behaviour that has been removed from newer PHP releases. Take a full backup, check compatibility notes, update on staging if you have it, and test the front end and checkout. A broken layout is fixable. A compromised server is a far longer job.

Is a security plugin or firewall enough protection?

No. A firewall can block some automated traffic and reduce exposure while you arrange a patch, but it does not fix a flaw in the engine itself. Treat it as an extra layer that buys you time, not as a replacement for running a supported, patched PHP version. Patching remains the fix.

Should I take my site offline until this is fixed?

Only if you cannot get a patch applied within 24 to 48 hours. A holding page or maintenance mode stops visitors reaching the vulnerable application, but it also stops sales and enquiries. Weigh the lost trade against the risk of a breach, and keep the admin area restricted while you work.