PHP has scheduled an emergency security release for 21 October 2026 at 15:00 BST (14:00 UTC). It will address two critical vulnerabilities, each rated 9.2 under CVSS v4.0. The PHP security team is asking users to prepare to update as soon as the fixes become available.
For businesses running PHP websites and applications, the immediate task is to establish where PHP is installed, who manages those installations and how the updates will be applied.
What is PHP2Shell?
PHP2Shell is the name circulating among security researchers for the two flaws. watchTowr describes them as remote code execution vulnerabilities, reportedly tracked as CVE-2026-109618 and CVE-2026-109619. In practical terms, that could allow an attacker to run their own code on an affected server.
PHP’s advance notice does not confirm those identifiers or describe how the vulnerabilities work. It says the affected versions, fixed versions and technical details will be published with the release. Claims that every PHP version since PHP 5 is affected remain unconfirmed.
That distinction matters. There is enough information to justify urgent preparation, but not enough to determine whether a particular application is exposed.
Check the PHP your applications actually use
Start with an inventory of your PHP installations. Include customer-facing websites, internal applications and any software that bundles its own copy of PHP. Huntress specifically advises checking less obvious installations in vendor software and hosting control panels, rather than stopping at the main web server.
Check individual websites too. In hosting environments such as cPanel, different domains can use different PHP versions. The server’s default setting does not necessarily tell you what every site is running.
PHP currently supports branches 8.2, 8.3, 8.4 and 8.5. Versions 8.2 and 8.3 receive security fixes only; 8.4 and 8.5 remain in active support. Older branches, including 8.1, no longer receive updates from the PHP project. A supported branch provides an update path, but does not by itself mean an installation is unaffected by these flaws.
Prepare the update, then verify it
Confirm where your PHP packages come from before deciding how to update them. Your operating system vendor or control-panel supplier may provide its own security packages.
Some vendors apply security fixes to an existing software version, a practice known as backporting. This means the headline version number alone may not establish whether a package is patched. Check the supplier’s security advisory and package information rather than relying solely on a version comparison.
Before deployment, confirm that you have a usable backup and agree who will check the applications afterwards. Keep the checks focused on the functions the business depends on: customer logins, checkout, forms, scheduled jobs and integrations.
Once the update is installed, have the administrator confirm that the relevant websites are actually using the patched PHP runtime. Record the package details and any remaining installations that need attention.
Where prompt patching is not possible, CERT-EU advises considering isolation of internet-facing applications from public networks until a fix can be applied. That decision should sit with the team responsible for the service, taking account of both security exposure and business impact.
Administrators should also investigate unusual activity, such as PHP processes launching unexpected shells or download tools. These are reasons to investigate, not proof of PHP2Shell exploitation. Huntress recommends preserving web server and PHP logs if suspicious activity is found.
Security release and eUKhost service update
For questions about your eUKhost service, contact support with the relevant domain or server details and mention PHP2Shell. Ask which updates apply to your setup and whether you or your developer need to take any action.
