A PHP alert went out this week. Here is the one question to ask.

What happened, in plain English

What. PHP is the programming engine that runs behind a large share of websites. WordPress, WooCommerce, Joomla, Drupal and Magento are all built on it. You never see it, in the same way you never see the engine management system in your car. On 21 October the PHP project released fixes for two flaws, tracked as CVE-2026-109618 and CVE-2026-109619, both rated critical. Per Laravel Forge's advisory, each scores 9.2 out of 10 on the CVSS v4.0 severity scale. In simple terms, a flaw of this type could let a stranger run their own commands on a web server without a password.

The Australian Signals Directorate's cyber centre (the ACSC) issued a "Critical Alert: Act Now" on the afternoon of 21 October, ahead of the full public details, telling organisations to find where they use PHP and be ready to patch (as reported by Cyber Daily). The same day, PHP released the fixed versions.

Why it matters to your business. Security researchers have reported large numbers of automated attempts to find servers that have not yet been updated, and public proof-of-concept code exists. The PHP Foundation said it had seen no evidence of successful exploitation before disclosure or against patched versions. A senior Mandiant executive cautioned that limited exploitation "may have already begun". As of Friday 23 October there were no publicly confirmed successful attacks (The Register). So this is not a story about a wave of hacked small businesses. It is a story about a window between "a fix exists" and "the fix is applied on your server", and that window is the part you can shorten.

The one question to ask

What. Send a short message to whoever looks after your site: your web host, your developer or the agency that built it. You can copy this:

"Is our website running on a patched version of PHP, with the fix released on 21 October 2026 applied? Could you confirm the PHP version and that the update has been done?"

Why it matters to your business. You do not need to understand the flaw. You need a named person to confirm, in writing, that the update has been applied. That one reply tells you whether the gap is closed, and it creates a record if you are ever asked what you did.

How to read the answer. The fixed versions are in the table below. A good reply names your version and says it has been updated.

One catch worth knowing. If the answer is PHP 8.1 or older, the version number alone does not tell you whether the fix is in. Those branches no longer receive official releases. Per Laravel Forge's advisory, package maintainers backported the fix to them as new package revisions, and the version number stays the same before and after. So a reply of "we are on 8.1.34" is not enough. Ask whether the security update has been applied. And if the site is on 8.1 or older, a move to a supported version is worth putting on the list for the new year.

Does this apply to me?

What. It applies to any site running its own PHP. That includes most WordPress, WooCommerce, Joomla, Drupal and Magento sites, plus custom-built sites. If your site is on a hosted website builder, keeping the underlying software current is the platform's job, not yours, although it never hurts to ask.

Why it matters. Do not assume the update happened automatically. Some hosting arrangements patch PHP for you and some do not. Laravel Forge, a server-management service, noted that its own automatic security updates do not patch PHP, so customers had to apply the update themselves. The same pattern can exist on a cheap shared plan or on a site that has had no active maintainer for years.

How to find out. Ask the question above. If you do not know who looks after your site, that is the finding. Work out who is responsible and write it down.

A third bug, and why it is not an emergency

What. On Friday 23 October the PHP team published an advisory for a third flaw, CVE-2026-115560. Unlike the first two, it is not getting an emergency patch. It will be fixed in the next regular PHP release.

Why it matters to your business. Very little, for most sites. Exploiting it takes an unusual combination of settings and application code, which the PHP Foundation said it considers very unlikely in practice. It can be switched off with a single setting, session.upload_progress.enabled=0, until the regular fix arrives (The Register).

How to handle it. Do not change server settings yourself. If you are already messaging your host, add one line: "Is the interim setting for CVE-2026-115560 in place, or will the next PHP update cover it?" A competent host will know exactly what that means.

Four small jobs for this week

If customer information is ever exposed because software was left unpatched, there can be obligations to notify the people affected. Whether that applies to your business is a legal question, and one worth having a professional review. It is also the cheapest problem to avoid: the update gets applied on time and nothing happens.