PHP2Shell (CVE-2026-109618): Is My Website Affected?

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, the two critical flaws known as PHP2Shell. Both are rated CVSS v4.0 9.2. The project had announced the release a day earlier, without details, so that hosts could prepare. WordPress, WooCommerce, Joomla, Drupal and many custom-built sites run on PHP, so if you own one of them, this guide answers three questions: is mine affected, who installs the fix, and what should I do now?

Short answer: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, fix two critical flaws that "can allow unauthenticated remote code execution": someone on the internet, without logging in, could run their own code on the server behind your site (PHP, 2026). Every PHP that serves websites below those versions is at risk, whether it runs as PHP-FPM, LiteSpeed or Apache with mod_php, and that includes typical shared WordPress hosting. Security vendors report exploitation attempts since 17 October, though CISA had not observed exploitation when it published its alert on 21 October. On shared or managed hosting your host installs the fix: check that WordPress shows one of those versions or later under Tools → Site Health → Info → Server, and ask the host if it does not. On your own server, VPS or Docker image, update PHP from your distribution's packages or rebuild the image now, then restart every PHP worker. PHP 8.1 and older get no release from the PHP project, so ask your host what your site runs on. Updating closes the hole. It does not remove anything an attacker planted before the update, and it does not lift a browser or antivirus flag.

What was fixed, and who is at risk?

The PHP project's advisory is short: "PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately" (PHP, 2026). Both flaws are rated CVSS v4.0 9.2: they can be used over the network, with no login and without anyone on your side clicking anything. An attacker who can run code on your server can change your site, read its database and serve whatever they like to your visitors.

Who is at risk. In the PHP project's words: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." That covers every common way of running a website on PHP, including the setups shared WordPress hosts use. The project adds: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." In plain words: on mod_php, WordPress, your plugins and your security plugin never get a chance to see the request. In its own report, Wiz says it demonstrated code execution "on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest)" (Wiz, 2026).

CVE-2026-109618, "RCE via OOM corruption". A crafted upload-style request, in the multipart format browsers use to send files, makes PHP run out of memory while it is still setting up the request, and the cleanup that follows trusts data that was only half built. The advisory states: "Complete remote code execution was validated over HTTP against mod_php with default PHP input and memory limits". PHP-FPM is "susceptible" by source analysis, but "no complete FPM exploit has been demonstrated" (GitHub advisory, 2026).

CVE-2026-109619, "RCE via stale global state". Data left over from one request is reused by the next request handled by the same PHP worker. The advisory notes: "Session upload progress is enabled by default, and no application call to session_start() is required." Your site does not have to use sessions at all to be exposed. And: "Session lifecycle RCE was validated against mod_php and FPM" (GitHub advisory, 2026).

Each release announcement carries the same line: "There are no complete mitigations, updating is the only safe choice" (PHP news archive, 2026).

Which PHP versions are affected, and which are fixed?

Affected and fixed versions come from the two advisories; support status from the PHP project (PHP supported versions; PHP end of life):

Branch	Support status	Affected	Fixed in
8.5	Active support	below 8.5.12	8.5.12
8.4	Active support	below 8.4.27	8.4.27
8.3	Security fixes only	below 8.3.36	8.3.36
8.2	Security fixes only, until 31 December 2026	below 8.2.35	8.2.35
8.1	End of life since 31 December 2025	treat as affected (see below)	No release; source backport only, ask your host
8.0	End of life since 26 November 2023	treat as affected (see below)	No release; source backport only, ask your host
7.4	End of life since 28 November 2022	treat as affected (see below)	No release; source backport only, ask your host

The previous releases, 8.5.11, 8.4.26, 8.3.35 and 8.2.34 from 24 September 2026, are all affected. The advisories list affected ranges only for 8.2 to 8.5. For 7.4, 8.0 and 8.1 the PHP security team published minimal source backports "given the severity of these vulnerabilities". We read that as a reason to treat those versions as affected too; that is our reading, not a statement from php.net.

