What PHP2Shell means for your site and what to check today
Last updated: 21 October 2026, 18:00 UTC · By Struc Răzvan, STNS Development
In short
PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 by the PHP project.
The flaw is in PHP itself, not in your plugins or theme.
Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026.
Exploitation is reported by some vendors (Cloudflare, watchTowr) and not confirmed by others (Huntress, NCSC-NL).
Today: find out which PHP version your site runs and ask your host when it will be updated.
What is PHP2Shell?
PHP2Shell is a pair of memory-handling bugs in the PHP engine that can let an attacker run code on a web server remotely, without logging in.
Because the problem sits in PHP itself, updating a plugin or theme does not fix it. Sansec and Wiz demonstrated unauthenticated attacks on current versions of WordPress, Drupal, Joomla, Magento, Laravel, Nextcloud and others; Wiz showed that even a minimal “Hello World” PHP page can be exploited.
Sansec adds that CVE-2026-109618 can leak passwords, tokens or API keys from server memory. The calmer side: NCSC-NL rates the attack as high complexity, and a complete fix is already available.
Is my website affected?
If your site runs on PHP and has not yet been moved to a fixed version, assume it is affected until your host or developer confirms otherwise.
According to php.net, every PHP installation serving web requests is affected, with the highest risk on Apache mod_php. We cannot tell whether a specific site is vulnerable without checking it, and we never scan websites without the owner’s permission.
Which PHP versions fix the vulnerability?
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and anything older on those branches still needs the PHP update.
PHP branch
Fixed version
Notes
8.5
8.5.12
Released 21 Oct 2026
8.4
8.4.27
Released 21 Oct 2026
8.3
8.3.36
Released 21 Oct 2026
8.2
8.2.35
Released 21 Oct 2026; end of life on 31 Dec 2026
8.1, 8.0, 7.4
No official release
Minimal backports for building from source; Linux distributions and LTS vendors received patches in advance
Older
No fix
Sansec and Wiz trace the vulnerable code back to PHP 5.4; upgrade to a supported branch
On 8.2, patch now and plan a newer branch before year end. If your host uses PHP packages from a Linux distribution or an LTS vendor, the version number may not match the table, so ask whether the package includes fixes for both CVEs.
How do I find out which PHP version my site uses?
The quickest way is your hosting control panel or, on WordPress, Tools → Site Health → Info → Server, which shows the PHP version.
Hosting panel: most panels show the PHP version per domain.
WordPress: Tools → Site Health → Info tab → Server.
Custom software: ask your developer.
Developers: command-line PHP can differ from the PHP serving the website, so check the web handler too.
The full number matters: “8.3” is not enough, you need 8.3.36 or newer. Include staging copies and forgotten tools such as an old phpMyAdmin.
What should I ask my hosting provider?
Ask whether your PHP is already on a fixed version and, if not, when it will be and what protects you until then.
You can paste these questions into a ticket:
Which PHP version and handler does my account use?
Is it on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or on a vendor package with the fixes for CVE-2026-109618 and CVE-2026-109619?
If not, when is the update scheduled, and which temporary measures are active until then?
Have you seen signs of compromise, and can you keep the logs from the last few days?
Never send passwords by email or web form; agree on a secure channel first.
Why isn’t a temporary mitigation a real fix?
Temporary mitigations make the bugs harder to trigger, but php.net states they do not make an installation safe, because only the update removes the flaw.
php.net lists configuration changes (see the technical box), and Cloudflare has published WAF rules. They are useful bridges, but they can break legitimate uploads, must be applied on every PHP worker and leave the bug in place. Use them to buy time. On PHP 8.1 or older, the realistic path for most businesses is an upgrade to a supported version.
What are the signs that a server may be compromised?
No confirmed indicators of compromise have been published yet, but a few patterns are worth reviewing with your host or developer. Huntress and Patchstack point to these high-level signals:
web server processes (PHP-FPM, Apache) starting command shells or download tools;
unusual upload requests followed by memory-limit errors or repeated HTTP 500 errors;
very large or malformed session cookies, unexplained worker restarts;
new files in the website folder, new scheduled tasks or new user accounts.
If you see any of these, keep the logs, treat the server as possibly compromised and rotate database passwords, API keys and other secrets. We will update this page when Huntress publishes its announced detection rules.
Is the UpdraftCentral WordPress incident part of PHP2Shell?
No, it is a separate incident from the same week, and it is not a code vulnerability.
Patchstack documented a campaign on 18–19 October in which an attacker with valid, probably leaked UpdraftCentral keys installed backdoor plugins on connected WordPress sites. If you use UpdraftCentral, have your developer remove the connection keys and look for unknown plugins such as “Site Health Cache”. Two different problems, one difficult week for WordPress.
Need help with the PHP update?
Yes: STNS Development can handle the PHP update for you and check for basic signs of compromise.
That covers the version inventory, the update or vendor package, temporary mitigations where needed and a written upgrade plan. It is not a full forensic investigation, and nobody can honestly promise a “100% secure” server; we bring you to a fixed version and reduce the risk. See how we work in our case studies or contact us.
Technical box
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): RCE via corruption on out-of-memory; cleanup treats partly initialised request data as valid. Also memory disclosure, even without session_start() (Sansec).
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): RCE via stale global state reused by a later request on the same worker.
Affected SAPIs: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. Known triggers: multipart/form-data requests.
Interim mitigations (php.net, not a fix): for 109618, non-overridable memory_limit=-1 (php_admin_value), post_max_size 8M (32M with uploads), proxy request limits, no RLIMIT_AS/RLIMIT_DATA; for 109619, session.upload_progress.enabled=0 with a restart of all workers, plus fatal_error_backtraces=0 on 8.5.
EOL backports: branches PHP-<ver>-CVE-2026-109618-109619, source builds only.
Frequently asked questions
Is PHP2Shell being exploited?
Exploitation is reported by some vendors (Cloudflare, watchTowr) and not confirmed by others (Huntress, NCSC-NL). At the time of writing, the CVEs are not in the CISA KEV catalogue. Either way, the safe step is to update PHP.
I updated WordPress and all plugins. Am I protected?
Not against PHP2Shell. The vulnerability is in PHP itself, so only a PHP update to a fixed version or a patched vendor package removes it.
My site runs PHP 8.1 or older. What should I do?
There is no official release for these versions, only minimal backports for building from source and patches provided in advance to Linux distributions and LTS vendors. Ask your host which applies and plan an upgrade to a supported version.
Does a web application firewall (WAF) protect my site?
A WAF can reduce the risk, and Cloudflare has published rules for these vulnerabilities. It is a temporary layer, not a fix.
Information as of 21 October 2026, 18:00 UTC, based on the sources cited. It does not replace an individual assessment.
