On October 21, 2026, the PHP project released emergency updates: two critical vulnerabilities in the core of the programming language, together dubbed “PHP2Shell”, allow attackers to run their own code on the server remotely. They do not need a password to do so. Because the flaw sits in PHP itself rather than in an application, even a cleanly programmed website is affected.
Anyone running PHP – for WordPress, Joomla, Drupal, Magento or Shopware, but also for the web interfaces of NAS systems and other devices – should check today which PHP version is in use. Exploitation attempts have already been reported.
What is PHP2Shell?
PHP2Shell is the nickname for two vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. The PHP team rates both at 9.2 out of 10 (CVSS 4.0), i.e. critical.
- CVE-2026-109618: If PHP runs out of memory during a request, the abort can leave internal data half-initialized. During cleanup, PHP then treats this data as valid.
- CVE-2026-109619: Internal data from a request survives even though its memory has already been freed. A later request in the same process can exploit this stale state.
In both cases the result is remote code execution: the attacker runs commands with the privileges of the web server user. That is enough to steal customer data, tamper with websites, load malware or attack other systems on the network.
Who is affected?
Every PHP installation that answers web requests is affected – regardless of whether it uses PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. According to the PHP team, the highest risk is with Apache and mod_php. Reports indicate that a single unauthenticated request may be enough there.
Updating WordPress, plugins or your shop does not close the gap. It sits one layer deeper, in PHP on the server.
Which PHP version is safe?
| PHP branch | Vulnerable | Patched from |
|---|---|---|
| 8.5 | before 8.5.12 | 8.5.12 |
| 8.4 | before 8.4.27 | 8.4.27 |
| 8.3 | before 8.3.36 | 8.3.36 |
| 8.2 | before 8.2.35 | 8.2.35 |
| 8.1 and earlier | all | no regular update |
There is no official patch for PHP 8.1 and earlier through the regular release process. The PHP team has published source-code backports for 7.4, 8.0 and 8.1, but these are aimed at users who build PHP themselves. Everyone else needs a hosting provider or distribution vendor that backports the fix – or a move to a supported version.
Important: distributions often ship fixes as backports without raising the version number. When in doubt, check the package vendor’s security advisory or changelog.
What to do: website with a hosting provider
- Check whether your provider has updated the PHP version automatically (provider notices, admin panel or your website’s PHP version).
- Trigger the update: If not, start the update yourself in the admin panel, if your provider offers that option.
- Ask: If that is not possible and the version has not been updated, ask your provider when the patch will be applied.
What to do: self-hosted website
- Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or the corresponding distribution package).
- Ubuntu: check the package source. Ondřej Surý’s popular PHP repository (
ppa:ondrej/php) is moving from Launchpad topackages.sury.org. If you simply dismiss the warning about the changed “Label”, you will stop receiving updates. Switch the package source to the new server, then runapt updateandapt upgrade. - Restart services (PHP-FPM or Apache) – otherwise running processes keep using the old code.
- Verify the version – with
php -vand, for the web server, by checking the PHP version actually being served.
Recommendation until you can update
As long as a system cannot be patched, the safest option is to take the website offline to protect customer data and the server. Authorities such as the US CISA and the UK NCSC give the same advice for systems that cannot be updated immediately or run PHP 8.1 and earlier.
As a stopgap only, the PHP team lists settings that make exploitation harder, such as session.upload_progress.enabled=0 (then restart all PHP processes) and limiting the request size. This is explicitly not a complete fix – at best a crutch.
If your site sits behind Cloudflare, you also benefit from the WAF rules provided for the known attack paths. These do not replace the update either.
Don’t forget: devices and forgotten systems
PHP is not just in websites. Devices with a web interface – NAS systems, appliances, management portals – often use PHP too. Here the fix depends on the vendor: check for firmware updates and block access from the internet until then. The same applies to old, unmaintained applications on servers that hardly anyone keeps an eye on.
Conclusion
PHP2Shell is one of the most serious PHP vulnerabilities in years. The update is the only complete protection – and it is available. Check today which PHP version your websites, shops and devices use, and take unpatched systems offline until they are updated.
At HK Trust Solutions, we check which of your systems are affected, coordinate updates with your hosting provider or install them on your servers. Get in touch: +49 7721 402 414 0 or via hk-ts.de.
Sources:
- PHP2Shell: Critical PHP vulnerabilities patched, update now! – Help Net Security
- Critical Vulnerabilities in PHP Require Immediate Patching – CISA
- PHP2Shell: PHP Remote Code Execution Exploited – watchTowr
- php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP – heise online
- Ubuntu: apt error … the PPA is moving to packages.sury.org – Nextcloud Forum