PHP2Shell: A UK Business Guide to the PHP RCE Flaw

The UK's National Cyber Security Centre has urged organisations to act immediately over PHP2Shell, two critical vulnerabilities in the PHP language tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project released an emergency fix on 21 October 2026; the NCSC, alongside CISA, the FBI and the NSA, followed with warnings to patch now. Both flaws are rated 9.2 on the CVSS v4.0 scale and let an unauthenticated attacker run code on a web server, or read sensitive data straight from its memory.

Crucially, the weakness is in PHP itself rather than in WordPress, a plug-in or your own code, which is why it reaches so far. If your organisation runs a website, a web app or anything built on PHP, this is one to deal with this week, not next month. Below is a guide for owners and managers first, then a detailed section for whoever administers your servers.

Does this affect my business?

For most UK SMEs the practical answer is: assume so until the server is confirmed patched. PHP powers roughly 70% of the web, so the useful question is not whether you use it but who maintains the server and whether they have updated and restarted PHP.

Three things are worth understanding without any jargon:

• It is not a flaw in your website. A well-built, fully updated WordPress, Laravel or Magento site is still vulnerable if the PHP underneath it has not been patched.
• CMS and plug-in updates will not save you. The only real fix is a patched PHP build on the server, with every PHP process restarted afterwards.
• There is nothing for an attacker to trick out of your staff. No password, no phishing email, no download; just web traffic aimed at your site.

The single most useful step for a manager is to ask your web agency, hosting provider or IT team one direct question: "Have we patched PHP for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), and has PHP been restarted on every server?" Then get the answer in writing. If you are on mainstream shared hosting the provider has very likely patched already, but you still want that confirmation and a check of the PHP version your own site runs.

The setups we see catching UK firms out

• Shared hosting with cPanel or Plesk. The host patches the PHP packages centrally, but each site can be pinned to a specific PHP version, so confirm yours is on a fixed build.
• A VPS or cloud server you rent. The patching is yours, not the provider's. This is where most unpatched business sites sit.
• Legacy sites on old PHP. Anything on PHP 8.1 or older has no routine upstream fix and needs urgent attention.
• PHP you did not know you had. Control panels, network appliances and some desktop software ship PHP internally; the NCSC specifically flags third-party products that bundle it.

The two flaws in plain terms

Both vulnerabilities trace to a single pattern in how PHP recycles its worker processes. A worker handles many requests in a row. When a request runs out of memory and aborts midway, PHP releases that request's memory, yet a global pointer into it can live on. The next request that worker handles then relies on that stale pointer before PHP has reset things.

• CVE-2026-109618 is the out-of-memory corruption bug. An allocation failure interrupts PHP while a request is only half-initialised, and the clean-up stage then treats that half-built state as if it were valid. Multipart (upload) bodies at start-up are one trigger; on Apache mod_php, even a normal form submission can push PHP over the edge.
• CVE-2026-109619 is the stale-global-state bug. State that belonged to one request survives the freeing of its memory, and the next request on the same worker uses it first. Confirmed triggers include session upload-progress handling, the PHP 8.5 fatal-error backtrace feature, and warnings from per-request configuration settings.

Wiz, which discovered the flaws, demonstrated unauthenticated remote code execution against stock WordPress, Drupal and Joomla, plus a Heartbleed-style memory-disclosure path that spills leftover memory, potentially passwords, session tokens, API keys and TLS certificates, into the response cookie. The patched releases stop the abrupt abort, reset state between requests, and add a higher hard memory ceiling.

How your PHP runs changes your risk

Every web-facing PHP is affected, and the attack relies on features that ship switched on, such as sessions and file uploads.

• Apache mod_php is the worst case: PHP proved full remote code execution over HTTP with default limits, firing before any application code.
• PHP-FPM behind nginx, Caddy or Apache is still high risk; terminating a failed worker closes the mod_php path, but upload-progress, app-triggered and OPcache paths remain.
• php-cgi, FrankenPHP and LiteSpeed are named as at risk, because any persistent worker can carry stale state forward.
• Command-line scripts and cron jobs are low risk, since they are not reachable over the web.

Patch and verify: the technical steps

PHP is explicit that patching is the only complete fix. Update to the fixed release for your branch, then restart every PHP process so the old code is cleared from memory.

Watch the version-number trap. Distribution packages retain their old version string after patching, so a patched Ubuntu 24.04 still prints PHP 8.3.6. Check the package version against your vendor's advisory, not php -v. The Ubuntu 24.04 fixed package is 8.3.6-0ubuntu0.24.04.13, per Ubuntu notice USN-8948-1.

Shared hosting with cPanel or Plesk

On managed shared hosting you usually do not patch PHP yourself; the provider updates the ea-php or alt-php packages (CloudLinux shipped fixed builds for every version from ea-php52 to ea-php85). Your jobs are to confirm the host has patched, and to check the PHP version assigned to your site in the control panel, since sites can be pinned to an older branch. The reliable way to see what your site actually runs is a short script placed in the web root and opened once in a browser, then deleted:

<?php echo PHP_SAPI, " ", PHP_VERSION;

That shows both the interface (for example fpm-fcgi or apache2handler) and the version serving live requests, which php -v on the command line may not match.

On a server you manage