How do I find out which PHP version my website runs?

You do not need server access for this. Pick whichever of these you can reach first:

• WordPress: go to Tools → Site Health → Info, open the Server section, and read PHP version. This is the version that actually runs your site, with the full number, for example 8.3.36.
• Your hosting control panel. In cPanel, look for MultiPHP Manager or Select PHP Version, depending on how the host set it up. Panels often show only the branch, such as "PHP 8.3", not the exact build, so they tell you which branch you are on but not whether the fix is in.
• Ask the host. One line to support is enough: "Which PHP version does my site run, and have you applied the fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?"

Without WordPress admin or a panel, a developer can open a temporary phpinfo() page once and delete it straight away; left online, it shows your full server configuration to anyone.

I'm on shared or managed hosting. Do I have to do anything?

Usually not the patching itself. On shared hosting, managed WordPress hosting and most website builders, the host runs PHP for you, and installing the fixed build is their job. The PHP project notes that "Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages." On cPanel servers, EasyApache 4 25.91, released on 21 October, "fixes two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) in ea-php74 through ea-php85" (cPanel, 2026). So a cPanel host can install a fixed build even for PHP 7.4 to 8.1, and the question for your host is simply: have you applied it?

What is worth doing:

• Check Site Health. The PHP version WordPress reports should be 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release on the same branch.
• If it shows a lower number, ask the host whether the fixed build is installed for your site, and if not, when it will be.
• Do not switch branches in a hurry. Moving from 8.1 to 8.4 is a real upgrade that can break an old plugin or theme. On a supported branch, the fixed build of that branch is all you need.

One reason not to rely on the number alone: some hosts and Linux distributions apply security fixes to their own PHP builds without changing the version number the PHP project uses. Ubuntu is a concrete case. Its notice USN-8948-1 ships the fix as php8.3 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04 and php8.1 8.1.2-1ubuntu2.28 on Ubuntu 22.04 (Ubuntu, 2026). On such a server Site Health shows 8.3.6 although the fix is in. Only the host can confirm which build you run, so ask rather than assume either way.

What if my site runs PHP 8.1 or older?

These branches are past end of life (see the table), and the advisory is direct about it: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version." Because of the severity, the security team also published "minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor" (PHP, 2026). Those are patches for whoever compiles PHP, not a version your hosting panel can switch to. CISA goes further: "Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated" (CISA, 2026).

So ask your host directly: "My site runs PHP 8.1. Does your build include the fix for CVE-2026-109618 and CVE-2026-109619?" On cPanel the answer can be yes, through EasyApache 4 25.91. If the answer is no, or vague, move to a supported branch now. 8.2 is not a long-term home either: the 8.2.35 announcement says "PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date", so 8.3 or newer buys you more time. Test on a staging copy first if your host offers one, and update WordPress, the theme and the plugins before switching.

I run my own server, VPS or Docker container

Then the fix is yours to install:

• Update PHP from the same source you installed it from. Distributions received the patches in advance, so updated packages may already be waiting for your package manager. If your distribution keeps the old version number, as Ubuntu does, its security notice names the package release that contains the fix.
• If you use the Remi repository (rpms.remirepo.net): on 21 October the PHP project said this volunteer-maintained repository "will not have updates today", and urged its users "to switch to distribution packages or build from source, so you can immediately apply updates."
• Restart every PHP worker after updating. A running worker keeps the old code in memory: restart PHP-FPM for every version and pool, Apache if it uses mod_php, and any other PHP process manager.
• Check the version the web server uses. php -v reports the command-line PHP, which can be a different build from the one serving your site; Site Health shows the one that matters.
• Docker: the official php image has had 8.5.12, 8.4.27, 8.3.36 and 8.2.35 tags since 21 to 22 October. Rebuild from one of them, pulling the base again rather than using a cached layer, and redeploy every container that runs it.

