PHP2Shell (CVE-2026-109618 & CVE-2026-109619): What UK Businesses Need to Do Now

By Andy Pickett · Chief Technology Director and AI Champion

Published 22 October 2026 · About the author

What is PHP2Shell?

PHP is the programming language behind a large share of the web. WordPress is written in it, and so are WooCommerce, Drupal, Joomla, Magento, many customer portals and booking systems, and countless bespoke business websites. Cloudflare, citing W3Techs, says PHP is used by almost 70% of websites.

PHP2Shell is the name researchers gave to two related flaws in PHP’s engine, made public on 21 October 2026. Both can lead to PHP remote code execution, where an attacker runs their own code on your server:

• CVE-2026-109618, “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w). When PHP runs out of memory part-way through setting up a web request, its clean-up can treat half-built data as if it were valid.
• CVE-2026-109619, “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp). Data belonging to one request can survive after its memory has been freed, and the next request handled by the same PHP process can then use it.

In plain English: an attacker sends a carefully prepared request to any PHP page on your site. PHP trips over itself while handling it, and the attacker turns that stumble into their own commands running on your server, with the same access as your website. A related bug lets an attacker read pieces of the server’s memory without running any code. Wiz, one of the research teams, says that memory can hold passwords, authentication tokens, API keys and certificates belonging to other visitors or to the server itself.

Why your website’s own security doesn’t help

The flaw is in PHP, underneath your website. According to PHP’s security advisory, the most exposed set-ups can be attacked “before any application code runs”. That means your login page, two-factor authentication, security plugins and maintenance mode never get a chance to step in, and a carefully maintained website is exposed in the same way as a neglected one. Wiz says even a simple “Hello World” page on an affected PHP version can be vulnerable.

How serious is this PHP vulnerability, honestly?

PHP rates both CVEs Critical, with a CVSS v4.0 score of 9.2. The score says the attack works over the internet, needs no login and no action by a user, and could let an attacker read, change or disrupt what’s on the server. It also marks the attack as high complexity: the attacker has to get the timing and memory layout right, so not every attempt will work and not every PHP site will be broken into.

What has changed is how quickly that complexity can be overcome. Wiz says AI models helped it build and adapt working exploits for several applications “in hours”, and Amazon’s threat intelligence team says AI-assisted analysis makes it cheaper to turn an advisory into a working exploit. Treat PHP2Shell as urgent, but don’t panic: the update closes the hole. It won’t undo a break-in that has already happened, though, which is why checking for compromise matters too.

Is PHP2Shell being exploited?

Yes. As of 22 October 2026:

• Amazon recorded a first exploit attempt against its MadPot honeypots on 17 October, four days before the fix was released, followed by several different exploits from multiple attackers on 21 October. It says PHP2Shell “is now being broadly exploited in the wild”.
• watchTowr reports exploitation of both CVEs in its honeypot network.
• Cloudflare has seen attack traffic aimed at its customers, with attackers changing their requests to try to get past its firewall rules.
• Government agencies: the UK’s National Cyber Security Centre (NCSC) and the US CISA have urged organisations to patch immediately, and the FBI and NSA have issued warnings of their own, The Hacker News reports.
• Not yet on CISA’s KEV list: at 09:15 UTC on 22 October, neither CVE was in CISA’s Known Exploited Vulnerabilities catalogue. CISA’s own alert said it hadn’t yet seen exploitation itself, so a listing may follow. Don’t wait for it.

Is your business affected?

If your business has a website, online shop, customer portal, booking system or intranet, there’s a good chance PHP is involved somewhere. Work through these questions.

Quick checklist: am I affected by PHP2Shell?

1. Does any of your web software run on PHP? WordPress and WooCommerce always do. So do Drupal, Joomla, Magento, MediaWiki, and frameworks such as Laravel. If you’re not sure, ask whoever built or hosts the site.
2. Who looks after the server? On shared or managed WordPress hosting, the host updates PHP, but you should still confirm it has been done. If you rent your own server in the cloud, updating PHP is your job or your IT provider’s.
3. Which PHP version is it? Anything before 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is affected, unless your Linux distribution has added the fix to its own package. The technical section below explains how to tell.
4. How does PHP run? PHP rates Apache with mod_php as the riskiest set-up. PHP-FPM, which is common with nginx, is still at risk. Command-line scripts and scheduled (cron) jobs can’t be reached from the web.
5. Is it PHP 8.1 or older? PHP no longer releases fixes for these versions. See step 5 of the plan below.

