Critical PHP2Shell Vulnerability Alert - Majority online Servers and Services Affected CVE-2026-109618/109619

On 21 October 2026 the PHP project shipped emergency security releases for two critical flaws that let an attacker run their own code on a web server without logging in. Researchers have nicknamed the pair PHP2Shell. They are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 out of 10 on CVSS v4.0. Details leaked online the day before the patches arrived, Amazon recorded an exploit attempt four days before disclosure, and by the evening of 21 October Amazon said the flaws were being broadly exploited in the wild. The UK's National Cyber Security Centre has urged organisations to act immediately.

Because the bug is in PHP itself rather than in any one application, it reaches WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel and custom PHP sites, the control panels that host them, VoIP phone systems such as FreePBX, firewalls, monitoring tools and a great deal of other software that never mentions it runs on PHP. This guide explains what PHP2Shell is, what an attacker can do with it, whether it affects your server, your website or both, which systems are at risk, and exactly what to do today.

PHP2Shell latest updates: 22 October 2026

This is a fast-moving incident, and we update this section through the day. The newest developments come first, with the critical ones highlighted.

Update, 23 October 2026 (20:00 UTC)

• Critical: PHP has disclosed a third flaw that the 21 October releases do not fix. CVE-2026-115560 is another remote code execution route through PHP's session upload progress feature. PHP says it needs an unusual combination of server configuration and application code, and it will be fixed in PHP's next regular release. Turning off session upload progress, already one of the PHP2Shell mitigations, also blocks this flaw, and PHP now suggests keeping the feature off until that release. If you switched it back on after patching, switch it off again: set session.upload_progress.enabled = 0 and restart PHP.
• Botnets have joined in. Researchers have tied PHP2Shell attempts to operators of the Mirai botnet, which recruits hacked Linux servers and devices into a network used for attacks. Sophos has published indicators from these attempts, including a payload dropped at /tmp/nfs and a scanner that identifies itself as php2shell-scan/109618. We have added checks for them to the breach-detection steps below.
• Firewall and appliance fixes are still days away. Citrix plans to release fixed NetScaler versions for all supported releases on 27 October. Palo Alto still has no fixed PAN-OS or Panorama release; it advises restricting management access, for example to a dedicated jump box, and its Threat Prevention signature (Threat ID 543004) helps protect PHP servers behind its firewalls. Synology has now published advisory Synology-SA-26:14 with fixed PHP packages, and QNAP has urged users to take its devices off direct internet exposure.
• Still not on CISA's exploited list. As of 23 October, neither CVE is in CISA's Known Exploited Vulnerabilities catalogue, in line with the absence of confirmed compromises.
• New tools to check your exposure and look for intruders. Censys has a public dashboard tracking in real time how many internet-facing PHP services still run a vulnerable version. Singapore's Cyber Security Agency has published guidance on monitoring for PHP2Shell-related compromises, and SOCRadar has released a flash report with indicators of compromise and hunting guidance. Huntress says Sigma and YARA detection rules will follow.
• PHP2Shell is not the only fire. The past three weeks have brought a run of critical, actively exploited flaws in firewalls, VPNs, remote-support tools, email gateways and backup servers, several from the same vendors affected by PHP2Shell. See other critical vulnerabilities to patch right now further down this page.

Evening update, 22 October 2026 (17:45 UTC)

• Critical: the first signs of real break-ins. The Dutch National Cyber Security Centre said on 22 October that it is investigating first signs of successful misuse of PHP2Shell. Until now, reports described exploit attempts rather than confirmed compromises. If you have not checked your servers for compromise back to 17 October, do it now. (Update, 23 October: no successful compromise has been confirmed so far; see above.)
• Experts disagree on how widespread attacks will get. Sansec now says mass exploitation is less likely than it feared on release day: a successful attack needs specific knowledge of the target server and specific conditions on it, and the public exploits do not work against a default PHP installation. Amazon and Hadrian, however, still describe exploitation at scale, and analysts at Howler Cell expect a publicly documented compromise within days. Our view: fewer one-shot mass hacks does not mean you are safe. Targeted attacks still work, and the memory-leak route can steal passwords and keys while leaving almost no trace in web logs.
• Rocky Linux and Amazon Linux are now patched. Rocky Linux synced Red Hat's fixes overnight for its 8, 9 and 10 releases, and Amazon Linux 2023 now has fixed PHP 8.2 to 8.5 packages (ALAS2023-2026-3301 to 3304). On Rocky Linux and AlmaLinux, the security-only update list may not show these fixes, so run a full dnf upgrade. Remi's repository has also caught up, with free fixes for the end-of-life PHP 7.4, 8.0 and 8.1 and 7.2 and 7.3 to follow. The patch tracker below has the details.
• Critical: a working exploit that beats a key defence now exists. VulnCheck says it has built a fully working exploit for CVE-2026-109618 that bypasses address space layout randomisation (ASLR) on standard x86-64 servers, which it is sharing privately with customers. None of the hundreds of public proof-of-concept exploits had managed that yet, while ARM64 servers were already easier targets. Expect criminals to reach the same point.
• Almost nobody has patched yet. OX Security found that roughly 99% of affected hosts whose PHP version it could identify were still not showing a patched version 24 hours after the release. VulnCheck counted more than 1.1 million hosts, 42% of those it could identify, running PHP versions that no longer get official updates.
• A free exposure scanner is out, but beware fakes. Searchlight Cyber has released php2shell-scanner, an open-source tool that tests whether a host is exposed. Around 100 GitHub repositories mentioning PHP2Shell appeared within a day of disclosure, so stick to tools from known security firms and never run unknown "exploit" or "checker" code on production servers.
• Still not on CISA's exploited list. As of the latest checks on 22 October, neither CVE is in CISA's Known Exploited Vulnerabilities catalogue. The US National Vulnerability Database has now scored both 9.8 out of 10 on the older CVSS v3.1 scale.
• Cloudflare protection is on by default. Cloudflare says customers on its free or paid web application firewall have been protected by default since 03:02 UTC on 21 October, including rules that stop leaked server memory from reaching an attacker. It is a useful shield, not a substitute for patching.
• No follow-up PHP release yet. At our check, PHP had not yet released new versions fixing the known bugs in 8.4.27 and 8.5.12 listed below.

Morning update, 22 October 2026

• Critical, new: big-name firewalls and network appliances are affected. Palo Alto Networks lists every PAN-OS version from 10.2 to 12.2, plus Panorama, as affected, with no fix date yet. Citrix says NetScaler is impacted on all supported versions because its management portal uses PHP, and F5 lists the BIG-IP Configuration utility as affected. These are the devices that protect everything else, so restrict their management interfaces to trusted admin networks today. Details are in the manufacturer statements below.
• Critical: PHP2Shell is now being broadly exploited. Amazon's threat intelligence team said on the evening of 21 October that PHP2Shell is being broadly exploited in the wild. It saw proof-of-concept exploits used against its sensors almost as soon as they appeared, from about 02:00 UTC on 21 October, with payloads and infrastructure pointing to multiple attackers. The earlier "no exploitation seen" reports from 21 October are now out of date.
• Critical: attacks started on 17 October, four days before disclosure. Amazon's honeypots recorded an exploit attempt on 17 October from an anonymisation network, while the flaws were still under embargo. It is not known how the attacker got the details early. Amazon recommends starting any investigation from 17 October, not from the disclosure date, so check your logs and files back to then.
• Critical: attempts are in the millions. Cloudflare's chief executive, Matthew Prince, said Cloudflare saw thousands of exploit attempts in the 10 hours before the announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions since.
• Critical: a restart is not always a restart. Engineer Mattias Geniar's tests found that an Apache reload or graceful restart leaves mod_php running the old, vulnerable PHP; only a full stop and start loads the fix. On LiteSpeed, restarting the web server does not restart the separate lsphp processes. Use the check in step 5 of the emergency checklist to prove nothing is still running the old PHP.
• UK and European organisations are taking sites offline. The Office for Budget Responsibility, Oxfordshire County Council and Hillingdon Council took their websites down as a precaution, and the UK government said work was under way to identify and patch any exposure. Across Europe, Charité hospital in Berlin, the city of Mainz, Ruhr-Universität Bochum, the University of Basel and the Swiss host Cyon were reported to have done the same, and HR provider BambooHR warned that payroll would be interrupted. The US National Security Agency and the Australian Cyber Security Centre have also urged organisations to apply updates, and the Wikimedia Foundation said it was addressing the vulnerabilities.
• Experts expect worse to come. NetBlocks director Alp Toker told Sky News the disruption so far has been limited but is likely to spread, warning that AI agents can reproduce the attack much more easily. OpenAI, which led the research team behind the discovery, called it one of the most impactful security issues in recent memory.
• Critical: put your memory limit back after patching. If you set memory_limit = -1 as a temporary mitigation, restore a normal value once the fix is installed. The fixed PHP adds a second, hard memory limit (memory_hard_limit_percent, 200% of memory_limit by default), so leaving memory_limit at -1 switches off both. A process that reaches the hard limit is stopped immediately, without running its shutdown functions.
• Keep session upload progress switched off. Attack-surface firm Hadrian reported on 21 October that most of the exploitation it saw at scale came through PHP's session upload progress path. Few sites use the feature, so leaving session.upload_progress.enabled = 0 in place after patching costs nothing.
• Known bugs in the new releases. Bug reports filed against 8.4.27 and 8.5.12 on 21 October include a crash with heap corruption when code uses SimpleXML (GH-24488), functions such as sprintf(), pack() and bin2hex() killing the process at the new hard limit instead of raising a catchable error (GH-24492), and in 8.5.12, an edge case where the upload-progress handler destroys a whole session (GH-24493). If sites start crashing after the update, check these first. Do not roll back to a vulnerable version; work around the problem and watch for PHP's next release.
• The exposure is huge. Palo Alto Networks' Cortex Xpanse counted more than 22.6 million exposed instances potentially vulnerable to PHP2Shell.
• Vendor news. pfSense has been reported as patched, with PHP 8.5.12 in pfSense CE 2.9.0 and Plus 26.07, and the Plesk panel hotfix (18.0.81 Update 4) has shipped. Fortinet says FortiOS, FortiManager, FortiAnalyzer, FortiWeb, FortiMail and others are not affected, but it is still checking FortiADC, FortiClient EMS, FortiSIEM and FortiSOAR. Cisco has confirmed no affected products yet. Synology has now said it is assessing its products and preparing updates; QNAP has made no official statement. Full details are in the manufacturer statements and patch tracker below.
• Scanners now detect it. Qualys and Tenable have released detections for PHP2Shell, including local checks for Linux distribution packages, so a vulnerability scan is a quick way to find PHP you did not know about.