If you cannot update straight away, there is no complete workaround. The CVE-2026-109619 advisory lists partial stopgaps for administrators: set session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0, then restart every PHP worker. These are partial, not a fix; both advisories say updating is the only complete one. For a public-facing site you cannot patch, CERT-EU's advice is to "consider isolating internet-facing applications from public networks until a fix is available" (CERT-EU, 2026): a maintenance page, access limited to known addresses, or a non-essential site taken offline until it is updated.

Was my site hacked before the update?

Updating PHP closes the door. It does not tell you whether anyone came in first, and it removes nothing an attacker left behind: a backdoor file, a new administrator account or injected code all survive a PHP update untouched.

What has been reported so far, as of 22 October 2026:

• Amazon Threat Intelligence "identified a PHP2Shell exploitation attempt dating to Oct. 17, 2026", four days before the fix, while noting "it's unclear if any of these attempts would have succeeded in real-world systems" (Amazon, 2026).
• VulnCheck saw scanning with the user agent php2shell-scan/109618, and "at least one attempted exploit from a China-based IP which tried to (unsuccessfully) drop a webshell via a server-side session file" (VulnCheck, 2026).
• Patchstack: "Shortly after PHP's update, our telemetry shows only probing attacks, with no hard evidence of breaches yet" (Patchstack, 2026).
• CERT-EU, in version 1.1 of its advisory: "Technical details are now being discussed publicly, and initial proofs of concept (PoCs) have begun to circulate. This raises the likelihood that attackers are already exploiting the vulnerabilities" (CERT-EU, 2026).
• CISA, on 21 October: "While CISA has not observed exploitation of these vulnerabilities as of the time of publication, they pose a risk to organizations if left unpatched" (CISA, 2026). Neither CVE was in CISA's Known Exploited Vulnerabilities catalog on 22 October.

Put together: security vendors report attempts and scanning since 17 October, but no official body had confirmed exploitation, and no confirmed compromised sites had been published as of 22 October. That does not clear your site. Amazon sets the window: "For PHP2Shell, investigate from at least starting on October 17th." Look from 17 October until the day the fix was installed.

In your access logs. On shared hosting, ask the host for the logs from 17 October onward, or download them from the panel if it offers them. Look for:

• POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS, which Amazon names. It is a form field, so it usually sits in the request body, which a standard access log does not record; a firewall log may show more.
• The user agent php2shell-scan/109618, the scanner VulnCheck observed.

A hit means your site was probed, not that it was compromised. It tells you to check the files and accounts below with more care.

On the server. Look for new PHP files you did not put there: in your site's folders, especially wp-content/uploads, and in the server's PHP session directory, where the attempt VulnCheck saw tried to drop a webshell. On shared hosting only the host can check the session directory, so ask them to. The UK's NCSC gives the same advice to anyone who could not patch at once: "If you are unable to update, or disable, the system immediately then you should assess the system for any evidence of compromise … and look for backdoors" (NCSC, 2026).

Other signs that something is wrong:

• Visitors arriving from Google are redirected elsewhere, or a site:yourdomain.com search shows spam pages you never wrote.
• Administrator accounts you did not create, or recently changed .htaccess, wp-config.php or theme files.
• A warning from your host, a Security Issues report in Google Search Console, or a browser or antivirus warning your visitors.

Our guide to the signs your website has been hacked covers these in more detail. If you find something, cleaning a hacked website covers the full sequence, and why WordPress malware keeps coming back explains the backdoors that survive a quick cleanup. If your site ran WordPress older than 7.1.2 in late September, also check whether it was hit through CVE-2026-87902, a separate WordPress flaw this PHP update does not touch.

My site is now blocked by antivirus or browsers

If a browser shows a red warning page, or an antivirus blocks your domain, a security vendor's crawler has recorded something your site served. Attackers who get code execution rarely deface a site; they add spam pages, selective redirects, a phishing page or a card skimmer on a store's checkout, which is exactly what those crawlers find.