WordPress sites: what updating does and doesn’t fix

Updating WordPress, your theme or your plugins does not fix PHP2Shell, because it’s a PHP vulnerability rather than a WordPress one. It lives in the engine WordPress runs on. Wiz demonstrated unauthenticated remote code execution against the standard WordPress, Drupal and Joomla container images, so a fully up-to-date WordPress site on unpatched PHP is still exposed. Keep WordPress updated, but make sure the PHP underneath it is patched too.

“One-click” WordPress images need extra care. AWS says its Bitnami-packaged Lightsail blueprints carry their own copy of PHP that the normal system update doesn’t touch, and it recommends moving to a Lightsail-packaged blueprint or replacing the bundled PHP. Other marketplace images can work the same way, so check with whoever supplied yours.

PHP hiding inside other products

PHP is often built into other software, such as hosting control panels like cPanel and Plesk, network appliances and some business applications. The NCSC tells organisations to watch for updates from these vendors too. The Dutch NCSC keeps a public list of products with a PHP dependency that may be affected. If a supplier runs a portal or system for you, ask whether they have patched. Our guide to supply chain cyber attacks explains why a supplier’s flaw can quickly become your problem.

Questions to ask your web host or IT provider

• Which PHP version, and which package, does each of our websites and systems run?
• Has it been updated to a version that fixes CVE-2026-109618 and CVE-2026-109619, and when?
• Was PHP fully restarted after the update?
• Have the server logs been checked back to 17 October for signs of attack?
• Are any of our systems on PHP 8.1 or older, and what is the plan for them?
• Does any software or appliance we rely on contain its own copy of PHP?

If the answers are vague, or you don’t have anyone to ask, that’s a sign your website needs a named owner. Our business IT support includes security patching and updates for servers, and our IT security audit checklist shows how to build an inventory of what you run.

What to do now: six steps for business owners

1. Find every PHP system, starting with anything on the internet. The NCSC says not to limit the search to old versions, because every version may be affected. Include websites, portals, staging copies and anything an agency or supplier runs for you.
2. Patch PHP today, or get your host to. That means PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux distribution’s patched package, followed by a full restart of PHP. A running PHP process keeps the old, vulnerable code in memory until it restarts.
3. If you can’t patch straight away, reduce the risk and consider going offline. PHP has published temporary measures, listed in the technical section below, but they don’t make a server safe. The NCSC says that if you can’t apply them, or they would take too long, you should consider taking the system offline until it is fixed.
4. Check for signs of a break-in. Attacks began before the fix was public, so look back to at least 17 October, not just 21 October. If anything looks wrong, follow the steps under “If you find signs of compromise” below.
5. Plan your way off old PHP. PHP 8.1 and older get no official fixes, and PHP 8.2 loses security support on 31 December 2026, about ten weeks away. Move to PHP 8.4 or 8.5.
6. Keep Cyber Essentials in mind. The NCSC’s Cyber Essentials requirements say critical and high-risk fixes must be installed within 14 days of release, and unsupported software must be removed or cut off from the internet. The PHP2Shell fixes came out on 21 October, so certified organisations have until 4 November 2026 at the latest. Much sooner is wiser. Our Cyber Essentials service and guide to the five technical controls explain what assessors look for.

Tip: UK organisations can sign up to the NCSC’s free Early Warning service, which sends notifications of potential threats on your network.

How we handled PHP2Shell for the customers we support

We look after PHP for the businesses we support as well as running it ourselves, so PHP2Shell landed on our desk as soon as the fixes came out on 21 October. Here’s what we did.

• We patched through the night. Our team worked overnight to patch every customer system we host or support, as well as our own internal systems. Each one got the fixed PHP and a full restart, so nothing was left running the old code.
• We took our own affected systems offline while we fixed them. A short outage is a small price compared with a compromised server.
• We checked for compromise. Because attacks began before the fix was public, we searched logs back to 17 October and looked for new or changed files, scheduled tasks and user accounts. Those checks are complete.

The lesson we took away: even working through the night, there’s a gap between a fix being released and it being installed, and attacks were already under way while it lasted. That’s why we checked for compromise rather than assuming everything was fine, and why we’d encourage you to do the same.

