Your website can look perfectly normal while the software running it needs an urgent security update. Customers can still browse, enquiries can still arrive and the checkout can still work.

That is why the latest PHP security warning deserves attention—even if nothing appears wrong.

On 21 October 2026, PHP released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619, commonly discussed as PHP2Shell. Both carry a CVSS v4.0 severity score of 9.2 out of 10 and can allow remote code execution without authentication. PHP security advisory.

For business owners, the immediate task is straightforward: find out whether your website uses an affected PHP installation and confirm that the relevant fix is running.

What Are the New PHP Vulnerabilities?

PHP is software used behind the scenes to run websites and applications. These vulnerabilities affect the PHP runtime itself, rather than being limited to one website theme or plugin.

The two flaws involve problems with how PHP handles memory and internal information between requests.

CVE-2026-109618: Out-of-memory corruption

When PHP encounters certain out-of-memory conditions, it can leave internal request information incompletely initialised. During cleanup, that information may be treated as valid, creating an opportunity for remote code execution. PHP’s technical advisory.

CVE-2026-109619: Stale global state

The second vulnerability concerns internal information that can remain accessible after the memory behind it has been freed. A subsequent request handled by the same worker may use that outdated information, potentially leading to memory disclosure or code execution. PHP’s technical advisory.

You do not need to understand memory management to recognise the business risk. Under exploitable conditions, an outsider could make the server execute code it was never supposed to run.

Can Hackers Really Take Control of a Server?

The confirmed impact includes remote code execution with the permissions of the web worker account—the account running PHP requests. That is serious, but it does not automatically mean unrestricted administrator or root access to the entire machine. PHP’s confirmed impact assessment.

The distinction matters. The damage an attacker could cause depends partly on what that account can access and change. Depending on permissions, compromise could expose application files or secrets, allow website changes or provide a foothold for further activity.

PHP has validated exploitation, but reliability varies with the build, extensions and server environment. A vulnerable installation needs urgent attention; vulnerability alone is not proof that it has already been breached. PHP advisory.

Which Websites and Servers Are at Risk?

PHP’s security team identifies installations serving web requests as at risk, including:

  • PHP-FPM

  • Apache with mod_php

  • php-cgi

  • FrankenPHP

  • LiteSpeed

The team considers mod_php the highest-risk configuration, with a demonstrated attack that can trigger before application code runs. Other exploitation paths depend on the environment and application behaviour. Official PHP guidance.

NHS England reports demonstrated exploitation in products integrating PHP, including WordPress, Drupal and Joomla. That does not mean every installation of those platforms has been compromised. It means the underlying PHP installation must be checked. NHS England security alert.

Organisations should also look beyond their main website. ENISA warns that products can include PHP in the background even when their dependence on it is not obvious. ENISA joint statement.

Which PHP Versions Contain the Fixes?

The following upstream releases address these vulnerabilities:

PHP branchAffected releases within that branchFixed releasePHP 8.5Earlier than 8.5.128.5.12PHP 8.4Earlier than 8.4.278.4.27PHP 8.3Earlier than 8.3.368.3.36PHP 8.2Earlier than 8.2.358.2.35

Canadian Centre for Cyber Security’s affected-version table.

PHP 8.1 and older no longer receive normal upstream security releases. Some distributions and support vendors provide backported fixes, so owners of older installations should obtain explicit confirmation from their provider or move to a supported branch. Canadian security advisory.

A version number alone may not tell the whole story. Vendors can backport a fix without changing the displayed upstream version. Check the installed package against the vendor’s security notice. University of Toronto guidance.

What Website Owners Should Do Now

1. Ask your hosting provider for a specific answer

Instead of asking only whether your website is “secure,” ask:

Has the PHP runtime serving my website been patched against CVE-2026-109618 and CVE-2026-109619? Which fixed release or vendor package is running, and have the relevant services been restarted?

ENISA recommends identifying PHP applications, coordinating with providers and prioritising internet-facing systems. ENISA recommendations.

2. Update the runtime, not just the website dashboard

Updating WordPress, a theme or a plugin does not establish that the underlying PHP runtime has been patched. Confirm the runtime update separately.

After installation, administrators need to restart or replace the relevant PHP processes and verify that the running service has loaded the fix. Installing a patched package while old workers remain active is not enough. University of Toronto remediation guidance.

3. Reduce exposure if patching cannot happen immediately

Where an immediate fix is not feasible, security agencies recommend considering isolation of exposed applications from public networks until patching is complete. ENISA joint statement.

PHP lists temporary configuration measures, but explicitly warns that they do not make an affected installation safe. Have an administrator assess those measures rather than applying isolated settings without understanding their consequences. Updating is the complete remedy for these flaws. PHP advisory.

4. Check for signs of compromise

Canada’s Cyber Centre recommends reviewing logs and investigating unexpected processes, files, accounts or outbound connections associated with PHP and web-server services. Detection recommendations.

Patching closes the vulnerability; it does not remove anything an attacker may already have installed. If suspicious activity is found, involve the hosting provider or an incident-response professional. University of Toronto guidance.

Why This Matters to a Small Business

A server problem quickly becomes a customer problem when a website handles bookings, enquiries or orders.

You may never see the PHP configuration yourself. You still need to know who maintains it, whether the update has been applied and what happens if suspicious activity is discovered.

The most useful response is a documented one: confirm your exposure, apply the appropriate fix, verify it is running and investigate anything unusual.

A website that loads normally is reassuring. A provider who can explain exactly how it has been patched gives you something more dependable.

Information checked on 22 October 2026. Follow current PHP and hosting-vendor advisories as guidance develops.