Which PHP versions are vulnerable to PHP2Shell?

This is causing confusion, so to be completely clear: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are the fixed versions. They are what you need to update to, not the versions that are affected. Every PHP release before them is vulnerable, including PHP 8.1, 8.0, 7.x and older 5.x releases. You do not need to jump to PHP 8.5: stay on the version your sites use and update to the fixed release for it.

• PHP 8.5: 8.5.11 and earlier are vulnerable. Update to 8.5.12 or later.
• PHP 8.4: 8.4.26 and earlier are vulnerable. Update to 8.4.27 or later.
• PHP 8.3: 8.3.35 and earlier are vulnerable. Update to 8.3.36 or later.
• PHP 8.2: 8.2.34 and earlier are vulnerable. Update to 8.2.35 or later.
• PHP 8.1, 8.0, 7.x and 5.x: every release is vulnerable, and the PHP project is not issuing new releases for these versions. You need a patched build from your hosting panel, Linux distribution or a support vendor (see the platform notes below), or an upgrade to a supported version.

A quick way to read your own version: if php -v or your hosting panel shows 8.3.35, or an older 8.3 release such as 8.3.3, that copy of PHP is vulnerable. If it shows 8.3.36, it is patched, provided PHP has been restarted since the update. There are two catches. Some patched builds keep their old version number, as Plesk's patched PHP 7.4, 8.0 and 8.1 do, and Linux distributions often patch older releases while changing only the package suffix, so check the build date or package release as well. And many servers run more than one PHP, so check every copy. The patch tracker further down this page lists the fixed package for each Linux distribution, with the date and time each one became available.

What is PHP2Shell?

PHP2Shell is the name given to two memory-safety bugs in the PHP engine. Both come down to the same weakness: when a web request ends abnormally, PHP can leave its internal memory in a broken state, and a skilled attacker can steer what happens next. PHP's own security advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php as the highest risk, because the demonstrated attack fires before any application code runs.

CVE-2026-109618: memory corruption when PHP runs out of memory

PHP stops a request abruptly when it runs out of memory. According to the technical advisory, if that happens while internal request data is only half set up, the clean-up code that runs afterwards treats the broken data as valid. Specially crafted multipart requests, the format browsers use to submit forms and upload files, can push PHP to that point while still appearing to stay within its size limits. PHP confirmed full remote code execution over HTTP against Apache mod_php running with its default memory and input limits.

CVE-2026-109619: one request's leftovers poison the next

A PHP worker handles many requests one after another. This second flaw lets internal state from one request survive after its memory has been freed, so the next request handled by the same worker can use that stale data before PHP resets it. PHP confirmed remote code execution against both mod_php and PHP-FPM, along with memory disclosure. One confirmed route runs through session upload progress, a little-used feature that is switched on by default and works even if a site never starts a session.

The memory leak is serious in its own right. Sansec reports that it can hand an attacker fragments of other visitors' requests, including passwords, session tokens, API keys and even TLS private keys, much like the Heartbleed bug did to OpenSSL in 2014.

How PHP2Shell came to light

The flaws were found independently by several teams and were meant to be disclosed in an orderly way. That plan fell apart a day early.

• 1 to 24 August 2026: researchers at Calif find several remote code execution paths and report the first to PHP on 11 August. Wiz Research reports the vulnerabilities on 24 August, and OpenAI is also credited with the discovery.
• 20 October: details leak on Hacker News ahead of the agreed disclosure date. watchTowr confirms the flaws are real, and the PHP security team posts advance notice of an emergency release.
• 21 October, 07:43 UTC: Cloudflare reports early attacks, more than six hours before any patch is available.
• 21 October, 14:00 UTC: PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the researchers publish their write-ups.

Why PHP2Shell is the most urgent vulnerability right now

We do not call something an emergency lightly. Several factors line up here that rarely appear together.

• No login needed. The attacker simply sends web requests. There is no password to guess, no phishing email and no user who has to click anything.
• It fires before your code runs. On mod_php the confirmed attack works before WordPress, Magento or your own application has even loaded, so security plugins cannot see it and maintenance mode does not help.
• The scale is enormous. PHP powers an estimated 75 to 80 per cent of websites, and BleepingComputer reports a VirusTotal estimate of more than 5.1 million PHP hosts exposed online.
• It goes back more than a decade. Sansec traces the vulnerable code to PHP 5.4.0, released in 2012, so old servers are exposed alongside new ones.
• It is proven against the platforms businesses use. Calif demonstrated code execution without a login against current releases of WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS.
• Attackers had a head start. The leak gave criminals the same day's notice as defenders, and the write-ups and an exploit tool are now public.

What the PHP2Shell alerts and security researchers are saying

The advice from the PHP project, government agencies and the security firms tracking PHP2Shell is unusually consistent.

All PHP users are strongly encouraged to update immediately.

— PHP security team, security advisory, 21 October 2026

…you should consider taking the system offline until it can be fully mitigated.

— UK National Cyber Security Centre, on systems that cannot be updated or mitigated quickly

Rapid7 recommends updating affected installations on an emergency basis, outside of normal patch cycles.

— Rapid7 Emergent Threat Response

…among the most severe vulnerabilities discovered in PHP, and arguably in software history.

— Wiz Research, quoted by Help Net Security

You cannot fix PHP2Shell from within your store code.

— Sansec Forensics Team, writing for online shop owners

This is a goldmine for hackers.

— Shahak Shalev, Global Head of Scam and AI Research, Malwarebytes, on attackers hijacking trusted websites to phish visitors and spread malware

…just the beginning of a wider wave of attacks.

— Alp Toker, director of NetBlocks, speaking to Sky News, 22 October 2026

Update, 22 October: Amazon's threat intelligence team now says PHP2Shell is being broadly exploited in the wild, after recording an exploit attempt as early as 17 October, and Cloudflare reports millions of exploit attempts. The paragraph below records how the picture looked on 21 October, when reports still conflicted.

On 21 October, reports of real-world attacks did not all agree. Cloudflare's chief technology officer said the company was seeing early attacks before the patches were released, and Cloudflare has pushed emergency firewall rules to all of its customers, including those on free plans. watchTowr says its global honeypot network has observed exploitation in the wild. Patchstack says it has confirmed multiple active exploitation incidents. On the other side, Huntress had still seen no attacks across its partner systems as of 20:30 UTC on 21 October. The US Cybersecurity and Infrastructure Security Agency (CISA) has issued its own alert urging immediate patching, but said it had not observed exploitation when it published, and as of 21:03 UTC neither flaw was on its Known Exploited Vulnerabilities list.

The direction of travel is clear, though. Rapid7 expected a working exploit to go public soon; by the afternoon Sansec reported that write-ups and an exploit tool were already out, and it expects mass exploitation to follow. In the Netherlands, several high-profile sites, including the House of Representatives and the Dutch NCSC, went offline as a precaution. Waiting for a confirmed attack on your own server is not a plan.

There are also signs that attackers are automating their way to permanent access. Techzine reports that security operations centres saw massive automated scans within hours of the leak, with the first waves of attacks believed to be aimed mainly at planting web shells and cryptominers. Sansec had warned via SecurityWeek that mass exploitation would likely start within 15 minutes of the patches appearing. A web shell is a backdoor: it stays on the server after PHP is updated, so an attacker who got in before you patched can simply walk back in afterwards. If your server was online and unpatched at any point since 17 October, when Amazon recorded the first exploit attempt, assume a backdoor could be there, and check for one before you call the job finished.

What an attacker can do with PHP2Shell

Remote code execution means the attacker can run commands on your server as the account PHP runs under, usually the web server user or the site's hosting account. That is enough to do almost all of the damage that matters to a business. These are the things attackers typically do once they have this kind of foothold.

On an online shop the most likely outcome is a card skimmer: a few lines of JavaScript added to the checkout that send every customer's card details to the attacker, often unnoticed for months. On servers where every site runs under the same web server account, as with classic Apache mod_php setups, one compromised site can expose all the others. And because these attacks are automated, nobody picks you as a target. Bots scan the whole internet and exploit whatever answers.

A typical PHP2Shell attack, step by step

A bot sends a crafted form upload to any PHP page on your site. On a vulnerable mod_php server the request triggers the flaw before your application even loads, and the bot gets a command shell as the web user. It writes a small PHP backdoor into an uploads or temporary folder, reads wp-config.php or .env for the database credentials, creates a hidden administrator account and adds a scheduled task so it can get back in even after you update PHP. The whole sequence can take seconds, which is why patching on its own is not enough if your server was exposed.

Does PHP2Shell affect servers, websites or both?

Both, but the fix lives in one place. The vulnerability is in the PHP engine installed on the server, so the server is what needs updating. Every website running on that server inherits the risk, whatever it is built with and however well its own code is written. Codeable reports that WordPress.org has confirmed no WordPress update is needed or planned: the fix is the PHP update alone. Nothing you change inside a website removes the flaw.

If you run your own server

