Published: 20 October 2026, 23:00 BST. Updated: 21 October 2026 following the emergency PHP security release.
Patch update: PHP2Shell fixes are now available. Website owners should ask their hosting provider to confirm that the PHP runtime serving their website has been patched. The official fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. See the PHP release announcement.
PHP2Shell is the name being used for two critical PHP remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They affect the software that runs PHP websites, making this an important hosting security issue for businesses using WordPress, online shops, bespoke applications and other PHP-based systems.
The practical priority is to establish who manages your website's PHP installation and obtain confirmation that the relevant security fixes are in place. Updating a website's content or changing its appearance will not repair a vulnerable server runtime.
The warning and the emergency security release
On 20 October, PHP announced an urgent release addressing two vulnerabilities rated 9.2 under CVSS v4.0. Its initial notice scheduled the release for 21 October at 14:00 UTC, while reserving the option to release earlier. At 23:00 BST on 20 October, the emergency release was still pending. See the PHP team's advance notice.
CERT-EU subsequently recorded the release of the fixes at 13:30 UTC on 21 October, equivalent to 14:30 BST in the UK. The patch information in this article was added in the 21 October update. The watchTowr PHP2Shell FAQ provides further reporting on the disclosure and developing threat.
What CVE-2026-109618 and CVE-2026-109619 mean
CVE-2026-109618: memory corruption during error handling
The first vulnerability concerns how PHP handles an out-of-memory condition. Certain failures can leave internal request data in an incomplete state. Subsequent cleanup may then use that invalid data, potentially allowing an unauthenticated attacker to execute code. The PHP project's CVE-2026-109618 advisory explains the issue and its conditions.
CVE-2026-109619: stale state carried between requests
The second vulnerability involves internal state that remains accessible after the memory supporting it has been released. A later request handled by the same worker can encounter that stale state. In suitable circumstances, this can also lead to remote code execution. See the PHP project's CVE-2026-109619 advisory.
Remote code execution means an attacker may be able to run code with the permissions of the affected PHP process. The consequences can include unauthorised access to information or changes to a website. The exact exposure depends on the PHP build, server integration, configuration and application behaviour; an installation does not become safe simply because it uses a different PHP handler.
Affected PHP versions and the fixed releases
For the maintained upstream branches, the security releases are:
- PHP 8.2: update to 8.2.35 or a later patched release.
- PHP 8.3: update to 8.3.36 or a later patched release.
- PHP 8.4: update to 8.4.27 or a later patched release.
- PHP 8.5: update to 8.5.12 or a later patched release.
Do not assume that an older PHP branch is unaffected. PHP's official security advisory also directs users of older installations towards their distribution or extended-support vendor, or an upgrade to a supported branch.
A backport applies a security correction to an older software branch. This is why a patched vendor package can retain an older PHP version number. For example, Canonical lists fixes for several older Ubuntu PHP packages, including PHP 5.5 under its extended maintenance arrangements. The complete package release and the supplier's advisory matter when checking protection.
A practical PHP2Shell checklist for website owners
- Identify the responsible provider. Establish whether PHP is managed by your host, an agency, your own administrator or a software supplier. Include staging sites and older applications in the enquiry.
- Ask about both CVEs. Request confirmation that the PHP environment serving your site includes fixes for CVE-2026-109618 and CVE-2026-109619. Keep that response with your website maintenance records.
- Check the running environment. Installing a package is only part of deployment. The appropriate services or workers must use the updated build; a command-line PHP version alone may not describe the web-facing runtime.
- Check important website journeys. After maintenance, review sign-in, enquiry forms and any checkout or booking process your business depends on. Report new errors to the provider handling the update.
- Continue application maintenance. Maintain WordPress, extensions and other website software alongside the PHP update. A runtime security release does not replace ordinary application upkeep.
Temporary configuration changes need care. PHP's technical advisories make clear that targeted workarounds do not cover every vulnerable path. Avoid copying emergency settings from an unverified post into a live hosting environment. If immediate patching is not possible, involve the administrator responsible for that system.
Giraffe Hosting's response
For clients hosted with the company behind Giraffe Digital, read our Giraffe Hosting PHP2Shell patching update. It explains the server updates, client website checks and legacy PHP backports carried out in response to these vulnerabilities.
PHP2Shell frequently asked questions
Ask your hosting provider to confirm the patch status of the PHP environment serving your website.
What is PHP2Shell?
PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in PHP. Under the relevant conditions, an attacker can exploit them without signing in to execute code through the affected PHP process.
Does updating WordPress fix PHP2Shell?
A WordPress update does not replace the underlying PHP runtime. Your hosting provider or server administrator must apply the relevant PHP fixes. WordPress, plugins and themes should still be maintained for their own security and compatibility. Automattic's response also distinguishes the PHP-level issue from the applications running on it.
Are older PHP 5 and PHP 7 websites covered by the official releases?
The new upstream releases are for the maintained PHP 8.2 to 8.5 branches. PHP 5 and PHP 7 require an appropriate vendor backport or migration to a supported runtime. Ask the provider responsible for the specific installation to confirm its patch coverage.
Is a web application firewall enough to protect against PHP2Shell?
A web application firewall can help reduce exposure, but it does not install a fix in PHP. Cloudflare describes its PHP2Shell protections as an additional layer and still advises customers to patch their PHP installations.
How can I tell whether a website has been patched?
Obtain the installed package or build details and the relevant security advisory from your hosting provider. Confirm that both CVEs are covered and that the web-facing processes are using the fixed build. An older-looking version number can belong to a patched backport, so the short version string is not sufficient evidence on its own.
