PHP2Shell CVE-2026-109618: Check and Patch PHP Now | Temporary Workaround

Quick answer: Two critical flaws in core PHP, CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2), can let an unauthenticated attacker run code on a server or read its memory. Every PHP release from 5.4 through 8.5.11 is affected. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 or later. PHP 8.1 and older no longer receive fixes from the PHP project.

Key facts at a glance

What is PHP2Shell?

PHP2Shell is the name Wiz Research gave to a family of memory-safety flaws in PHP’s core engine. Both CVEs stem from how PHP handles fatal errors, especially out-of-memory errors:

• CVE-2026-109618: If PHP runs out of memory while initializing a request, it can be interrupted with request data only partly set up. Cleanup then treats that invalid data as valid.
• CVE-2026-109619: Request-owned internal state can survive after its memory has been freed. The next request handled by the same worker process can then use that stale state.

Wiz identified four underlying bugs, grouped under these two CVEs. It also says other variants likely exist, and the PHP patch fixes the root cause rather than each variant.

The flaws live in PHP itself, so a site can be vulnerable even if its WordPress theme, plugins, or application code is secure. Wiz says a simple “Hello World” PHP app on an affected version can be exposed.

Who is affected?

PHP runtimes that serve web requests. The PHP advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP project considers mod_php the highest risk, because its exploit can run before any application code.

Common platforms. Wiz demonstrated working exploits against the latest WordPress, Drupal, and Joomla container images. Wiz and php2shell.com also list MediaWiki, Moodle, Nextcloud, Laravel, and Symfony as widely used PHP software. Any PHP application on an affected version is at risk.

Shared hosting, VPS, and dedicated servers. All of these are in scope, as are cloud platforms, where the patch depends on how you deploy. Google Cloud says App Engine Standard is patched automatically, while App Engine Flexible, Cloud Run services built without automatic base-image updates, and GKE containers must be rebuilt or redeployed. Google Cloud is not itself vulnerable, but customers running PHP on it may be.

Hosts may lag. At the time of writing, at least one major hosting provider, Hostinger, had not yet updated its PHP versions. The author confirmed this directly. Other hosts may be in the same position, so do not assume yours has patched.

CLI-only scripts (such as cron jobs that never serve web requests) are less exposed, since the advisory describes risk for web-serving installations. Upgrade the CLI binary anyway, so everything runs the same version.

How to check if you are affected

1. Check the CLI version:

php -r 'echo PHP_VERSION, PHP_EOL;'

2. Compare it with the fixed release for your branch:

3. Check the version your website actually uses. The CLI and web server can run different PHP versions.

• WordPress: Tools → Site Health → Info → Server
• cPanel: MultiPHP Manager
• Plesk: PHP Settings
• VPS: ps aux | grep -E "php-fpm|apache2|httpd" shows which PHP processes are running.

4. Look for signs of exploitation. These bugs run below the application layer, so application logs may show very little. Investigate if you see:

• Unusual multipart (file upload) requests followed by memory-limit errors
• Repeated HTTP 500 responses
• Unusually large or malformed PHPSESSID cookies in responses
• Unexplained PHP worker restarts or churn

If you find these, assume compromise. Rotate every secret the site uses (database passwords, API keys, admin credentials, tokens), and get a security review before you trust the server again.

Timeline

• 19 August 2026: Wiz discovers the first bug.
• 24 August 2026: Wiz reports the issues to the PHP security team.
• 21 September 2026: PHP acknowledges the reports and begins work on a coordinated fix.
• 20 October 2026: PHP announces an upcoming critical security release.
• 21 October 2026: Patches are released and the flaws are disclosed publicly.

How to upgrade PHP on a VPS or dedicated server

You can upgrade without breaking the site if you back up first and test before switching.

Step 1: Back up

tar -czf /root/site-backup-$(date +%F).tar.gz /var/www/
mysqldump -u root -p --all-databases > /root/db-backup-$(date +%F).sql

Take a provider snapshot if you can.

Step 2: Record your current setup

php -m > /root/php-modules-before.txt
php -i > /root/php-info-before.txt

Note which web server and PHP handler you use (PHP-FPM, mod_php, or CGI) before you change anything.

Step 3: Install the patched version alongside the old one

Ubuntu (use the Ondřej Surý PPA):

sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.3 php8.3-fpm php8.3-cli php8.3-mysql php8.3-curl \
  php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-opcache

Replace 8.3 with your branch. Install any extra extensions you recorded in Step 2.

Debian: Use the Sury repository from the same maintainer (packages.sury.org), and follow its instructions.

RHEL, Rocky, or AlmaLinux: Use your distribution’s PHP packages or the official source. Do not rely on the Remi repo for this patch, since the PHP advisory says it will not have updates on the release date.

Check that your package source has the patched version before you switch. Your distribution’s packages may lag the upstream release, and the PHP project says LTS vendors received patches in advance.

Step 4: Test on staging

Clone the site to a staging server, point it at the new PHP, and test the front end, admin login, forms, file uploads, and cron jobs.

Step 5: Switch the live site

Nginx with PHP-FPM:

sudo nano /etc/nginx/sites-enabled/yoursite.conf
# change the fastcgi_pass line to e.g. unix:/run/php/php8.3-fpm.sock
sudo nginx -t && sudo systemctl reload nginx

Apache with mod_php:

sudo a2dismod php8.2
sudo a2enmod php8.3
sudo systemctl restart apache2

Change php8.2 and php8.3 to your old and new versions.

Restart, do not just reload. PHP’s OPcache and workers keep old code in memory. Restart PHP-FPM so the new version and any old workers are fully replaced:

sudo systemctl restart php8.3-fpm

Point the CLI at the new version:

sudo update-alternatives --set php /usr/bin/php8.3

Step 6: Verify

php -r 'echo PHP_VERSION, PHP_EOL;'
curl -sI https://yoursite.com | head -n 5

Confirm the web-facing version in WordPress Site Health. The version should be 8.5.12, 8.4.27, 8.3.36, 8.2.35, or later.

Step 7: Check memory and request-size settings

The PHP advisory says the fix introduces a new hard memory limit. Reaching it ends the process and skips shutdown handlers. After patching:

• Review memory_limit against real application memory use.
• Keep post_max_size in line with your memory budget while still allowing legitimate uploads.
• Limit max_input_nesting_level to what your application needs, and test complex forms.
• Revisit any temporary memory_limit = -1 you set during the interim.

Step 8: Clean up

After a few days of stable running, remove the old PHP packages. Keep backups longer.

Shared hosting or no server access: what to do

You cannot install PHP yourself, so the patch is up to your host.

1. Contact your host today, and ask:

• Is my account’s PHP version patched for CVE-2026-109618 and CVE-2026-109619?
• When will the patched version be rolled out to my account?
• Can I select the patched version in my control panel now?
• Do you have a WAF or mitigation in place in the meantime?

2. Switch to a patched version if one is available. Use MultiPHP Manager in cPanel or PHP Settings in Plesk, then test.

3. Put a WAF or CDN in front of the site. Cloudflare, Akamai, Fastly, Imperva, Google Cloud, and others published mitigations for these bugs. A WAF is a stopgap, not a fix. The PHP project says only an update is a complete solution.

4. If your host cannot give a timeline, consider moving. Waiting on a host that has not patched leaves the site exposed.

Interim mitigations (if you cannot patch yet)

These come from the PHP advisory. They reduce exposure to some attack paths but do not make a system safe. Patch as soon as you can.

For CVE-2026-109619 (stale state):

• Set session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool configuration, then restart every worker. Do not rely on ini_set() or .user.ini, because these apply too late.
• On PHP 8.5 only, set fatal_error_backtraces = 0, then restart workers. This blocks only the confirmed path.

For CVE-2026-109618 (out-of-memory corruption):

• Set post_max_size = 8M if the site does not accept file uploads, or post_max_size = 32M if it does. Keep upload_max_filesize below post_max_size.
• Consider setting request-size limits at the web server or proxy, covering request body size, multipart part count, header count, and nesting depth. These limits must also apply to requests without a Content-Length header.
• You can set memory_limit = -1, but only with an operating-system memory cap (such as a cgroup v2 memory.max) to contain the impact. Set it in a way the application cannot override, such as php_admin_value in the PHP-FPM pool. Revisit this after patching.
• Do not use RLIMIT_AS or RLIMIT_DATA as memory limits. The advisory says they can trigger the same vulnerable failure.

Also:

• Turn off features you don’t use that accept multipart uploads.
• Enable a WAF or CDN protection layer.
• Change passwords and API keys on any site that might have been exposed.

Common mistakes to avoid

• Updating only the CLI. The web server (PHP-FPM or mod_php) also needs the new version.
• Reloading instead of restarting. Old workers and OPcache can keep the vulnerable code running.
• Assuming your WordPress or CMS update fixes it. The flaw is in PHP, so only a PHP update fixes it.
• Relying on hidden errors. Turning off display errors does not protect you.
• Using RLIMIT as a memory cap. The advisory warns this can trigger the vulnerable path.
• Trusting a third-party repo that has not updated. Check that your source has the fixed version before you switch.

Frequently asked questions

Does this affect me if I only use PHP for WordPress?
Yes. WordPress runs on PHP, so any site on an affected PHP version is exposed, even if WordPress itself is fully updated.

Is my site safe if WordPress is up to date?
Not necessarily. These flaws sit in PHP beneath WordPress. Keeping WordPress current is good practice, but it does not fix PHP.

Do I need an account to be attacked?
No. Wiz describes the attacks as unauthenticated, meaning they work without logging in.

What data could be stolen?
Memory disclosure can expose passwords, authentication tokens, API keys, and certificates belonging to other requests or the server. Rotate secrets if you suspect exposure.

Can a WAF or CDN protect me?
It can reduce risk, but the PHP project says only the patched release fully remediates the issue.

What if I’m on PHP 8.1 or older?
The PHP project will not patch these branches. Upgrade to 8.2.35 or later, or to a supported branch. Some distributions and LTS vendors may backport fixes, so check with your vendor. PHP 8.2 reaches end of life on 31 December 2026.

Is there a source build option?
Yes. The PHP project published minimal backports for PHP 7.4, 8.0, and 8.1 on GitHub, for people building from source without an LTS vendor. The advisory links these in its security notice.

Sources

• PHP security advisory and release notes, 21 October 2026: https://www.php.net/archive/2026.php
• PHP2Shell overview and upgrade guidance: https://www.php2shell.com
• Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”: https://www.wiz.io/blog/php2shell-php-rce
• Google Cloud, “Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619”: https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619