On a VPS, dedicated or cloud server, you are responsible for the update. That covers every PHP version installed side by side by Plesk, cPanel or CloudLinux, not just the one your main site uses. It also covers PHP inside Docker containers, Windows servers running PHP under IIS, and any appliance or vendor product that bundles its own copy of PHP. The Dutch NCSC keeps an inventory of software products with a PHP dependency that may be affected. PHP used only on the command line is outside PHP's at-risk list, but update it anyway, because it usually ships in the same package.

If you are on shared or managed hosting

Your host has to patch the server, but do not assume they have. Ask them to confirm in writing that your server runs a patched build and that PHP has been restarted. If your site still runs on PHP 8.1 or older, ask whether they have installed a backported fix, and plan a move to a supported version either way.

If you only own the website

You cannot fix PHP2Shell from inside the website, but you do need to make sure someone has fixed the server, check the site for signs of compromise and change any passwords and keys it holds if there is any doubt. Keep updating plugins and themes as normal; they simply do not close this hole.

Which systems does PHP2Shell affect? VoIP, Linux servers and more

PHP2Shell is not just a website problem. Any server or device that uses PHP to answer web requests is in scope, and that takes in a long list of systems few people think of as PHP at all: phone systems, firewalls, monitoring dashboards, NAS boxes, CCTV recorders and password managers. Many of these run a PHP admin interface on an ordinary Linux server, sit on the network for years without updates, and hold the keys to everything else. Malwarebytes warns that this forgotten infrastructure, from abandoned websites to devices with PHP-based management pages, is the longer-term risk once the immediate emergency passes. Use the list below as your checklist when you hunt for every copy of PHP.

VoIP servers and business phone systems

Asterisk and FreeSWITCH, the engines behind most open-source phone systems, are not written in PHP, but the web interfaces that manage them usually are. On FreePBX the web server normally runs as the same account as Asterisk, so a foothold in the admin panel is effectively control of the phone system. PBX web interfaces are also often reachable from the internet, because the user control panel, softphone apps and handset provisioning rely on them.

• FreePBX and Sangoma PBXact. Checks shared on the FreePBX community forum show FreePBX 17 on Debian 12 running PHP 8.2 through Apache mod_php, the setup PHP rates as highest risk; Debian 12's security repository now carries the fixed 8.2.35 package. FreePBX 16 runs PHP 7.4 on Sangoma Linux 7 and FreePBX 15 runs PHP 5.6. Both are end-of-life PHP versions with no official PHP release, so check with Sangoma for a patched package and plan the move to FreePBX 17.
• VitalPBX. VitalPBX runs on Debian 12, and VitalPBX has published guidance telling customers to install Debian's fixed PHP 8.2.35 package.
• Other Asterisk and FreeSWITCH platforms. Issabel and the older Elastix, FusionPBX, and SIP proxy control panels such as Siremis for Kamailio and the OpenSIPS Control Panel all use PHP web interfaces.
• Contact centre platforms and diallers. VICIdial, ViciBox and GOautodial use PHP for their agent and administration screens.
• VoIP billing and reseller portals. A2Billing, MagnusBilling and ASTPP are PHP applications, as are many custom billing, call record and call recording portals built in-house.
• Provisioning, wallboards and reporting. Any server that generates handset configuration files, call statistics or wallboards with PHP is exposed in the same way.
• Commercial appliances and hosted phone platforms. These may or may not use PHP internally. If you are unsure, ask the vendor directly whether their product is affected.

A compromised phone system costs money fast. Attackers typically use it for toll fraud, running up large bills on premium-rate and international numbers through your SIP trunks within hours. They can also steal trunk credentials, listen to call recordings and voicemail, or divert your inbound calls. Until a PBX is patched, restrict its web interface, user control panel and provisioning to a VPN or trusted IP addresses, and disable session upload progress. Then check the call records for unexpected international or premium-rate calls, and the configuration for new extensions, trunks, outbound routes or admin users. Our VoIP services team can check and secure business phone systems.

Web hosting and control panel servers

• Shared, reseller, VPS and dedicated hosting servers running cPanel and WHM, Plesk, DirectAdmin, CloudLinux, ISPConfig, HestiaCP, Froxlor or Virtualmin, including every PHP version installed side by side for customer sites.
• The hosting panel itself where it runs on PHP, as Plesk's interface and HestiaCP's internal hestia-php runtime do.
• Managed WordPress and Magento hosting, staging servers and old servers left running after a migration.

Websites, online shops and web applications

• Content management systems such as WordPress, Drupal, Joomla, TYPO3, Craft CMS, Concrete CMS, Grav, Silverstripe, Statamic, ProcessWire, Neos, SPIP and Backdrop.
• Online shops such as Magento and Adobe Commerce, WooCommerce, PrestaShop, OpenCart, Shopware, Sylius, Pimcore, Bagisto, Spryker and HikaShop for Joomla. Shopware 5 is no longer actively maintained, so treat it as high risk.
• Custom applications built on Laravel, Symfony, CodeIgniter, CakePHP, Yii or plain PHP, including client portals, booking systems and intranets.
• Forums, wikis and learning platforms such as phpBB, Simple Machines Forum, MediaWiki, DokuWiki, PmWiki, BookStack and Moodle.

Email and webmail servers

• Webmail such as Roundcube, SquirrelMail, SnappyMail, RainLoop and Horde, including the copies bundled with mail server packages such as iRedMail and Mail-in-a-Box.
• Mail administration panels such as PostfixAdmin and the mailcow web interface.
• Email marketing platforms such as Mautic, phpList and Sendy.

Firewalls, routers and network management

• Enterprise firewalls, VPN gateways and load balancers whose management interfaces use PHP. Palo Alto PAN-OS and Panorama, Citrix NetScaler and the F5 BIG-IP Configuration utility are confirmed affected, Juniper's J-Web interface on SRX and EX devices is reported to be PHP-based, and Ivanti appliances are reported to use PHP too. Never expose these management interfaces to the internet.
• Open-source firewalls whose web interface is written in PHP. OPNsense has released fixed versions, and pfSense has been reported as patched (see the manufacturer statements below). Both run on FreeBSD rather than Linux, but the PHP they ship is exposed in the same way.
• Network and IP address management tools such as phpIPAM, RackTables and LibreNMS.
• Captive portals and guest Wi-Fi sign-in pages built in PHP.

Ubiquiti UniFi networks

As of 21 October 2026, Ubiquiti has not published any advisory mentioning PHP2Shell. As far as we can tell, UniFi consoles, access points, switches and the UniFi Network Application are not built on PHP, so there is no UniFi patch for this flaw because there is nothing PHP-based to patch. We will update this page if Ubiquiti says otherwise. UniFi networks can still be exposed indirectly, though.

• Self-hosted controllers on shared servers. A UniFi Network Application on a Linux server or VPS that also runs PHP, such as a website, a hosting panel or phpMyAdmin, is only as safe as that PHP. Patch the server, and keep the controller and its backups out of reach of the web server account.
• PHP tools connected to UniFi. Guest Wi-Fi external portals, voucher systems, dashboards and scripts built on PHP UniFi API clients usually store a UniFi admin login. If their server is compromised, the attacker can take over the whole network. Patch these servers first, and change the stored UniFi credentials if there is any doubt.
• Older Ubiquiti airOS equipment. airOS was found in 2017 to be running a very old PHP version from the 1990s in its web interface. That is a different codebase from the one PHP2Shell targets, but keep airOS management off the internet and its firmware current either way.

Separately, UniFi OS has had serious flaws of its own this year, including critical issues fixed in UniFi OS 5.1.19 and later under Ubiquiti's Security Advisory Bulletin 066. If you are updating servers anyway, update your UniFi consoles and applications in the same window, and make sure no UniFi management interface is open to the internet. As specialist UniFi installers, we can check and update UniFi networks for you.

Monitoring, IT management and helpdesk tools

• Monitoring dashboards such as Zabbix, Cacti, Nagios XI, Nagios Fusion, Icinga Web 2, Centreon and Observium, which often hold credentials for every device they watch.
• Asset, inventory and IT service management tools such as GLPI, Snipe-IT and OCS Inventory.
• Helpdesks such as osTicket, FreeScout, HESK and UVdesk.
• Server and virtualisation panels such as phpVirtualBox and the Pterodactyl game server panel.
• Database administration tools such as phpMyAdmin, Adminer and phpPgAdmin.

Business applications and password managers

• CRM and ERP systems such as SuiteCRM, SugarCRM, vTiger, EspoCRM, Dolibarr and webERP.
• Invoicing, billing and accounts software such as Invoice Ninja, Akaunting, SolidInvoice, WHMCS, Blesta and HostBill.
• Risk and compliance tools such as SimpleRisk, which hold exactly the information an attacker would want.
• Self-hosted password managers such as Passbolt and TeamPass, which deserve top priority because of what they protect.
• Analytics, survey and project tools such as Matomo, LimeSurvey, Kanboard and MantisBT.

Identity, single sign-on and directory tools

• SimpleSAMLphp, widely used as a SAML single sign-on identity provider or service provider, and OpenConext EngineBlock, which runs federated login services such as SURFconext.
• Directory and account management tools such as phpLDAPadmin.

Put these near the top of the list. A compromised single sign-on server can give an attacker a route into every application that trusts it.

File sharing, NAS and storage

• Nextcloud and ownCloud's classic server, plus file transfer tools such as ProjectSend, FileSender and PrivateBin.
• NAS systems with a PHP admin interface, such as OpenMediaVault and Unraid.
• QNAP NAS units running QTS or QuTS hero, which include a built-in PHP runtime as part of the operating system.
• Synology NAS units using Web Station with any of Synology's PHP packages, which span PHP 5.6 to 8.4. Those packages also power other Synology apps, including Note Station and Synology Calendar.

CCTV, building systems and small devices