1. Inventory every PHP install:

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'   # Debian / Ubuntu
rpm -qa 'php*' | sort                          # RHEL family

2. Upgrade only the PHP packages (mind the quotes), using your branch:

sudo apt-get update
sudo apt-get install --only-upgrade 'php8.3*' libapache2-mod-php8.3
# RHEL family:
sudo dnf upgrade 'php*'

3. Restart PHP correctly (table below); on mod_php a reload is not enough.

4. Confirm the fix landed, then confirm no process still holds the old binary:

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-common/changelog.Debian.gz
sudo needrestart -b -r l

Buying time: mitigations that only go so far

No configuration change fully closes either hole; the following block only the paths PHP has confirmed, and must be set in php.ini, in an FPM pool, or at the web server, then loaded with a full restart (not through ini_set() or a .user.ini file). Use them for hours while you prepare to patch, not as a destination.

• Reject multipart request bodies at the web server (uploads on those paths stop working).
• session.upload_progress.enabled = 0.
• fatal_error_backtraces = 0 on PHP 8.5.
• pm.max_requests = 1 on PHP-FPM, so a worker cannot pass state on.
• memory_limit = -1 set administratively, with a container or cgroup cap instead.

# nginx: in the http {} block, then the if in each PHP server {}
map $http_content_type $block_multipart { default 0; "~*multipart" 1; }
if ($block_multipart) { return 403; }

What will not protect you: hiding PHP errors, disabling file_uploads (PHP still parses the body), and any application-level control such as a login, CSRF token or maintenance mode, because the attack runs before your code. A CDN or WAF helps only if your origin server cannot be reached directly on its own IP, and attackers are already mutating payloads to slip past published WAF rules. If you run PHP 8.1 or older with no distribution fix, the NCSC's advice is clear: migrate to a supported version, and consider taking the system offline until you can.

Detecting compromise and indicators to hunt

A successful PHP2Shell attack can be almost invisible, so look for behaviour and search back to 17 October, the date of the first known attempt, not the 21st. Nothing here is proof on its own, and a clean search is not a clean bill of health.

# Memory-limit fatals across web and FPM logs
sudo zgrep -h 'Allowed memory size' /var/log/apache2/error.log* /var/log/nginx/error.log* /var/log/php*-fpm.log* 2>/dev/null
# The known scanner user-agent
sudo zgrep -h 'php2shell' /var/log/apache2/access.log* /var/log/nginx/access.log* 2>/dev/null
# PHP files added or changed in the web root since 17 Oct
sudo find /var/www -name '*.php' -newermt '2026-10-17' -ls

Other tell-tales are unusually large or malformed PHPSESSID cookies (the signature of the memory-disclosure bug), PHP processes launching shells or tools such as curl, wget or nc, and new cron entries or accounts. Legitimate updates also touch files, so review findings rather than acting on them blindly. If you confirm a compromise, isolate the server, keep the logs, and rotate every credential it holds; the memory-disclosure path can expose secrets without leaving a web shell, and patching does not undo what an attacker did beforehand.

If data was exposed: UK reporting duties

Where personal data may have been accessed, UK GDPR requires you to assess the breach and, if it is likely to risk people's rights and freedoms, report it to the Information Commissioner's Office (ICO) within 72 hours of becoming aware. PHP2Shell's memory-disclosure path matters here: leaked session tokens, passwords or customer records can be a reportable breach even if no obvious web shell was planted. Report cyber crime through Action Fraud in England, Wales and Northern Ireland, or Police Scotland on 101, and use the NCSC's reporting routes for significant incidents. Regulated firms should also weigh their sector obligations.

How quickly this escalated

Wiz found the first bug on 19 August 2026 and reported it to PHP on 24 August, with an acknowledgement on 21 September. An Amazon honeypot logged the first exploit attempt on 17 October, before any public disclosure, and a leak on 20 October pushed PHP to release the fix a day early on 21 October. With VulnCheck counting around 2.6 million internet-facing PHP hosts, many on long-unsupported versions, the window between disclosure and mass exploitation was effectively zero.

How Omega IT responded, and how we can help

On 21 October 2026, the same day the fixed builds appeared, our team updated and re-verified the servers in our care. Omega IT is certified to Cyber Essentials Plus (2026, via CyberSmart), which means we work to the standard we recommend to clients. If you do not know who is accountable for patching your websites, or you would value an outside review of your exposure, this is routine work for us.

Our cyber security services cover vulnerability response, patching and monitoring, while managed IT support and outsourced IT support keep your estate current so the next critical disclosure is routine rather than an emergency.

Sources

• UK NCSC: Critical security issue affecting PHP
• PHP security advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Wiz Research: PHP2Shell technical write-up and timeline
• Huntress: Rapid Response: php2shell
• watchTowr: PHP2Shell FAQ
• The Hacker News: exploited four days before disclosure
• Ubuntu: USN-8948-1: PHP vulnerabilities
• Mattias Geniar: applying the patches and early mitigation steps
• Jacar: check your version and patch

Related reading

• The importance of cyber security for UK businesses
• Ransomware response: a UK business action plan
• SIEM and MDR explained

This article is general guidance and reflects the position on 22 October 2026; vulnerability and vendor details may change. All diagrams by Omega IT.