PHP2Shell: the critical PHP update and what WordPress owners should check

On October 21, PHP released emergency updates for two critical vulnerabilities known as PHP2Shell. The official advisory says they can, under certain conditions, allow code to run on a server without an authenticated account. A website owner’s immediate task is to establish whether the host has applied the PHP fixes and obtain confirmation for the actual domain.

What happened, and why WordPress owners should care

The vulnerabilities are CVE-2026-109618 and CVE-2026-109619. The PHP Foundation describes faults involving out-of-memory handling and stale state between requests. They affect the runtime used by different web applications. Several teams investigated and validated the issues, including with AI assistance; people remained responsible for patches and release decisions. Describing this as “AI independently hacked the entire internet” would therefore misrepresent the event.

The WordPress team explicitly states that these are not WordPress-specific vulnerabilities and that no special WordPress update is planned for them. Having the latest CMS or a security plugin does not confirm that the server is patched. In the dashboard, the reported PHP version is under Tools → Site Health → Info → Server. Hosting control panels also commonly display it.

Which releases contain the fixes?

PHP identified the following fixed releases. Standard upstream builds need this release or a later one in the same branch; vendor packages containing backported fixes require the separate check explained below.

PHP branch	Release containing the fixes
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

There is an important qualification: a Linux distributor or hosting provider may backport the fixes into a package with an older PHP version number. For example, AlmaLinux published its own patched package list and warned that the short version reported by php -v is insufficient. Ask for the full package identifier and confirmation covering both CVEs. Equally, “you are on PHP 8.3” does not establish that the work is complete.

Our practical recommendation is not to change every website setting simply because a version differs from the table. Establish the package’s origin first. Conversely, a host’s general assurance about “secure servers” should be followed by a specific answer about these two fixes in the environment serving your site. Keep the support ticket number and confirmation time so the question does not become uncertain again tomorrow.

What to ask your hosting provider

A concise request could read: “Please check the PHP environment for my domain. Have fixes for CVE-2026-109618 and CVE-2026-109619 been installed? What is the full package version? Has it been applied to every process serving the site, and do I need to take any further action?” If the account hosts several sites, list them. Confirmation for the main domain does not necessarily describe every other environment.

For a self-managed VPS, the administrator performs this check. The NCSC recommends identifying PHP installations across the infrastructure, including components bundled in other products, and prioritising internet-facing systems. In practice, remember test subdomains, old shops and auxiliary panels too. Updating one service is not evidence that the others have received the fix. Inventory matters as much as the first successful update.

Prepare the site for an update

The WordPress guidance calls for a backup and checking theme and plugin compatibility before changing PHP. For this urgent fix, agree on the shortest safe route with your host: a patch within a supported branch or the necessary runtime upgrade. Preparation should not become a reason to postpone action for weeks. The backup needs both files and the database; the 3–2–1 rule explains the broader approach.

After the update, we suggest checking more than the homepage. Open the dashboard, several articles, search, the contact form and image uploads. For a shop, include the cart and a test checkout scenario. Record the time and exact message if something fails. Those observations give support more to work with than “everything broke after the update”, and help establish which functions still work normally.

Does a CDN or security plugin provide enough protection?

Request filtering can reduce exposure to particular attacks, but the official guidance does not treat temporary restrictions as a complete replacement for a patch. If a fix or suitable temporary measures cannot be applied promptly, the NCSC advises considering taking the system offline until the risk is addressed. Coordinate that decision with an administrator who understands the configuration, dependencies and consequences of downtime for the particular service.

Being vulnerable is not the same as being compromised

The announcement alone does not prove that your website has been compromised. If you find unfamiliar accounts, unexpected redirects or other unexplained changes, WordPress’s incident guidance recommends documenting the symptoms and when they appeared. Give that information to the host or an incident-response specialist. Applying a patch closes the vulnerability; it does not automatically confirm that the consequences of an earlier intrusion have been removed.