• PHP-based camera and recording systems such as ZoneMinder.
• Mainstream CCTV brands such as Hikvision and Dahua. We found no statement from either, and neither appeared on the Dutch NCSC's product list at our last check. That is not confirmation that their cameras and recorders are safe, so keep them off the internet and on current firmware. The PHP servers you run alongside CCTV, such as remote viewing portals, ZoneMinder and access control systems, are exposed either way.
• Access control, visitor management, digital signage and room booking systems with a PHP web interface, often supplied as a ready-made appliance or virtual machine.
• Raspberry Pi and other small Linux devices running PHP dashboards, including older Pi-hole installations, whose admin page used PHP before version 6.

Windows, cloud and container platforms

• Windows servers running PHP under IIS, and development stacks such as XAMPP, WampServer and Laragon.
• Docker and Kubernetes workloads built on PHP images, including the official php, wordpress and nextcloud images.
• Managed platforms such as Azure App Service, AWS Elastic Beanstalk and Google App Engine. Check the provider's notices and redeploy or restart onto the patched runtime.
• Vendor software that quietly bundles its own php.exe or php-cgi.exe.
• Serverless and platform-as-a-service PHP, such as Bref on AWS Lambda, Heroku's PHP buildpack, Pantheon and Laravel Cloud.
• Developer and build tools such as PHPUnit, PHPStan and PHP CS Fixer. These run PHP on the command line, which is lower risk, but update CI and build images too.

What manufacturers and vendors have said so far

Checked 21 October 2026, 22:43 UTC. The Dutch NCSC is tracking more than 600 PHP-dependent products from over 400 suppliers in its php2shell product list, and most are still under investigation. These are the statements we have found from brands our customers commonly use, drawn from vendor advisories, the Dutch list and Cyber Kendra's vendor roundup.

• Sophos: Not affected. Sophos says none of its products are affected. Its legacy MyUTM licensing portal for end-of-life SG UTM ran an affected PHP version and was taken offline on 21 October for updating.
• OPNsense: Patched. Hotfixes released on the evening of 21 October: Community Edition 26.7.7 with PHP 8.5.12, and Business Edition 26.4.2p3 with PHP 8.3.36.
• Netgate pfSense: Reported patched (22 October). Netgate's legacy web interface is written in PHP; the newer pfSense Plus interface is written in Go. pfSense CE 2.9.0 and Plus 26.07 have been reported as updated to PHP 8.5.12. Install the latest pfSense update and check Netgate's own advisory to confirm.
• Palo Alto Networks: Affected, no fix date yet. Its advisory lists all PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 versions and Panorama as affected, with fixes still to be scheduled. Cloud NGFW, Prisma Access, the GlobalProtect app and the Cortex products are not affected, and Palo Alto is not aware of exploitation against its products. Restrict the PAN-OS and Panorama management interfaces to trusted internal addresses now, ideally a dedicated jump box. Customers with Threat Prevention can use Threat ID 543004, released on 20 October, to help protect PHP servers behind the firewall.
• Citrix NetScaler: Affected. NetScaler says all supported versions are impacted because the NetScaler management portal uses PHP, while NetScaler Console and SVM are not. Its immediate advice is to restrict GUI and API access on the NSIP, management-enabled SNIPs and the cluster IP to trusted admin hosts. Citrix plans to release fixes for all supported NetScaler versions on 27 October 2026.
• F5: BIG-IP affected. F5's advisory K000163821 lists the BIG-IP Configuration utility as affected, rated High, while F5 Distributed Cloud is not vulnerable. F5 has also published WAF signatures that protect PHP servers behind BIG-IP Advanced WAF, ASM or NGINX App Protect.
• Fortinet: Mostly not affected, some products under investigation. Fortinet's advisory FG-IR-26-186 confirms that FortiOS, FortiManager, FortiAnalyzer, FortiWeb, FortiMail, FortiClient, FortiSASE, FortiAuthenticator, FortiSwitch and FortiNAC are not impacted. It is still investigating products including FortiADC, FortiClient EMS, FortiSIEM, FortiSOAR, FortiDDoS and FortiMonitor.
• Cisco: No affected products confirmed. Cisco's interim advisory, first published at 19:12 GMT on 21 October, says no products are currently known to be affected, with many, including Webex and Slido, under investigation.
• Synology: Fixed packages released (Synology-SA-26:14). Synology's advisory, published on 22 October, confirms PHP2Shell affects its PHP 7.3 to 8.4 packages, Synology Calendar and Mail Station, and lists the fixed package versions. PHP 7.3 is end-of-life and gets no fix, so move any site using it. DSM's own built-in PHP is command-line only and is not exposed through the management interface. Update through Package Center. Earlier, in a statement on 22 October, Synology said it is assessing which products and package versions are affected and preparing updates, which will be listed in its security advisories. It advises against exposing PHP-based websites or services directly to the internet and against manually replacing the PHP bundled with its products. Synology specialist Marius Hosting recommends disabling session upload progress in each Web Station PHP profile in the meantime.
• QNAP: No fix yet; take devices off the internet. QNAP has reportedly urged users to remove its devices from direct internet exposure immediately. QTS and QuTS hero include a built-in PHP runtime, and QNAP users point out on QNAP's own forum that the internal web server can only be patched by a firmware update. Until QNAP publishes one, keep QNAP units off the internet, including through port forwarding and remote-access services.
• Plesk: Affected, mostly patched. Plesk confirms every PHP version it ships for Linux and Windows is affected. Fixed builds are listed in the patch tracker below, and the panel's own PHP is fixed in hotfix 18.0.81 Update 4, which shipped late on 21 October.
• DirectAdmin: Patched, except the oldest versions. CustomBuild now offers PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus vendor-patched 7.4, 8.0 and 8.1. Patches for PHP 5.6 to 7.3 were still pending. Rebuild the hosted PHP to apply them.
• Sangoma FreePBX and PBXact: Under investigation. Version 17 of both runs on PHP 8.2; see the VoIP section above.
• VitalPBX: Guidance published. Install Debian 12's fixed PHP 8.2.35 package.
• Nextcloud: Affected through PHP. Deployments on affected PHP versions are vulnerable, and the All-in-One container rebuild was pending when reported.
• Bref (PHP on AWS Lambda): Affected. Its Lambda images were confirmed affected, with updates pending.
• Cloud platforms: Mostly patched. Google App Engine's standard PHP 8.2 and later runtimes were patched automatically, Azure App Service's built-in PHP images were fixed on two of its three release channels, and AWS Elastic Beanstalk shipped a patched PHP platform.
• No statement found yet: Hikvision, Dahua, Axis, Ubiquiti, Juniper, Ivanti, WatchGuard, SonicWall, Zyxel, DrayTek and Yamaha. None had published a statement at our check, and none appeared on the Dutch NCSC's list. That is not confirmation that they are unaffected, so check each vendor's security advisory page directly.

Software-as-a-service suppliers can be affected too. HR software company BambooHR took its service offline in the US, Canada and Ireland as a precaution. Ask the suppliers that hold your data whether their platforms run PHP and when they patched.

What is not affected, and how to find PHP on a Linux server

PHP that never answers web requests, such as command-line scripts and cron jobs, is outside PHP's at-risk list, and software with no PHP in it is not affected by this flaw at all. If you cannot tell whether something uses PHP, assume it does until the vendor tells you otherwise.

To find PHP on a Linux server, start with the package list: rpm -qa | grep -i php on Red Hat-based and CloudLinux systems, or dpkg -l | grep -i php on Debian and Ubuntu. Check for panel-installed versions under /opt/plesk/php, /opt/cpanel and /opt/alt, and see what is actually running with ps -eo user,args | grep -E 'php|httpd|apache2|lsphp'. Check appliances, containers and NAS boxes separately, because their PHP often does not show up in the host's package list.

Emergency checklist: how to fix PHP2Shell

Work through these steps in order, starting with your internet-facing servers.

1. Find every copy of PHP

   List every server, container and appliance running PHP, and every PHP version on each one. Hosting panels routinely install several versions side by side, and each needs the fix. Most servers also keep the operating system's own PHP alongside the versions that run the websites, so check both; the platform notes below explain where each one lives. Include staging sites, old servers left online after a migration, and the hosting panel itself.

2. Back up the server before you update

   Take a backup or snapshot before touching PHP, so you can roll back if the update fails or breaks a site. On a virtual server or VPS, a snapshot from your hosting or hypervisor console takes minutes and is the quickest safety net. Otherwise, back up the websites, databases and configuration files, including php.ini, PHP-FPM pool files and the web server configuration, plus the system's own backup on a phone system such as FreePBX. Check that the backup has actually completed before you start. If a full backup will take hours, apply the temporary mitigations below while it runs rather than leaving the server exposed.

3. Switch off PHP that no site uses

   Hosting servers often have dozens of PHP versions and handler types switched on that no website uses, and every one is another copy to patch and another way in. Turn off each PHP version or handler with no sites on it, and keep only what your sites actually run. On Plesk, Tools & Settings > PHP Settings shows how many domains use each handler; on cPanel, remove unused ea-php versions in EasyApache 4; on CloudLinux, disable unused versions in PHP Selector. Check that your hosting plans do not default to a handler you are switching off, and remember that turning a handler off stops sites using it but does not uninstall it.

4. Install the patched version

   Update each copy to the fixed release for its own version: 8.5.12 if it runs PHP 8.5, 8.4.27 for 8.4, 8.3.36 for 8.3 or 8.2.35 for 8.2. For PHP 8.1 and older, install your vendor's patched package. Linux distributions and hosting panels received the patches in advance, so use their packages where you can. The platform notes below cover Plesk, cPanel, Linux, Windows and containers.

5. Restart PHP and confirm the update took

   Restart PHP-FPM and the web server, then check the version the web server is actually running, not just the command-line PHP, which can differ. Vendors that backport fixes often keep the old version number, so check the build date or package release as well. With Apache mod_php, do a full restart: a reload or graceful restart leaves the old PHP running. On LiteSpeed, also end the lsphp processes with pkill lsphp, because restarting LiteSpeed does not restart them. Restart queue workers and other long-running PHP processes too. To prove nothing still runs the old PHP on Linux, run grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps: empty output means every process has loaded the new files.

