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, early attacks were reported before the fix was even out, and 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.

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

You cannot fix PHP2Shell from within your store code.

— Sansec Forensics Team, writing for online shop owners

Reports of real-world attacks are still coming in, and they do not all agree yet. 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. Huntress had not yet seen attacks across its partner base on the morning of 21 October, and neither flaw is yet on CISA's 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 the leak on 20 October, 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. 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.
• 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 does.
• 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 and Grav.
• Online shops such as Magento and Adobe Commerce, WooCommerce, PrestaShop, OpenCart and Shopware.
• 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, MediaWiki, DokuWiki, 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

• Firewalls whose web interface is written in PHP, notably pfSense and OPNsense. They run on FreeBSD rather than Linux, but the PHP they ship is exposed in the same way, so watch for vendor updates and never expose the admin interface to the internet.
• 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, 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 and HESK.
• Database administration tools such as phpMyAdmin, Adminer and phpPgAdmin.

Business applications and password managers

• CRM and ERP systems such as SuiteCRM, SugarCRM, vTiger, EspoCRM and Dolibarr.
• Invoicing, billing and accounts software such as Invoice Ninja, Akaunting, WHMCS and Blesta.
• 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.

File sharing, NAS and storage

• Nextcloud and ownCloud's classic server.
• NAS systems with a PHP admin interface, such as OpenMediaVault and Unraid.
• Synology and QNAP units where the Web Station or Web Server feature is running PHP sites.

CCTV, building systems and small devices

• PHP-based camera and recording systems such as ZoneMinder.
• 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.

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. Install the patched version

   Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to 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.

4. 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.

5. 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.

6. 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.

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 has scheduled fixes as hotfixes 18.0.80#11 and 18.0.81#4. Until your server shows one of those, we recommend restricting 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 has added the patched versions to EasyApache 4 for ea-php82 to ea-php85, and has backported the fix to its PHP 7.4, 8.0 and 8.1 packages, as GoDaddy reports.
• 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, so watch CloudLinux's announcements and update with your package manager as builds arrive.
• LiteSpeed is on PHP's list of affected setups. Update the lsphp builds your server uses and restart LiteSpeed.

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.
• 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.
• 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.
• 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. 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. 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.

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.