This is what we do for the businesses we support. When a critical fix lands, our team handles the patching, the restarts and the checks, so our customers don’t have to hear about it from the news, chase their host or stay up all night themselves. If nobody does that for your website or servers yet, our business IT support includes 24/7 emergency support for moments like this, or you can get a free IT quote.

Technical guide: how to check, patch and verify PHP

This section is for whoever manages your servers. Statuses are as of 22 October 2026 and are moving quickly, so check your vendor’s tracker before relying on them. If your team would like a second pair of hands, co-managed IT support lets us work alongside them.

Affected and fixed PHP versions

• PHP 8.5 has an extra path: the new fatal_error_backtraces feature, which PHP’s advisory calls the basis of its strongest confirmed exploit.
• Don’t trust php -v on Ubuntu. Distributions often add fixes to the version they already ship. Ubuntu 24.04’s patched PHP still reports 8.3.6, so check the package version instead.
• PHP’s backports for 7.4, 8.0 and 8.1 are deliberately minimal. According to Mattias Geniar’s patching guide, they also switch session upload progress off completely, whatever php.ini says.

How exposed is your set-up?

The cross-request bugs need the same worker to serve more than one request, which is normal for both prefork Apache and FPM pools. More workers make each attempt less likely to land, but they don’t remove the risk.

One detail differs between sources: Wiz’s write-up files the upload-progress bugs under CVE-2026-109618, while PHP’s advisory treats session upload progress as part of CVE-2026-109619. The same update fixes both, so it doesn’t change what you need to do.

Patched PHP packages by platform (as of 22 October 2026)

Trackers to bookmark: Ubuntu CVE-2026-109618, Debian CVE-2026-109618 and Red Hat CVE-2026-109618. The Ubuntu rows and the Debian 12 and 13 rows were checked directly against the vendors’ notices and tracker. The other rows come from Mattias Geniar’s package table (last checked at 07:19 UTC on 22 October), AWS and The Hacker News.

How to patch PHP and confirm the fix

Install the fixed PHP from the same source you already use, then fully restart every process that runs PHP. Repeat the steps for each PHP version on the server.

1. List every PHP package and where it comes from.

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'      # Debian / Ubuntu
apt-cache policy php8.3-common                  # which repository it comes from
rpm -qa 'php*' | sort                           # RHEL family

2. Upgrade only the PHP packages. Keep the quotes so the shell doesn’t expand the *.

sudo apt-get update
sudo apt-get install --only-upgrade 'php8.3*' libapache2-mod-php8.3   # swap 8.3 for your branch
sudo dnf upgrade 'php*'                                               # RHEL family

3. Restart PHP properly, using the table below. With mod_php, a graceful reload is not enough.

4. Confirm the fix is installed. On Ubuntu the package changelog names both CVEs. On Debian, the PPA and Red Hat, the changelog may only mention a new upstream version, so compare the package version with the table above.

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz   # Ubuntu / Debian
rpm -q --changelog php-fpm | head -5                                            # RHEL family

5. Confirm nothing still runs the old binary. Empty output means every process has picked up the new PHP.

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
sudo needrestart -b -r l      # Ubuntu / Debian

What to restart after upgrading

After patching: the new hard memory limit and known issues