6. Mitigate or go offline if you cannot patch yet

   Apply the temporary measures below, put the site behind a web application firewall, or take it offline. A short planned outage costs far less than a breach.

7. Check for compromise and change your secrets

   Attacks began before the patch existed, so look for signs of intrusion on every server that was exposed. If there is any doubt, change database passwords, API keys and admin credentials.

How long does a PHP2Shell fix take? The 30-minute patch versus the 2-hour fix

Two very different jobs are both being called "patched" this week. One takes about 30 minutes and closes the headline hole. The other takes about two hours per server and leaves the server genuinely secure. The difference matters, because the quick version often leaves attackers a way back in, and many servers have not had either yet: OX Security found that roughly 99% of the affected hosts whose PHP version it could identify were still not showing a patched version 24 hours after the release.

The 30-minute quick fix, and what it leaves behind

A quick fix usually means updating the one PHP package the engineer knows about, restarting a service and checking php -v. It is far better than nothing, but when it is done in a hurry or by an inexperienced engineer, it routinely misses:

• The other copies of PHP. The operating system's PHP gets updated while the separate versions that actually run the websites, the hosting panel's own PHP, alt-php versions or containers stay vulnerable, or the other way round.
• Old PHP versions. Unused and end-of-life versions are left installed and switched on, each one another unpatched way in.
• Kernel and other security updates. Only PHP is updated, so the server stays exposed to every other known flaw, and the reboot a new kernel needs never happens.
• A restart that actually loads the fix. An Apache reload or a LiteSpeed restart leaves the old, vulnerable PHP running in memory, even though php -v shows the new version.
• Any check for a break-in. Attacks began on 17 October, and a backdoor planted before the update survives it.
• New passwords and keys. PHP2Shell's memory leak can expose secrets without leaving a trace, so a server that was exposed needs its secrets changed even if it looks clean.
• Better protection. Firewall rules, web application firewall rules and antivirus are left as they were, and admin panels stay open to the internet.
• Testing. The new releases have known bugs, so skipping a check of the sites afterwards means customers find the problems first.

Why doing it properly takes about 2 hours

This is how a careful engineer typically spends around two hours on a single server. A simple server with one site can take less, and a busy hosting server with dozens of sites and several PHP versions can take considerably more.

1. Inventory and backup (about 10 minutes). Find every copy of PHP, every web server and every hosting panel on the server, then take a backup or snapshot so any update can be rolled back.
2. Compromise assessment before patching (about 30 minutes). Cloudflare saw millions of exploit attempts within a day of the leak, and Amazon recorded the first attempt on 17 October, so a proper fix starts by looking for an intruder: logs since 17 October, processes started by PHP, new files in web roots and temporary folders, and code that loads on every request. Patching first can destroy evidence and leaves any backdoor in place.
3. Patch every copy of PHP and run full system updates (about 20 minutes). Website PHP, operating system PHP, panel PHP and alt-php, plus the kernel and every other pending security update, using the vendor's own update tool.
4. Remove or switch off unused PHP (about 10 minutes). Switch off every handler with no sites on it, remove versions nobody needs, and check hosting plans do not default to them.
5. Restart properly and prove the fix is live (about 10 minutes). Fully stop and start Apache, restart every PHP-FPM pool, end the lsphp processes on LiteSpeed, restart queue workers, then confirm that no running process still uses the old PHP files.
6. Test sites and applications (about 15 minutes). Check that every site, checkout, form and admin area still works, watch the error logs, and look out for the known bugs in 8.4.27 and 8.5.12, such as crashes in code that uses SimpleXML.
7. Harden the server (about 15 minutes). Restrict hosting panels and admin interfaces to trusted IP addresses, confirm the web application firewall and antivirus rules are current (for example the Imunify360 ruleset), keep session upload progress switched off, and put a normal memory limit back if it was removed as a stopgap.
8. Reboot if needed, verify and record (about 10 minutes). Reboot for a new kernel, re-check versions and build dates, test exposure with a reputable scanner such as Searchlight Cyber's php2shell-scanner or a Qualys or Tenable scan rather than exploit code found online, and record what was done and when.

If your team or provider is taking around two hours per server, they are working with the care a 9.2-rated remote code execution flaw deserves. Rushing a runtime patch tends to end one of two ways: broken sites, or a server that reports the new version while an attacker's backdoor carries on working untouched.

What fixing every PHP server could cost

Nobody knows exactly how many PHP servers there are. Internet scans only see servers that reveal their PHP version, which is why measured counts vary so widely: Palo Alto Networks counted 22.6 million exposed instances potentially vulnerable to PHP2Shell, while VulnCheck identified around 1.5 million hosts whose PHP version it could read. Counting servers inside company networks, hosting platforms and devices, we have taken a working estimate of around 110 million PHP servers worldwide, an assumption rather than a measured figure, and not including firewalls, NAS units, phone systems and other appliances.

Assuming an average of one hour of engineer time per server (a mix of quick fixes, proper fixes and automated platforms) and an average engineer cost of £50 an hour:

• 110 million hours of work, or roughly 55,000 engineer-years. Even 100,000 engineers working full time would need around six months to get through it.
• About £5.5 billion in engineer time at £50 an hour, or roughly £3.3 billion to £8.8 billion at £30 to £80 an hour.
• About £2.75 billion if every server only got the 30-minute quick fix, and about £11 billion if every server got the full 2-hour fix.
• About £1.1 billion even on the most conservative measured figure, Palo Alto's 22.6 million exposed instances, at one hour each.

These figures leave out the cost of investigating and cleaning up servers that were breached, replacing stolen credentials, downtime and lost sales while sites were offline, and patching the appliances that bundle PHP. They also show why many servers will stay unpatched for months: there is simply not enough engineer time to go round, and attackers know it.

PHP2Shell patch tracker: which Linux systems have a fix (updated daily)

Last checked: 23 October 2026, 20:00 UTC (21:00 UK time). We are re-checking this list every day and recording the date and time each new patch appears, so you can see exactly when a fix for your system became available and whether one exists at all. All times are UTC. "Published" is the vendor's own release time. "Confirmed by" means the fix was live on the vendor's advisory or repository by that time, where the vendor gave no exact release time. Times come from vendor advisories, errata and repositories, cross-checked against Digital Applied's timestamped distribution tracker.

How to read it: Patched means the vendor has released a fixed package. Partly patched means some PHP versions on that system are fixed and others are not. In testing means the fix is only in a testing channel. Pending means the vendor lists the system as affected with no fix released. No fix planned means the vendor has said it will not fix it. Many fixed packages keep an older PHP version number, so compare the full package version listed here with yours, not just the output of php -v.

Debian

• Debian 13 trixie (PHP 8.4): Patched. php8.4 8.4.27-1~deb13u1 (DSA-6574-1). Published 21 Oct 2026, 13:45 UTC.
• Debian 12 bookworm (PHP 8.2): Patched. php8.2 8.2.35-1~deb12u1 (DLA-4848-1). Published 21 Oct 2026, 14:11 UTC.
• Debian 11 bullseye (PHP 7.4): Patched through Freexian's Extended LTS. php7.4 7.4.33-1+deb11u14 (ELA-1853-1). Dated 21 Oct 2026, confirmed by 21:55 UTC.
• Debian 10 buster (PHP 7.3): Patched through Freexian's Extended LTS. php7.3 7.3.31-1~deb10u16 (ELA-1854-1). Dated 21 Oct 2026, confirmed by 21:55 UTC.
• Debian 9 stretch (PHP 7.0): Patched through Freexian's Extended LTS. php7.0 7.0.33-0+deb9u26 (ELA-1855-1). Dated 21 Oct 2026, confirmed by 21:55 UTC.
• Debian testing (forky) and unstable (sid): Pending. Still listed as vulnerable at 20:23 UTC on 21 Oct 2026.

Ubuntu

• Ubuntu 26.10 (PHP 8.5): Patched. 8.5.9-0ubuntu2.1 (USN-8948-1). Published 21 Oct 2026.
• Ubuntu 26.04 LTS (PHP 8.5): Patched. 8.5.4-0ubuntu1.5 (USN-8948-1). Published 21 Oct 2026.
• Ubuntu 24.04 LTS (PHP 8.3): Patched. 8.3.6-0ubuntu0.24.04.13 (USN-8948-1). Published 21 Oct 2026. The version still reads 8.3.6; the fix is in the package revision.
• Ubuntu 22.04 LTS (PHP 8.1): Patched. 8.1.2-1ubuntu2.28 (USN-8948-1). Published 21 Oct 2026.
• Ubuntu 20.04 (PHP 7.4): Patched, Ubuntu Pro only. 7.4.3-4ubuntu2.29+esm5 (USN-8948-2). Published 21 Oct 2026.
• Ubuntu 18.04 (PHP 7.2): Patched, Ubuntu Pro only. 7.2.24-0ubuntu0.18.04.17+esm14 (USN-8948-2). Published 21 Oct 2026.
• Ubuntu 16.04 (PHP 7.0): Patched, Ubuntu Pro Legacy only. 7.0.33-0ubuntu0.16.04.16+esm22 (USN-8948-2). Published 21 Oct 2026.
• Ubuntu 25.04 and 25.10 (PHP 8.4): No fix planned. Both releases are end-of-life, so no fix is coming. Upgrade to Ubuntu 26.04 LTS.
• Ubuntu 14.04 (PHP 5.5): Patched, Ubuntu Pro Legacy only. 5.5.9+dfsg-1ubuntu4.29+esm18 (USN-8948-2). Published 21 Oct 2026.

According to Canonical, unattended upgrades will install these within 24 hours on most servers, but PHP and the web server still need restarting before the fix takes effect.

Ondřej Surý's PHP packages (Debian and Ubuntu)

