PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what to do if your marketing site runs on WordPress

What PHP2Shell is

PHP2Shell is the name Wiz Research gave to two memory-safety flaws in the PHP engine, tracked as CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a web server without logging in. The flaws are in PHP itself, not in WordPress or any plugin, so they reach every site whose server runs an affected PHP build.

The PHP project released fixes on October 21, 2026 and rated both flaws critical in its security advisory. Its two GitHub advisories describe them:

• CVE-2026-109618, RCE via OOM corruption. An out-of-memory error can stop PHP while a request's internal data is only half set up, and request cleanup then treats that data as valid (GHSA-w8hw-w9fx-j79w).
• CVE-2026-109619, RCE via stale global state. State owned by one request can outlive the memory behind it, and the next request handled by the same worker can use it before PHP resets it (GHSA-6wmf-4rv5-p3rp).

The PHP project scores both 9.2 out of 10 on CVSS version 4.0. NIST's National Vulnerability Database adds its own CVSS 3.1 scores: 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619.

Wiz Research, one of the reporters, says in its PHP2Shell write-up that it ran code without logging in on the latest WordPress, Drupal and Joomla container images. Wiz also says it could read PHP worker memory, which can hold passwords, tokens and API keys, without running any code. By Wiz's count, every PHP release of the past decade carries at least one of the bugs, back to PHP 5.4.

A third flaw followed on October 23. PHP's informational advisory says CVE-2026-115560 needs an unusual combination of settings and application code, will be fixed in the next regular release, and is blocked in the meantime by setting session.upload_progress.enabled=0.

Which PHP versions are affected and which fix it

Every supported PHP branch before its October 21, 2026 release is affected, and the fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, according to PHP's advisory. PHP 8.1 and older get no release from the PHP project. Because of the severity, PHP published minimal source patches for 7.4, 8.0 and 8.1, meant for people who build PHP from source or have no long-term support vendor.

The support dates come from PHP's supported versions page, and the 8.2.35 release note adds that 8.2 gets no security fixes after December 31, 2026. The site shares come from WordPress.org's PHP version statistics, read through its data feed on October 25, 2026. They show the branch a site runs, not its patch level. Read together, about 66% of WordPress sites sit on a branch with an official fix, and about 34% sit on PHP 8.1 or older, where only a vendor's backport or an upgrade helps.

A version number that looks old does not prove a server is exposed. PHP says Linux distributions and long-term support vendors received the patches in advance. Ubuntu, for example, shipped the fix on October 21 as package 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS and 8.1.2-1ubuntu2.28 for Ubuntu 22.04 LTS (USN-8948-1). A server on either build reports a PHP version starting 8.3.6 or 8.1.2 while carrying the fix, so only the host can say for sure.

Is my WordPress or WooCommerce site affected?

A WordPress or WooCommerce site is affected when its server runs a PHP build without the October 21 fixes, whatever WordPress version, theme or plugins it uses. Those all run on top of PHP, and the bugs sit in the engine underneath them, so updating WordPress, a theme or a plugin does not change the answer. PHP's advisory names every PHP installation that serves web requests as at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

A site whose server does not run PHP, such as a static site, is outside these two flaws. On managed WordPress hosting, PHP is the host's to update, and the next two sections show how to confirm it has. WordPress itself recommends PHP 8.3 or newer on its requirements page, and warns that the older versions it still runs on are past their end of life.

How to check your PHP version without a developer

WordPress shows the PHP version and the server type on its Site Health screen, which any administrator can open. The steps, from WordPress's Site Health documentation:

1. In the WordPress dashboard, open Tools, then Site Health, then the Info tab.
2. Expand the Server section.
3. Read the PHP version line. It shows PHP's own version string, followed by whether the build supports 64-bit values.
4. Read the PHP SAPI line, which names how the web server runs PHP.
5. Use the screen's copy feature to put the details on the clipboard for your host.

Both lines come straight from PHP: WordPress core fills them from PHP_VERSION and PHP_SAPI in its Site Health code. The SAPI value maps to the server types PHP's advisories discuss:

The value names are from the PHP manual's php_sapi_name reference, and the risk notes from the advisory and GHSA-w8hw-w9fx-j79w. Without WordPress access, some servers announce the version in an X-Powered-By response header, which PHP sends when its expose_php setting is on. A missing header proves nothing, because the setting can be off.

What to ask your host

The host is the party that can update PHP, so the job is to get a specific, dated answer from it. These questions can be pasted into a support ticket as they are:

1. Which PHP version and build does my site run, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619 (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or your vendor's patched package)?
2. When was the fix applied, and were the PHP workers restarted so the fixed build is the one serving my site?
3. Have you set session.upload_progress.enabled=0, as PHP suggests for CVE-2026-115560 until its next regular release?
4. If my site runs PHP 8.1 or older, is a backported fix in place, or can you move the site to PHP 8.3 or newer?
5. Do your logs show attempts against my site, and will you tell me if you find signs of compromise?

A site on PHP 8.2 has a second deadline. PHP's 8.2.35 release note says the branch reaches end of life on December 31, 2026, so the move to 8.3 or newer is worth planning in the same ticket.

Is PHP2Shell being exploited?

PHP2Shell had no confirmed exploitation in the main government trackers on October 25, 2026, but the details needed to attack it are public. The record on that date:

• Neither CVE is in CISA's Known Exploited Vulnerabilities catalog, version 2026.10.23, released October 23.
• CISA's SSVC assessment, dated October 21, records exploitation as none on the NVD records for CVE-2026-109618 and CVE-2026-109619.
• CERT-EU's advisory 2026-018, last updated October 23, says technical details are being discussed in public and initial proofs of concept have begun to circulate, which raises the likelihood that attackers already exploit the flaws.
• Wiz says frontier AI models let its researchers develop and adapt working exploits across several applications in hours (Wiz Research).

Claims of attacks in the wild could not be confirmed in a government or PHP project source on October 25, 2026, and that can change within days. CERT-EU's advice does not wait for it: patch now, and isolate an internet-facing application that cannot be patched yet.

PHP2Shell is not wp2shell

PHP2Shell and wp2shell are separate problems with separate fixes. wp2shell is the nickname of a pair of WordPress core flaws that WordPress fixed in July 2026, as a Wiz Research post describes; PHP2Shell is in the PHP engine and was fixed in October.

The WordPress side comes from the WordPress 7.0.2 release post, which says WordPress.org enabled forced updates for sites on affected versions. A site that took that update is still exposed to PHP2Shell if its PHP build is not fixed, and the reverse is also true.

What to check after the patch

A PHP update stops new break-ins through these flaws, but it does not undo one that already happened. A marketing team should check the places where a compromised site costs search traffic and ad spend:

1. Search Console's Security issues report. It lists hacked content, malware and social engineering that Google found on the site (Search Console Help).
2. Google Ads disapprovals. In Ads, filter for Policy details: Compromised site. Google's Compromised sites policy disapproves ads whose destinations inject scripts, steal card details, launch pop-ups or redirect visitors, and covers sites on a content management system with a known vulnerability that has been exploited. The final URL can be checked in Google's Safe Browsing site status tool.
3. Redirects, as a searcher sees them. Google's spam policies on hacked content say a hacked redirect can depend on the referrer, user agent or device. Open the site from a Google result on a phone, not only by typing the address on a laptop.
4. New pages and hidden text. The same policy lists page injection (new spam pages) and content injection (hidden links or text on existing pages) as common results of a hack.
5. Scripts, pixels and the tag manager. Look for tags nobody on the team added, in the theme, the plugins and the tag manager container. Scripts that send visitor data without consent are one of Google's compromised-site examples.
6. Administrator accounts. Check the WordPress Users screen for administrators nobody recognises.
7. Keys the site holds. Wiz showed PHP worker memory can leak passwords, tokens and API keys. If the site ran an unpatched build, rotate the secrets its plugins store: payment gateway keys, email service keys, ad platform conversion API tokens and admin passwords.

Where overads fits

overads is an AI marketing agent for small teams, and it has no part in fixing PHP2Shell: it does not host websites, run or update PHP, or scan pages for malware. overads' own web app and API are written in TypeScript for Node.js, and its code repositories contain no PHP files (checked October 25, 2026), so there is nothing in overads' code for these CVEs to patch.

Two parts of an incident like this touch overads:

• overads reads Meta, Google, X and Snapchat ad accounts read-only. So pausing ads that send people to a compromised page is done in Google Ads or Meta Ads Manager, not in overads.
• overads Publish can post a short status update to Instagram, Facebook, LinkedIn, X, Bluesky, Mastodon and Pinterest if the site has to go offline while it is cleaned, through one post with per-channel copy that can wait for a person's approval first (scheduling and approvals).

For the fix itself, the host comes first, and a security specialist is the right call for a site that may already be compromised, as Google's compromised-sites policy also suggests. Agencies that run client sites can send the host questions above once per client; what overads does for client work is on overads for agencies, and for store owners on overads for DTC operators.