Updating PHP does not lift the flag. The flag records what your domain served, and it stays until each vendor re-checks the site. Asking for a re-check before the site is clean does not help either: vendors re-scan when they review a request, and a site that still carries the payload keeps the flag. Clean first, then request reviews. Our guide on what to do when your website is flagged walks through it.

Start by finding out who is flagging you. Our free blocklist check looks the domain up across security vendors and shows which ones flag it, with no signup. It is a reputation check, not a malware scan: a clean result does not prove a clean server, and a flagged result tells you a vendor has already seen something.

Each flagging vendor then needs its own request; there is no central registry. For Google, request a review from the Security Issues report in Search Console. Google's help says a review "can take from a few days to a few weeks to complete" (Search Console Help), and the steps are in our guide to Google Safe Browsing removal. Every other vendor has its own false-positive form or security inbox and its own timeline; our guide on how long blacklist removal takes sets out what we know about each.

That administrative part is what unflagdomain.com does. After the free check shows who is flagging you, we email a removal request to each flagging vendor that takes email for a one-time €49: plain text, written separately for each vendor, with your own address as Reply-To so replies land in your inbox. Our catalog covers 135 active vendors; the ones that only take a form get the text ready to paste, and Google Safe Browsing stays a guided manual step through Search Console. We do not scan for or clean malware, so the cleanup is yours or your security provider's. And we cannot promise a delisting, because every vendor decides on its own. If the re-scan after payment finds zero flags, the payment is refunded automatically.

Updates

• 20 October 2026: advance notice published; fix scheduled for 21 October, 14:00 UTC.
• 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released; every web-serving PHP below those versions is affected; 8.1 and older get source backports only.
• 22 October 2026: not in CISA's Known Exploited Vulnerabilities catalog; security vendors report exploitation attempts since 17 October; no confirmed compromised sites published yet.

// FAQ

• [01]My site is on shared hosting. Am I affected by PHP2Shell?+

  Very likely, unless your host has already installed the fix. PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, and the PHP project says every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php and LiteSpeed, which covers typical shared hosting. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On shared or managed hosting the host installs them, not you: check the PHP version under Tools → Site Health → Info → Server in WordPress, and ask the host if it is lower.

• [02]My site runs PHP 7.4 or 8.1. What now?+

  The PHP project no longer publishes releases for those branches: 7.4 reached end of life on 28 November 2022 and 8.1 on 31 December 2025. Given the severity, its security team published minimal source backports for 7.4, 8.0 and 8.1, which we read as a reason to treat those versions as affected. Some hosts and Linux distributions ship backported fixes; cPanel's EasyApache 4 25.91, for example, covers ea-php74 through ea-php85. Ask your host whether their build includes the fix. CISA advises taking PHP 8.1 or older systems offline until they can be patched or updated. If it does not, move to a supported branch, 8.3 or newer, and test it on a staging copy first.

• [03]Does updating PHP clean a site that was already hacked?+

  No. Updating PHP closes the hole for the future. Backdoor files, administrator accounts an attacker created, injected code in the theme or .htaccess, and spam pages all survive a PHP update untouched. If you see signs of a compromise, clean the site as a whole and change every password, then check whether security vendors flagged it in the meantime.

• [04]Does a WordPress update fix this?+

  No. PHP is the language WordPress runs on, and it is installed separately from WordPress, by your host or on your own server. Updating WordPress, plugins or the theme does not change the PHP version. The fix arrives as a new PHP build, 8.5.12, 8.4.27, 8.3.36 or 8.2.35 depending on your branch, which your host installs or you install from your operating system's packages.

• [05]My site got flagged by a browser or antivirus after this. Will updating PHP clear the flag?+

  No. Blocklist flags record what your domain served, and they stay until each vendor re-checks. Remove whatever the attacker left, confirm the site is clean, then request a review from every flagging vendor. Google Safe Browsing requires a manual review request in Search Console; other vendors each have their own false-positive process.