• Debian 13 and 12, PHP 8.5 to 8.2: Patched. Upgraded to 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Confirmed by 20:26 UTC, 21 Oct 2026.
• Debian 13 and 12, PHP 8.1 down to 5.6: Patched by backport. Old version numbers kept, with a 20261021 date stamp in the package version. Confirmed by 20:27 UTC, 21 Oct 2026.
• Ubuntu 24.04 and 22.04 (ondrej/php PPA), PHP 8.5 to 7.4: Patched. Confirmed by 20:27 UTC, 21 Oct 2026. The PPA had no Ubuntu 26.04 packages at that time.

Red Hat Enterprise Linux

• RHEL 10, PHP 8.3 (default): Patched. php-8.3.36-1.el10_2 (RHSA-2026:87070). Confirmed by 20:26 UTC, 21 Oct 2026.
• RHEL 10, PHP 8.4: Patched. php8.4-8.4.27-1.el10_2 (RHSA-2026:87071). Confirmed by 20:26 UTC, 21 Oct 2026.
• RHEL 9, PHP 8.0 (default): Patched, version number unchanged. php-8.0.30-8.el9_8.1 (RHSA-2026:87151). Confirmed by 20:26 UTC, 21 Oct 2026.
• RHEL 9, php:8.2 module: Patched. php-8.2.35-1.module+el9.8.0+25111+a1450321 (RHSA-2026:87072). Published by 20:35 UTC, 21 Oct 2026.
• RHEL 9, php:8.3 module: Patched. php-8.3.36-1.module+el9.8.0+25109+6886e21a (RHSA-2026:87079). Published by 20:36 UTC, 21 Oct 2026.
• RHEL 9, php:8.4 module: Pending. Still listed as affected at 21:49 UTC, 21 Oct 2026.
• RHEL 8, php:7.4 module: Patched, version number unchanged. php-7.4.33-8.module+el8.10.0+25117+30337cca (RHSA-2026:87080). Published 15:53 UTC, 21 Oct 2026.
• RHEL 8, php:8.2 module: Pending. Still listed as affected at 21:49 UTC, 21 Oct 2026.
• RHEL 8, php:7.2 default stream: No fix planned. This stream was retired in 2021 and gets no fixes, yet a plain dnf install php on RHEL 8 still installs it. Move to a supported stream. AlmaLinux did patch its own 7.2 stream (see below).
• RHEL 7 and older: Not affected, according to Red Hat. Red Hat's bulletin RHSB-2026-013, updated at 21:08 UTC, says the PHP these releases ship is not affected. That covers only the operating system's own PHP; newer PHP added from Software Collections, Remi or a control panel must be checked separately.

AlmaLinux

• AlmaLinux 8, php:7.4: Patched. Rebuild of Red Hat's fix, in the production repositories by 20:31 UTC, 21 Oct 2026.
• AlmaLinux 8, php:7.2, 7.3, 8.0 and 8.2: Patched. In production from 21:15 UTC, 21 Oct 2026. Package versions end in .alma.1.
• AlmaLinux 9, default PHP 8.0 and php:8.1, 8.2 and 8.3: Patched. In production from 21:15 UTC, 21 Oct 2026. These keep older version numbers, for example php-8.3.33 with an .alma.1 suffix.
• AlmaLinux 10, default PHP 8.3 and php8.4: Patched. In production from 21:15 UTC, 21 Oct 2026.
• AlmaLinux Kitten 10: Pending. The fix is due with its next regular PHP update.

Rocky Linux and Oracle Linux

• Rocky Linux 8, 9 and 10: Patched. Rebuilds of Red Hat's fixes synced overnight to 22 Oct 2026: RLSA-2026:87070 and 87071 (Rocky 10), RLSA-2026:87151, 87072 and 87079 (Rocky 9) and RLSA-2026:87080 (Rocky 8, php:7.4). Nothing had been published at 20:32 UTC on 21 Oct. The security-only update list may not show these, so run a full dnf upgrade. Streams Red Hat has not fixed yet, such as RHEL 8 php:8.2 and RHEL 9 php:8.4, are also still pending on Rocky.
• Oracle Linux: No patch found yet. We found no Oracle Linux errata at our 17:43 UTC check on 22 Oct 2026. Oracle Linux 6 and 7 can get a fix through TuxCare (below).

CentOS and TuxCare Extended Lifecycle Support

• Patched through TuxCare by 20:18 UTC, 21 Oct 2026: RHEL 7, Oracle Linux 6 and 7, CentOS 8.4, CentOS 8.5, CentOS Stream 8, Amazon Linux 2, AlmaLinux 9.2 and 9.8 ESU, TuxCare 9.6 and 9.8 ESU, Ubuntu 16.04, 18.04 and 20.04 ELS, and Alpine 3.18 ELS.
• Releasing through TuxCare at 20:18 UTC, 21 Oct 2026: CloudLinux 7 and Debian 11 ELS.
• Pending through TuxCare (listed as next): CentOS 6, CentOS 7, Debian 10 ELS and PHP for Windows.
• CentOS 7 and 6 without ELS: No patch. These have been end-of-life for years and receive nothing from the CentOS project. Red Hat says RHEL 7's own PHP is not affected, but any newer PHP on these servers needs ELS packages or a migration.

CloudLinux

• alt-php: Partly patched; check each package. CloudLinux says its first fixed alt-php packages were released at about 19:00 UTC on 21 Oct 2026, starting with 7.4 and 8.0 on most platforms and 8.1 on some. CloudLinux's status page, updated at 20:18 UTC, listed fixed alt-php packages for CloudLinux 6 to 10 and other systems, with alt-php 8.5 due by about 22:30 UTC. A CloudLinux correction at 21:45 UTC, reported by Digital Applied, says those builds went to TuxCare's ELS alt-php repository, that fixed alt-php was not yet in the standard CloudLinux 7, 8 and 9 repositories, and that only alt-php 7.4 was confirmed on CloudLinux 10. Until this settles, check each alt-php package's changelog for the CVE numbers. On a CloudLinux 7 server we manage, alt-php 5.2 to 8.1 were rebuilt between 19:39 and 20:28 UTC on 21 Oct 2026, and the alt-php 7.4 changelog lists both CVEs.
• ea-php for cPanel on CloudLinux: Patched. Released to stable at 20:55 UTC, 21 Oct 2026, for ea-php52 to ea-php85 as backports, so version numbers do not change (for example ea-php74 7.4.33-18.elX.cloudlinux.13).
• Imunify360 firewall: interim protection only. Rulesets 8.83 (09:08 UTC), 8.84 (13:07 UTC) and 8.85 (17:17 UTC) delivered automatically to servers with the WAF enabled.

Amazon Linux and AWS

• Amazon Linux 2023 (PHP 8.2 to 8.5): Patched. php8.2 8.2.35, php8.3 8.3.36, php8.4 8.4.27 and php8.5 8.5.12 (release -1.amzn2023.0.1) in ALAS2023-2026-3301 to 3304, released 22 Oct 2026. Amazon Linux 2023 locks packages to a release, so follow the advisory's dnf upgrade --releasever command. These were still "Pending Fix" at 20:38 UTC on 21 Oct.
• Amazon Linux 2 (PHP 8.2 extra): Patched. ALAS2PHP8.2-2026-015, released 22 Oct 2026.
• Amazon Linux 2023 PHP 8.1 and Amazon Linux 2 core PHP: No fix planned. Amazon lists both as "No Fix Planned". Amazon Linux 2 can get a fix through TuxCare.
• AWS Elastic Beanstalk: Patched. PHP platform v4.13.12 shipped on 21 Oct 2026. Lightsail blueprints were due the same day.

SUSE and openSUSE

• SUSE Linux Enterprise 15 SP7 (Web and Scripting module): Patched. php8 8.3.36-150700.3.24.1. Confirmed by 20:38 UTC, 21 Oct 2026.
• SUSE Linux Enterprise Server 16.0: In testing. php8 8.4.27-160000.1.1 in QA at 20:38 UTC, 21 Oct 2026.
• openSUSE Leap 15.4 to 15.6 and 16.x, SLE 15 SP4 to SP6 LTSS and the php7 packages: Pending. Listed as affected at 20:38 UTC, 21 Oct 2026.

Fedora, Alpine and other distributions

• Fedora 46 and 44: Patched. php-8.5.12-1, stable from 15:31 and 16:43 UTC, 21 Oct 2026.
• Fedora 45 and 43: Pending. php-8.5.12-1.fc45 and php-8.4.27-2.fc43 awaiting stable release at 20:38 UTC, 21 Oct 2026.
• Alpine edge and 3.24: Patched. php83 8.3.36-r0, php84 8.4.27-r0 and php85 8.5.12-r0. Confirmed by 20:36 UTC, 21 Oct 2026.
• Alpine 3.21, 3.22 and 3.23: No patch yet. No fixed packages at 20:36 UTC, 21 Oct 2026. Alpine 3.18 is patched through TuxCare.
• Arch Linux: Patched. php 8.5.12-1 in the Extra repository, reported 21 Oct 2026.
• Gentoo: Advisory issued. GLSA 202610-02, reported 21 Oct 2026.
• Remi repository (RHEL, AlmaLinux and Rocky): Partly patched. Free fixes for the end-of-life PHP 7.4, 8.0 and 8.1 are out (for example php 8.0.30-21, built 21 Oct 2026), with 7.2 and 7.3 to follow, according to Sansec's update on 22 Oct 2026. Nothing had been published at 20:38 UTC on 21 Oct. Check Remi's blog for the supported branches.

Control panels

