If you have seen warnings about the latest PHP vulnerability and are wondering whether your website is affected, start with the software running on your hosting—not just whether your homepage still loads.

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities that can allow remote code execution without a login. A site can look completely normal while its server still needs an update. That does not mean your website has been breached, but it does make checking your patch status a priority. See the official PHP security announcement.

What is PHP, and why does this matter?

PHP is software that runs on a web server to process requests and generate pages. WordPress and many other website platforms use it. Updating your website’s text, theme or front-end design does not necessarily update that underlying runtime.

If an attacker can exploit a vulnerable request-handling path, they may be able to run code with the application’s permissions. Depending on the access available, that could expose application secrets or customer information, allow unauthorised changes, or disrupt the site. Those are possible consequences—not evidence that any particular website has been compromised.

There are two separate PHP issues

CVE-2026-109618: problems when PHP runs out of memory

PHP can leave request data in an invalid, partly initialised state when memory allocation fails. Later cleanup can use that invalid data. The advisory describes a demonstrated Apache mod_php attack path that runs before the application’s own code begins. That is why an application login is not a sufficient defence. Read the upstream advisory.

CVE-2026-109619: request state surviving after its memory is freed

A worker can retain internal state from an earlier request after the associated memory has been released. A later request can then use that stale state. The exact exposure depends on the server configuration and execution path. Read the upstream advisory.

Do not assume using PHP-FPM instead of mod_php removes the need to patch. Different server setups have different attack paths. The PHP Foundation’s release explanation gives more context.

Which PHP versions contain the fixes?

These are the minimum upstream releases containing the 21 October fixes for each listed branch. They are a reference for these advisories, not a promise that a whole website is secure. Use a newer compatible, supported release where available.

A hosting or operating-system vendor may backport fixes without changing the visible upstream version number. Ask for the full installed package revision and the vendor’s security confirmation. PHP 8.1 and older no longer receive normal upstream security releases, so older installations need vendor-specific evidence or an upgrade plan.

Does updating WordPress fix it?

Not on its own. These vulnerabilities are in PHP, rather than a WordPress core bug. You still need to keep WordPress, themes and plugins maintained, but the hosting runtime needs its own patch or verified vendor backport. Ask your hosting provider which PHP version actually serves your site, rather than relying only on the version selected in a control panel. WordPress’s official advice also explains where to find the PHP version in Site Health.

What can our free checker tell you?

It reads a public page and its response headers, identifies technology clues and compares any advertised PHP or Node.js version with the relevant security-release minimum. It does not send exploit payloads, sign in or change your website.

• An older advertised version: a reason to investigate promptly, not proof that an attack would succeed.
• A platform clue but no version: potentially affected, with hosting-level verification still needed. A framework or CMS fingerprint can also come from a static build.
• No identifiable PHP or Node.js: we cannot tell whether those systems are hidden behind a CDN, another origin or private services. It is not an all-clear.
• An advertised version meeting the fixes: encouraging, but not proof that every worker, dependency and service is patched.

What should you do next?

1. Establish what is running. Check the web-facing runtime, vendor package revision and any separate application workers with your hosting provider or developer.
2. Prepare before updating. Confirm backup and rollback arrangements and check compatibility with your website and integrations.
3. Apply supported updates. Patch the runtime and relevant dependencies to the latest compatible, supported versions available. A firewall or CDN is not a substitute for patching.
4. Verify the outcome. Check key website journeys and the version actually running after deployment, including restarted workers. A successful build log alone does not establish the live runtime’s patch level.

If you would rather have help, contact IT Boffins to book a fixed-price audit. We agree the scope and fixed price before work begins, verify applicable updates and leave a written outcome. No need to know your technology stack before getting in touch.

Reviewed 22 October 2026. This guide covers these specific PHP advisories; it is not a complete assessment of a website’s security.