• A new hard memory ceiling. The fix replaces PHP’s abrupt out-of-memory exit with an orderly stop at the next safe point, and adds a second, higher limit at which PHP ends the process immediately. Mattias Geniar reports the new setting is memory_hard_limit_percent, and we found it in Ubuntu 24.04’s patched package too. By default the hard limit is twice memory_limit for limits up to 1G, and a process that reaches it exits with code 137. Watch your PHP-FPM log for that after upgrading.
• Put a real memory limit back. If you set memory_limit = -1 as a stop-gap, restore a finite limit once you’ve patched.
• Known issues in the 21 October releases (reported as of 05:49 UTC on 22 October): a zend_mm_heap corrupted crash during SimpleXML garbage collection on 8.4.27 and 8.5.12 only (php-src #24488); some out-of-memory errors now end the worker with exit code 137 (#24492); and, rarely, upload progress wiping a session (#24493). None of these is a reason to stay on a version that can be broken into.
• Claims that 8.5.12 is “still vulnerable” trace back to a separate, older bug, according to the same guide. As of 22 October there was no new advisory and no published bypass.
• Consider leaving upload progress off. PHP’s advisory suggests keeping session.upload_progress.enabled = 0 after patching if you don’t need it, because attackers are now probing this “hardly-used and hardly-tested feature”. WordPress core doesn’t use it (we checked the code of WordPress 6.9.1), but check any upload or form plugins that show progress bars.

Temporary mitigations if you can’t patch yet

No setting fully prevents either bug. PHP’s advisories say updating is the only complete fix. The measures below block the paths PHP has confirmed, roughly in order of value. Set them in php.ini, the FPM pool or the web server configuration, not with ini_set() or .user.ini, which apply too late. Then fully restart PHP.

Sources: PHP’s advisory, the two GitHub advisories and Mattias Geniar’s mitigation notes. PHP warns that a container or cgroup cap can kill every worker at once unless each worker has its own group, so test it before relying on it.

Configuration examples

; php.ini drop-in, e.g. /etc/php/8.3/fpm/conf.d/99-php2shell.ini
; (for mod_php use /etc/php/8.3/apache2/conf.d/), then restart PHP
session.upload_progress.enabled = 0

# nginx: block multipart bodies. Put the map in the http {} context...
map $http_content_type $block_multipart {
    default       0;
    "~*multipart" 1;
}
# ...and this in every server {} block that passes requests to PHP
if ($block_multipart) { return 403; }

# Apache 2.4: in every PHP virtual host (also works in .htaccess if AllowOverride permits)
<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Remove the multipart blocks once you’ve patched, because they break legitimate uploads, including the WordPress media library.

Cloudflare and other web application firewalls

Cloudflare says its managed rules have protected customers on all plans, including Free, since 03:02 UTC on 21 October. On Pro, Business and Enterprise plans, check the Managed Ruleset is deployed in block mode. Cloudflare has also seen attackers changing their requests to get past its rules, so treat a web application firewall as an extra layer, not the fix. AWS has published guidance for AWS WAF users, including an updated PHP managed rule group.

Common mistakes: measures that don’t help

• Hiding errors with display_errors = 0, error_reporting or the @ operator. PHP touches the stale error state before it decides whether to show or log anything.
• Setting file_uploads = Off. PHP still parses the multipart body.
• Using ini_set() or .user.ini for mitigations. They apply too late.
• Relying on logins, CSRF checks, maintenance mode or security plugins. The attack runs before your application code.
• Using RLIMIT_AS or RLIMIT_DATA as a memory cap. These cause the very allocation failure the attack needs.
• Trusting a WAF or CDN while your server is reachable directly. Attackers can skip it by sending requests straight to your server’s IP address.
• “Taking the site offline” by disabling only the PHP handler. Apache or nginx may then serve your .php files as plain text, database passwords included. Stop the web server or return a 503 for every request instead.
• Reloading Apache gracefully with mod_php. Do a full restart.
• Checking only php -v on distributions that backport fixes.
• Updating WordPress and assuming you’re covered. PHP2Shell is fixed in PHP, not WordPress.

How to tell if you were targeted

A successful attack can leave very little behind. CrowdStrike reports that the worker process doesn’t crash, the server returns a normal HTTP 200, application logs show nothing unusual, and the only server-side trace may be a single memory-limit error in the web server’s error log. Hunt for behaviour, and search back to 17 October, as Amazon advises. None of the signs below proves an attack, and not finding them doesn’t prove you’re clean.

Signs to look for

• Web requests: unusual multipart POSTs, especially ones carrying a PHP_SESSION_UPLOAD_PROGRESS form field, followed by memory-limit errors or bursts of HTTP 500s. Also ordinary form posts with an extremely long field name (Datadog’s test exploit used one of about 3.5 MB) or raw binary bytes in field values, and the scanner user agent php2shell-scan/109618 reported by VulnCheck.
• Responses: unexpectedly large or malformed PHPSESSID cookies, which Wiz flags as a sign of the memory-disclosure bug.
• Error logs: “Allowed memory size of … bytes exhausted” errors, especially ones ending “in Unknown on line 0”, which means PHP failed before any script started. Apache child processes exiting with a segmentation fault (AH00052) can point to failed attempts.
• Processes: PHP workers crashing or restarting for no clear reason, and php-fpm, php-cgi, apache2 or httpd launching shells or downloading files. Datadog calls a web server process starting a shell the most direct evidence of a successful attack, and it’s exactly what endpoint monitoring such as managed detection and response (MDR) watches for.
• On the server: new or changed .php files in the web root, new scheduled tasks and new user accounts, including new WordPress administrators.

Quick checks for an Ubuntu or Debian web server

# Memory-limit fatals (Apache, nginx and PHP-FPM logs), then the start-up ones
sudo zgrep -h 'Allowed memory size' /var/log/apache2/error.log* /var/log/nginx/error.log* /var/log/php*-fpm.log* 2>/dev/null
sudo zgrep -h 'Allowed memory size' /var/log/apache2/error.log* /var/log/nginx/error.log* /var/log/php*-fpm.log* 2>/dev/null | grep 'Unknown on line 0'
# The known scanner user agent
sudo zgrep -h 'php2shell' /var/log/apache2/access.log* /var/log/nginx/access.log* 2>/dev/null
# PHP files created or changed in the web root since 17 October
sudo find /var/www -name '*.php' -newermt '2026-10-17' -ls
# Scheduled tasks
sudo ls -la /etc/cron.d /var/spool/cron/crontabs
# WordPress administrator accounts (needs WP-CLI; run in the site's folder)
wp user list --role=administrator

Your logs only go back as far as your log rotation keeps them. Plugin and core updates also change files, so review the results rather than treating every line as a hit. Central log monitoring, such as a SIEM service, keeps copies an attacker can’t quietly delete.

Reported attacker IP addresses

These addresses were reported publicly and are shown “defanged” (with [.]) so they can’t be clicked. Amazon says its addresses belong to anonymisation services that other people also use, so investigate any matches rather than relying on blocking them.

Sources: Amazon and The Hacker News.

If you find signs of compromise

1. Isolate the server from the internet, but don’t wipe it yet. Preserve the web, PHP and system logs.
2. Look for backdoors, as the NCSC advises: web shells, scheduled tasks and new accounts.
3. Rotate every secret the server holds if you think it was probed before you patched: database passwords, API keys, WordPress salts and keys, and TLS private keys. The memory-disclosure bug can leak secrets without leaving a web shell or process behind. Our free email breach checker shows whether an email address has appeared in a known data breach.
4. Rebuild from a known-good state if you can’t be sure the server is clean, using clean backups from before the attack.
5. Consider your legal duties. If personal data may have been exposed, the ICO says a notifiable breach must be reported within 72 hours of becoming aware of it.
6. Get specialist help if you need it. The NCSC points organisations to its assured Cyber Incident Response providers if they aren’t confident doing this themselves.

Remember: patching doesn’t remove anything an attacker left behind. If a web shell, scheduled task or stolen password went in before the fix, it’s still there afterwards.

PHP2Shell timeline

PHP2Shell went from private reports in August to an emergency release in October, with a leak bringing the release forward by a day.

Sources and further reading

All sources were checked on 22 October 2026.

• PHP: Security advisory: critical remote code execution vulnerabilities, update now (21 Oct 2026), the PHP 8 ChangeLog and supported versions
• PHP on GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation: Today’s PHP security release, and how we’re strengthening PHP security (21 Oct 2026)
• Ubuntu: USN-8948-1 and USN-8948-2 (21 Oct 2026)
• Debian: security tracker for CVE-2026-109618 (DSA-6574-1, DLA-4848-1)
• NCSC: Critical security issue affecting PHP (21 Oct 2026, updated 22 Oct) and Cyber Essentials: requirements for IT infrastructure v3.3
• NCSC-NL: php2shell product inventory
• CISA: Critical vulnerabilities in PHP require immediate patching (21 Oct 2026) and the KEV catalogue
• Wiz Research: PHP2Shell technical write-up and disclosure timeline (21 Oct 2026)
• Amazon: PHP2Shell exploitation prior to public disclosure (21 Oct 2026), security bulletin 2026-143 and Lightsail update guide
• watchTowr: PHP2Shell FAQ (updated 22 Oct 2026)
• The Hacker News: Someone tried to exploit PHP2Shell 4 days before the vulnerabilities were publicly disclosed (22 Oct 2026)
• CrowdStrike: CrowdStrike protects customers from threats delivered via PHP2Shell
• Datadog Security Labs: PHP2Shell detection, analysis and remediation (21 Oct 2026)
• Cloudflare: WAF protection for the PHP vulnerabilities (21 Oct 2026)
• Mattias Geniar: How to apply the patches and early mitigation steps
• Huntress: Rapid response: php2shell, leaked critical PHP vulnerabilities
• ICO: Personal data breaches: a guide