• cPanel EasyApache 4 v25.91: Patched. ea-php82 to ea-php85 updated to the fixed releases, with ea-php74, 80 and 81 backported. Confirmed by 20:35 UTC, 21 Oct 2026.
• cPanel's own internal PHP: Patched in cPanel & WHM 138.0.18, 136.0.50, 134.0.66 and 110.0.153. Confirmed by 20:35 UTC, 21 Oct 2026.
• Plesk PHP 8.2 to 8.5 (Linux and Windows): Patched. Listed in Plesk's change log on 21 Oct 2026.
• Plesk PHP 7.4, 8.0 and 8.1: Patched. Same version numbers, with a build date of 21 Oct 2026.
• Plesk panel's own PHP (sw-engine): Patched. Plesk Obsidian 18.0.81 Update 4, built at 21:00 UTC on 21 Oct 2026, confirmed installed on a server we manage, with the panel running PHP 8.4.27. Nothing was in Plesk's change log at our check earlier that evening.
• DirectAdmin CustomBuild: Patched, except PHP 5.6 to 7.3. PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus vendor-patched 7.4, 8.0 and 8.1, listed as fixed on the Dutch NCSC's product list at our 22:43 UTC check on 21 Oct 2026. Nothing had been published at 20:34 UTC. Hosted PHP must be rebuilt to apply the fix.

Firewalls and NAS systems

• Palo Alto PAN-OS 10.2 to 12.2 and Panorama: Pending. Affected, fix date to be confirmed, per Palo Alto's advisory on 22 Oct 2026.
• Citrix NetScaler (all supported versions): Pending, fix planned for 27 Oct 2026. Affected through the management portal; restrict management access until then.
• F5 BIG-IP Configuration utility: Pending. Affected per F5 advisory K000163821.
• Fortinet: Partly confirmed. FortiOS and most core products not impacted; FortiADC, FortiClient EMS, FortiSIEM, FortiSOAR and others under investigation (FG-IR-26-186, published 21 Oct 2026).
• OPNsense: Patched. Community Edition 26.7.7 (PHP 8.5.12) and Business Edition 26.4.2p3 (PHP 8.3.36), released on the evening of 21 Oct 2026.
• pfSense: Reported patched. CE 2.9.0 and Plus 26.07 reported as updated to PHP 8.5.12 by the morning of 22 Oct 2026 (Japan time). Under investigation at our 22:43 UTC check on 21 Oct 2026.
• Synology PHP packages, Synology Calendar and Mail Station: Patched. Fixed versions listed in Synology-SA-26:14, published 22 Oct 2026; PHP 7.3 gets no fix. Synology had only issued a holding statement earlier that day.
• QNAP QTS and QuTS hero: Pending. No announcement by the morning of 22 Oct 2026.

Containers and Windows

• Docker official php images: Patched. Tags for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 rebuilt from about 17:20 UTC, 21 Oct 2026. No PHP 8.1 or older tags are maintained.
• FrankenPHP: Patched in v1.13.2, released 18:19 UTC, 21 Oct 2026.
• Windows builds from php.net, PHP 8.2 to 8.5: Patched. Available by 13:49 UTC, 21 Oct 2026. There are no new Windows builds for PHP 7.4, 8.0 or 8.1.

PHP2Shell tracker change log

• 23 October 2026, 20:00 UTC: PHP disclosed a third flaw, CVE-2026-115560, to be fixed in its next regular release (mitigated by turning off session upload progress). Synology patched (SA-26:14). Citrix NetScaler fixes scheduled for 27 Oct. Still no fixed PAN-OS or Panorama. Still no confirmed PHP2Shell compromise and no CISA KEV listing. No new Linux distribution fixes found for Oracle Linux, the RHEL 8 php:8.2 and RHEL 9 php:8.4 modules, Alpine 3.21 to 3.23 or openSUSE at this check.
• 22 October 2026, 17:43 UTC (evening): Rocky Linux 8, 9 and 10 patched overnight. Amazon Linux 2023 (PHP 8.2 to 8.5) and Amazon Linux 2 (PHP 8.2 extra) patched. Remi partly patched (EOL 7.4, 8.0 and 8.1). Dutch NCSC investigating first signs of successful misuse. Neither CVE in CISA KEV at the latest checks. Still waiting: Oracle Linux, the RHEL 8 php:8.2 and RHEL 9 php:8.4 modules, Alpine 3.21 to 3.23, openSUSE, Palo Alto, Citrix, F5, Synology and QNAP.
• 22 October 2026, 09:09 UTC: Added Palo Alto PAN-OS and Panorama, Citrix NetScaler and F5 BIG-IP (all affected, fixes pending) and Fortinet's product list. Synology issued a holding statement. Known regressions in 8.4.27 and 8.5.12 noted in the latest updates.
• 22 October 2026, 09:04 UTC: Amazon now reports broad exploitation in the wild, with a first attempt on 17 October; Cloudflare reports millions of attempts. Plesk panel hotfix 18.0.81 Update 4 confirmed shipped (built 21:00 UTC, 21 Oct). CloudLinux 7 alt-php fixes confirmed on a live server. pfSense reported patched. Added Ubuntu 25.04 and 25.10 (end-of-life, no fix) and RHEL 8's retired php:7.2 stream (no fix). QNAP and Synology still silent. Still waiting: Rocky Linux, Oracle Linux, Amazon Linux 2023, the RHEL 8 php:8.2 and RHEL 9 php:8.4 modules, Alpine 3.21 to 3.23, openSUSE and Remi.
• 21 October 2026, 22:43 UTC: DirectAdmin now patched, except PHP 5.6 to 7.3. OPNsense hotfixes released. Added firewall and NAS systems: pfSense, Synology and QNAP still have no fix.
• 21 October 2026, 22:37 UTC: tracker started. The first fixes appeared at 13:45 UTC (Debian 13) and 13:49 UTC (Windows builds), just ahead of PHP's 14:00 UTC release. Still waiting at this check: Rocky Linux, Oracle Linux, Amazon Linux 2023, the RHEL 8 php:8.2 and RHEL 9 php:8.4 modules, CloudLinux's standard alt-php repositories, Alpine 3.21 to 3.23, openSUSE, Remi, DirectAdmin and the Plesk panel hotfix.

PHP2Shell update notes for Plesk, cPanel, Linux and Windows

The right update route depends on where your PHP came from. This is what the main platforms had released by the evening of 21 October; check each vendor's advisory for the latest position.

Operating system PHP and website PHP are often different

Many servers have more than one PHP, and it is easy to patch the wrong one. There is usually the operating system's own PHP, installed from the Linux distribution's packages and used by the php command, cron jobs and some system tools. Then there are the separate PHP versions that actually run the websites, installed by a hosting panel or an extra repository and kept in their own folders. Updating one does not update the other, and running php -v on the command line usually shows only the operating system's copy, not the versions your sites use.

• Plesk installs its own PHP versions under /opt/plesk/php/, can also offer the operating system's PHP to sites as an "OS vendor" handler, and has a third copy for the control panel itself. Run plesk bin php_handler --list to see every handler on the server.
• cPanel runs websites on EasyApache's ea-php versions under /opt/cpanel/, separate from any PHP the operating system provides. WHM's MultiPHP Manager shows which version each site uses.
• CloudLinux adds alt-php versions under /opt/alt/, chosen per site through PHP Selector, on top of the panel's and the operating system's PHP.
• Debian and Ubuntu servers using Ondřej Surý's packages can have several versions side by side, such as php7.4, php8.2 and php8.3, each with its own PHP-FPM service.
• Red Hat-based servers using Remi's repository may run websites on separately installed versions under /opt/remi/ as well as the system PHP.
• LiteSpeed servers run websites on lsphp builds kept apart from the operating system's PHP.

Update every copy, starting with the versions that serve websites, and update the operating system's PHP too even if no site uses it. Then confirm each version separately, ideally with a test page served by that version, because the command line can report a different copy that is already up to date. Delete any test page as soon as you have checked it.

Plesk

• According to Plesk's advisory, fixed builds of PHP 8.2 to 8.5 are available for both Linux and Windows.
• Plesk's patched builds of the end-of-life PHP 7.4, 8.0 and 8.1 keep their old version numbers (7.4.33, 8.0.30 and 8.1.34) but carry a build date of 21 October 2026. Check the build date, not just the number.
• The Plesk control panel runs on its own copy of PHP, called sw-engine, which is also affected. Plesk fixes it in hotfixes 18.0.80#11 and 18.0.81#4, and 18.0.81 Update 4 shipped late on 21 October (built at 21:00 UTC). Check your Plesk version, and until your server shows one of those updates, restrict access to the Plesk panel to trusted IP addresses.
• Install updates from the Plesk interface or over SSH with plesk installer update. Check each PHP handler with, for example, /opt/plesk/php/8.3/bin/php -v, and the panel's own PHP with /usr/local/psa/admin/bin/php -v.
• For PHP 5.6, 7.2 and 7.3, Plesk points customers to paid TuxCare Extended Lifecycle Support.

cPanel and WHM

• cPanel's patched ea-php74 to ea-php85 packages ship in EasyApache 4 v25.91. That covers PHP 8.2 to 8.5 plus backported fixes for PHP 7.4, 8.0 and 8.1, as GoDaddy reports.
• According to InMotion Hosting, ea-php 7.3 and older will not get a fix on cPanel servers without CloudLinux. Move those sites to a supported version.
• Update through WHM's EasyApache 4 screen or your package manager, for example dnf upgrade 'ea-php*' (yum on older systems), then restart PHP-FPM and Apache.

CloudLinux and LiteSpeed

• CloudLinux servers often run several alt-php versions chosen per site through PHP Selector. Every installed alt-php version needs updating, not just the system default.
• CloudLinux's status page announced fixed alt-php packages on the evening of 21 October, but a later CloudLinux correction says many of those builds went to TuxCare's ELS repository rather than the standard CloudLinux 7, 8 and 9 repositories. See the patch tracker above for the current position, update with yum update alt-php* (or apt upgrade on Ubuntu and Debian), and check each package's changelog for the CVE numbers to confirm you are covered.
• Run a normal update, not a security-only one. CloudLinux warns that commands such as yum --security and dnf updateinfo will not list these packages until its security advisory data is published.
• Servers with Imunify360 and its web application firewall enabled are receiving blocking rules and IP reputation challenges automatically. CloudLinux and Imunify both describe these as a stopgap, not a fix.
• LiteSpeed is on PHP's list of affected setups. Update the lsphp builds your server uses, restart LiteSpeed, and end the running lsphp processes with pkill lsphp, because restarting LiteSpeed does not restart them.

