In short: If you still run PHP 8.1 or older, you no longer receive official security updates from the PHP project, not even for PHP2Shell. A PHP 8.1 upgrade to a supported version is therefore not optional but the actual solution. We check your applications, test in a copy, migrate in a controlled way and secure the time until then.
Why PHP 8.1 and older is an acute risk now
The PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619 allow code execution without logging in. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There are no official updates any more for PHP 8.1 and older, only minimal source backports for 7.4, 8.0 and 8.1. According to the trade press, nearly all versions going back to PHP 5.4 are affected.
Some distributions and hosting providers apply their own backports. Whether your system is one of them has to be confirmed by the provider for your specific package version. Without that confirmation, you should assume the server is exposed. What this means in detail is described in PHP 8.1 and older: what applies now.
PHP 8.1 upgrade: which target version?
The target should be a version that the PHP project still supports and that your application is approved for. php.net publishes the current state of support on its page of supported versions. PHP 8.2 ends on 31 December 2026; moving to 8.2 would therefore only be an intermediate step with a follow-up project soon after.
We check which PHP version your CMS or shop system supports against the manufacturer's system requirements, for example on wordpress.org, shopware.com or typo3.org, and not from memory. Often the CMS itself has to be updated first. Old shops are a typical case, see Shopware 5: old shops on an old PHP version.
How does PHP SOS help?
- Inventory and securing: We record all applications, their PHP version, CMS state, extensions and custom code. In parallel we apply the interim measures from php.net so that the risk falls until the migration; details at WAF and virtual patching.
- Check compatibility: We compare the manufacturers' system requirements, check dependencies with Composer and search custom code for deprecated functions. What this looks like for dependencies is described in Checking Composer dependencies for vulnerabilities.
- Test in a copy: The application first runs in a test environment with the new PHP version. We fix errors there or document them for your agency.
- Switchover with a way back: The live switchover takes place in an agreed maintenance window with a current backup and a defined rollback path.
- Follow-up check: We check error logs and core functions after the switchover and remove the old PHP version when it is no longer needed.
A harmless look at which websites use which PHP version is possible on many systems via the running FPM pools:
# show running PHP-FPM masters and pools
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# installed PHP versions (Debian/Ubuntu)
ls /etc/php/
An upgrade to a new PHP version does not remove malware that was planted beforehand. If the server was exposed on the network without protection since 17 October 2026, a check for traces is part of the job.
Typical pitfalls during the upgrade
Most problems when changing the PHP version are predictable if you know where to look:
- Outdated extensions: Plugins or modules that are no longer maintained often do not run on newer PHP versions. They need a replacement or an adjustment.
- Custom code: Functions that PHP has since marked as deprecated or removed lead to warnings or aborts. Stricter type checks reveal old programming errors.
- Dependencies: Libraries included via Composer sometimes require newer versions themselves and pull in further changes.
- PHP extensions on the server: Not every extension that was installed under the old version is automatically available for the new one.
- Cron jobs and command line: The website already runs on the new version, but scheduled tasks still call the old PHP version.
Checking these points beforehand shortens the switchover and avoids surprises in live operation.
What you get and what we need
You get an overview of all applications with source and target version, a migration plan with sequence and risks, a test log, the documentation of the switchover and a list of items that your agency or developer still has to complete.
We need from you:
- server or panel access and access to the CMS backends
- access to source code and repository for custom developments
- contact with the agency or developer who knows the application
- a test environment or permission to create one
- maintenance windows and a contact person for acceptance
What we do not promise
We do not promise that every old application will run on a new PHP version without changes. For systems that are no longer developed, a larger rebuild or a switch may be necessary; we say so openly as soon as it becomes apparent. We base compatibility statements on the manufacturers' information. And interim measures are no substitute for the migration; they only bridge the time. Long-term risks of outdated versions are described in PHP end of life: risks of outdated versions.
Frequently asked questions
Is PHP 8.1 affected by PHP2Shell?
According to the trade press, nearly all versions going back to PHP 5.4 are affected. There are no official updates from the PHP project for PHP 8.1 and older, only minimal source backports for 7.4, 8.0 and 8.1. Some distributions apply their own backports; the respective provider has to confirm that.
Which PHP version should I upgrade to?
To a version that the PHP project still actively supports and that your application is approved for according to the manufacturer's system requirements. PHP 8.2 reaches the end of support on 31 December 2026 and is therefore only conditionally sensible as a target.
Can't I simply switch the PHP version in the hosting panel?
Technically that often works with one click. Whether the application still runs afterwards depends on the CMS version, extensions and custom code. Without testing, you risk outages or faulty functions, for example in a shop's checkout.
What if my CMS does not support the new PHP version?
Then the CMS has to be updated first, possibly to a new major version. For systems that are no longer developed, a switch may be necessary. Until then, we secure the server with interim measures.