# Critical PHP vulnerabilities: what WordPress website owners need to do

- Link: https://codexcollective.co.uk/blog/critical-php-vulnerabilities-wordpress-october-2026/
- Published: 2026-10-25T01:15:45+00:00
- Author: Codex Collective

**Two critical PHP vulnerabilities prompted an urgent security release on 21 October
2026. If your business runs WordPress, the action to take is to confirm that your
hosting environment has been patched, then check that the website still works correctly.**

The issues, CVE-2026-109618 and CVE-2026-109619, can allow unauthenticated remote
code execution. In plain English, an attacker may be able to run code on an affected
server without logging in. Both received a CVSS v4.0 severity score of 9.2. The 
[PHP project’s first advisory](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
and [second advisory](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
explain the technical findings.

_Information checked on 25 October 2026. The patch versions below address the two
21 October vulnerabilities; the separate 23 October advisory is explained further
down._

## What happened, and does it mean your website was hacked?

These are flaws in PHP itself, the server-side runtime used by WordPress and many
other applications. One concerns memory handling when PHP runs out of memory. The
other involves internal state from one request being accessed after its memory has
been released.

A vulnerability is a weakness that could be exploited. A compromise means someone
successfully used a weakness to gain access or cause harm. Running an affected PHP
version does not, by itself, prove that a website has been hacked. Equally, a website
that looks normal is not evidence that it is secure.

The response should be based on evidence: establish the installed version, apply
the relevant updates and investigate suspicious activity where there is reason to
suspect a compromise. Avoid treating headlines about a “PHP hack” as a diagnosis
of your own website.

## Which PHP versions fix the two critical vulnerabilities?

The PHP project released these security updates on 21 October:

| PHP branch | Security release | 
| 8.2 | 8.2.35 | 
| 8.3 | 8.3.36 | 
| 8.4 | 8.4.27 | 
| 8.5 | 8.5.12 |

These are the releases containing the fixes, not a recommendation to install an 
older build if a newer supported security release is available. Hosting vendors 
may also backport fixes into their packages. Where that applies, ask for confirmation
that the installed package addresses both CVEs rather than judging its status from
the version number alone.

PHP 8.1 and earlier no longer receive updates from the PHP project. Some vendors
provide extended support or backported fixes, but that needs explicit confirmation.
Plan a move to a supported branch rather than assuming an old installation is covered.
See the [official PHP announcements](https://www.php.net/archive/2026.php).

## Why updating WordPress or installing a security plugin is not enough

WordPress, its theme and its plugins sit above the PHP runtime. Updating them remains
important, but it does not update the PHP installation used by the server.

[WordPress’s security notice](https://wordpress.org/news/2026/10/critical-php-security-release/)
confirms that these vulnerabilities are not specific to WordPress and that no WordPress
update is required or planned to resolve them. It directs site owners to check their
hosting provider’s response and update PHP.

A web application firewall may help reduce exposure to particular attack attempts.
It does not replace the runtime patch. A security plugin also cannot be relied upon
to protect against every server-level vulnerability.

## A practical checklist for WordPress website owners

 1. **Check the PHP version used by the website.** In WordPress, open Tools → Site 
    Health → Info → Server. Ask your host to confirm the exact package and patch status.
    Check each website or subdomain separately.
 2. **Confirm who owns the update.** Managed hosting, shared hosting and a self-managed
    server have different responsibilities. Get written confirmation of what was patched
    and when.
 3. **Prepare a recoverable backup.** Include the database and files. If a PHP upgrade
    may expose compatibility problems, agree a recovery plan that does not leave the
    site running an unpatched runtime.
 4. **Apply the appropriate update promptly.** Your host or server administrator should
    confirm that the website is actually using the updated runtime, including any necessary
    service restarts.
 5. **Test the journeys that matter.** Check forms, logins, search, scheduled tasks
    and integrations. For an online shop, check basket, checkout and payment behaviour
    using an appropriate test method.
 6. **Review the result.** Confirm the live PHP version again, check error logs and
    record any compatibility fixes. A successful installation is only part of a successful
    update.

## The 23 October follow-up: session upload progress

PHP published a separate informational advisory on 23 October about CVE-2026-115560.
It describes a further remote-code-execution risk involving an unusual combination
of session configuration and application behaviour.

PHP recommends setting `session.upload_progress.enabled=0` until the next regular
bugfix release. Its notice explains the specific conditions involved and says applications
that never change the session serialisation handler at runtime can keep the feature
enabled. Ask your server administrator to assess and apply the current guidance;
this setting concerns session upload progress, not a blanket switch to disable ordinary
file uploads.

The important distinction is that the four releases listed above fix the two original
vulnerabilities. Do not treat that list as a claim that every subsequently disclosed
PHP issue is resolved. Refer to the [23 October PHP notice](https://www.php.net/archive/2026.php)
and [updated CERT-EU advisory](https://cert.europa.eu/publications/security-advisories/2026-018/).

## What if your host cannot patch immediately?

CERT-EU advises organisations to consider isolating affected internet-facing applications
until a fix has been applied and verified. The PHP project states that configuration
changes for the original two vulnerabilities only reduce particular attack paths;
they do not provide a complete substitute for updating.

Ask the person responsible for hosting to explain the remaining exposure and the
plan to resolve it. If there are signs of a compromise, patching alone should not
be treated as proof of recovery. Investigation and remediation need to address what
an attacker may already have changed.

## Make PHP maintenance part of owning the website

The operational lesson is straightforward: someone needs to own the hosting inventory,
security updates, compatibility testing and recovery process. That responsibility
should be clear before an urgent advisory arrives.

If you need help assessing an existing platform or resolving compatibility problems
after an upgrade, explore our [Enterprise WordPress service](https://codexcollective.co.uk/enterprise-wordpress/)
or [discuss your website with us](https://codexcollective.co.uk/contact/). Start
with the software and hosting you actually run, then agree the work needed to keep
it maintainable.