Debian and Ubuntu

• Ubuntu's own security packages are out, as are Ondřej Surý's widely used PHP packages, which also backport the fix to PHP 8.1 and older.
• Run apt update && apt upgrade, then restart your PHP-FPM service (for example systemctl restart php8.3-fpm) and Apache or nginx. Distribution packages often keep the original PHP version and add a package suffix, so compare the package version with your distribution's security notice.

Red Hat, AlmaLinux and Rocky Linux

• If you install PHP from Remi's repository, PHP warned that it would not have updates on 21 October. Switch to your distribution's packages or build from source until Remi catches up.

Windows servers

• Patched Windows builds of PHP 8.2 to 8.5 are on the php.net downloads page. Replace the PHP folder, then recycle the IIS application pools or restart the service so the new files load.
• Look for business software that bundles its own php.exe or php-cgi.exe. It needs an update from that software's vendor.

Docker and containers

• Rebuild your images from a patched PHP base image and redeploy them. Restarting a container that still uses the old image changes nothing.

PHP 8.1 and older

• The PHP project no longer issues releases for these versions, but given the severity it has published minimal source backports for PHP 7.4, 8.0 and 8.1. Hosting panels and Linux vendors are also shipping backported builds.
• For older operating systems, TuxCare's Extended Lifecycle Support has released fixed distribution PHP for RHEL 7, Oracle Linux 6 and 7, CentOS 8.4 and 8.5, CentOS Stream 8, Amazon Linux 2 and older Ubuntu releases, with CentOS 6 and 7 and Debian 10 next.
• Use a backport if you must, but treat it as a stopgap and plan the upgrade. Bear in mind that PHP 8.2 itself reaches end of life on 31 December 2026.

If you cannot update PHP today: temporary mitigations

These measures come from PHP's own advisory and from incident responders. Each one closes a known attack path, not every path, so use them to buy hours rather than weeks. watchTowr warns that changes to .ini files should not be relied on to prevent exploitation, and PHP is clear that updating is the only complete fix.

• Turn off session upload progress. Set session.upload_progress.enabled = 0 in php.ini, or add php_admin_flag[session.upload_progress.enabled] = off to each PHP-FPM pool, then restart every worker. Setting it with ini_set() or a .user.ini file happens too late to help. Keep it off even after patching: it also blocks CVE-2026-115560, a related flaw PHP disclosed on 23 October that the current releases do not fix, and PHP suggests leaving it off until its next regular release.
• Remove PHP's memory limit, but cap the server. Enforce memory_limit = -1 at server level, using php_admin_value in the FPM pool or Apache configuration so sites cannot put a limit back. Keep post_max_size low (8M where uploads are not needed, 32M where they are) and use a container or cgroup memory limit instead. Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable path. Watch memory closely, because a single request can now use all of it. Once the fix is installed, put a normal memory_limit back: the fixed PHP's new hard limit is calculated from memory_limit, so leaving it at -1 removes both limits.
• On PHP 8.5, disable fatal error backtraces. Set fatal_error_backtraces = 0 and restart every worker.
• Block multipart form uploads at the web server if your site can live without them. Sansec notes that every known trigger is a multipart/form-data request, so rejecting these in nginx or Apache removes the known routes in, at the cost of breaking file uploads and some forms. Test your contact forms and checkout afterwards.
• Put a web application firewall in front. Cloudflare has deployed emergency rules against known PHP2Shell techniques for all customers, including free plans, and Imunify360 has pushed new rules to servers with its firewall enabled (see how to check your Imunify360 ruleset below). On AWS WAF, Amazon recommends the SizeRestrictions_BODY rule in the core rule set against CVE-2026-109618, and F5 has published signatures for BIG-IP Advanced WAF, ASM and NGINX App Protect. Treat any firewall rule as a temporary shield, not a fix.
• Clean up per-site PHP settings. Invalid or deprecated values set per request in .htaccess files or PHP_VALUE parameters can feed the second flaw. Hiding errors does not help; correcting the settings does.
• Go offline or read-only. If none of this is practical, follow the NCSC's advice and take the system offline until it is patched. WordPress and Magento maintenance modes do not help, because PHP processes the request before the application checks the maintenance flag.

How to check whether a PHP server has already been compromised

Patching closes the door, but it does not evict anyone who got in first. Amazon recorded the first exploit attempt on 17 October and recommends investigating from that date, so check logs, files and accounts back to 17 October, not just since you patched. A quick start is find /var/www -name "*.php" -newermt 2026-10-17, which lists PHP files created or changed since then (adjust the path to your web root). On any server that was exposed before it was patched, look for:

• PHP worker processes such as php-fpm, php-cgi, httpd or apache2 starting shells, Python or Perl, or download tools such as curl, wget and nc
• command lines containing reverse-shell patterns such as /dev/tcp/, mkfifo or fsockopen, and reconnaissance commands like whoami, id and uname -a run by the web server user
• new or recently changed PHP files in web roots, upload folders and temporary directories
• new cron jobs, scheduled tasks, SSH keys or system users, and new admin accounts in WordPress, Magento or your hosting panel
• PHP settings that load extra code on every request, such as an unexpected auto_prepend_file or auto_append_file setting or a new .user.ini file, and WordPress must-use plugins you did not install
• unexpected outbound connections from the web server, and sudden spikes in outgoing email.

Huntress highlights PHP launching processes it never normally would as the clearest sign of exploitation. Florian Roth's free process-watcher tool can alert on exactly that on Linux servers that have no endpoint detection. If you find anything, isolate the server, preserve the web server and PHP logs before changing anything, and treat every password and key stored on that server as stolen: database passwords, API keys, mail logins, WordPress salts, SSH keys and TLS certificates. The NCSC recommends an NCSC-assured incident response provider for UK organisations that are not confident handling it themselves, and our cyber security helpline is there if you think you have been breached.

Be wary of PHP2Shell "checker" scripts circulating online. JFrog has flagged fake proof-of-concept code around the disclosure, and running unknown code on a production server is the last thing you need this week.

Check your PHP2Shell exposure with our free osir.co.uk tools

We run two free tools on osir.co.uk, our free online tools site, that help with incidents like this one.

Cyber Threat Monitor shows what attackers are exploiting right now: the newest entries on CISA's Known Exploited Vulnerabilities list with ransomware flags, the week's critical CVEs and the latest UK NCSC advisories, refreshed several times a day. The NCSC's PHP alert is already on it, and if CISA adds PHP2Shell to its exploited list, it will show up there too.

Website Health check runs more than 170 safe external checks on any site you own or look after. For PHP2Shell, the useful parts are the PHP version your server gives away in its responses (flagged if it is past end of life), the known vulnerabilities Shodan has already matched to software on your server's IP address, control panels such as Plesk and phpMyAdmin left open to the internet, and leftover backups, .env files and database dumps that attackers go straight for after a breach.

An outside scan cannot see inside your server. Many servers hide their PHP version, and backported fixes often keep the old version number, so a clean report is not proof that you are patched. Use the report to find what you have missed, then confirm on the server itself with the version and build-date checks above.

Other critical vulnerabilities to patch right now (October 2026)

PHP2Shell has dominated the headlines, but it has landed in the middle of an unusually heavy month. Several other critical flaws are being actively exploited, many in the same firewalls, VPNs and remote-access tools that protect everything else, and attackers know that IT teams are stretched. If your team has been working flat out on PHP, make sure these have not slipped. All of the following were added to CISA's Known Exploited Vulnerabilities catalogue in October, which means attacks are confirmed:

• Palo Alto Networks PAN-OS (CVE-2026-0322): a code injection flaw, added on 14 October. PAN-OS is also affected by PHP2Shell, so Palo Alto firewalls need both issues dealt with.
• Ivanti Connect Secure (CVE-2026-104935): an authentication bypass in the widely used VPN gateway, added on 13 October.
• Windows Shell (CVE-2026-96951): a zero-day fixed in Microsoft's October Patch Tuesday, added on 13 October. Make sure every Windows PC and server has the October updates.
• BeyondTrust Remote Support (CVE-2026-102764): an authentication bypass rated 9.3, added on 16 October after CISA warned that attackers were using it for initial access, persistence and moving through networks.
• Cisco Secure Email Gateway (CVE-2026-76519): a path traversal flaw, added on 14 October.
• AhsayCBS backup server (CVE-2026-105133 and CVE-2026-105134): authentication and command injection flaws, added on 14 October. Compromised backup servers are a favourite ransomware target.
• Plex Media Server ("Plex2Shell"): four flaws added on 20 October after attackers used them to install cryptocurrency miners and proxy malware.
• Citrix NetScaler (CVE-2026-88779) and Fortinet FortiMail (CVE-2026-104286): added on 4 October and 1 October respectively.

There has also been a supply-chain attack on LiteLLM, a popular open-source library used to build AI tools, where attackers published a malicious version designed to steal credentials and open remote access. If your developers use it, check which version is installed. Our free Cyber Threat Monitor shows new additions to CISA's exploited list as they appear, so you can see at a glance what attackers are using right now.

The bottom line on PHP2Shell

Treat PHP2Shell as the top priority on every system that runs PHP. Update today, restart PHP, confirm the version the web server is really using, patch your hosting panel, and check any server that was exposed for signs of compromise. If you cannot do all of that today, mitigate hard or take the site offline until you can.

If your website runs on a server we look after through our website hosting or website maintenance services, contact us and we will confirm its patch status. Our contract customers deal directly with a senior engineer rather than a call centre, and even complex issues are typically resolved the same day. For wider protection, see our cyber security services.