On 21 October 2026, PHP released emergency security updates for two critical vulnerabilities known as PHP2Shell. They could allow an attacker to run code through a vulnerable web server without logging in, putting websites and their data at risk.
At Itomic, we began preparing before the fixes were released. We reviewed PHP across our hosting fleet, identified the different versions and suppliers involved, and prepared to apply and verify updates as they became available.
When vendor patches arrived, we moved quickly to install them and verify the updated runtimes. That response, and the ongoing checks behind it, are part of what clients receive with managed hosting.
Most website security stories involve a vulnerable plugin, an outdated theme or a stolen password. PHP2Shell affected something deeper: PHP itself, the software that runs WordPress, Drupal, Laravel and many other website platforms. Updating a website’s plugins could not repair the underlying PHP vulnerability. The hosting environment needed attention too.
The PHP project brought its security release forward after details leaked online on 20 October. Both vulnerabilities were rated critical, with a CVSS v4.0 score of 9.2. Researchers subsequently reported active exploitation attempts, reinforcing the need for a prompt response.
The fixes were released as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Hosting and operating-system vendors also supplied patched packages, sometimes retaining older version numbers. PHP’s security advisory explains the affected systems and recommended response.
These vulnerabilities were not limited to one website platform or hosting setup. PHP identified installations serving web requests as being at risk, including Apache, PHP-FPM and LiteSpeed environments. The demonstrated risk was highest with Apache’s mod_php configuration, but other configurations also needed to be checked and patched.
For website owners, the practical lesson is straightforward: a fully updated CMS still depends on a properly maintained server.
Older PHP versions made the response more complicated. The PHP project no longer provides regular security releases for PHP 8.1 and earlier, although its security team supplied minimal source patches for PHP 7.4, 8.0 and 8.1 in response to this emergency.
Linux distributions, independent package maintainers and commercial support vendors also provided backports for older branches. A backport adapts a security fix to an earlier software version, allowing an older application to receive protection without immediately moving to a newer PHP branch.
That work matters. Some older websites cannot move to a new PHP version without application changes and testing. Supported backports can provide valuable breathing room while those upgrades are planned.
They also make verification important. A patched vendor package may still show an older PHP version number. Confirming protection means checking the actual package against the supplier’s security guidance and confirming which runtime the website uses.
Our response at Itomic covered more than the obvious website PHP settings. We inventoried multiple PHP branches and the copies bundled with hosting and management software, then tracked fixes through the relevant vendor channels. We applied available updates, checked the installed components and verified the services using them.
Some legacy and vendor-supplied components follow different release schedules. We continue to monitor and verify those updates, following up where a supplier’s coverage or supported upgrade path needs clarification. That ongoing work is part of managing the hosting environment responsibly.
For clients, managed hosting means having someone take ownership of this server-level response. Itomic handles the PHP package updates and service checks; clients do not need to install server patches themselves. Where an older application needs a compatibility upgrade, we can help plan and test that work separately.
It is the same approach behind our managed hosting and website security services: know what is running, respond promptly, and verify the result.
If your website is hosted elsewhere, there are a few useful questions to ask:
- Has the PHP runtime serving my website been patched? Ask for confirmation against the hosting provider’s vendor guidance. A version number alone may not tell the whole story.
- Were the relevant services restarted or their workers replaced? Updating files does not update PHP processes that are still running the old code.
- Were staging sites and older installations checked too? Forgotten test environments and legacy applications also need attention.
- Is there a plan to move away from unsupported PHP? A backport can address this vulnerability, but it does not make an obsolete stack a long-term choice.
Unusual errors or process activity should be investigated promptly. If you suspect a compromise, contact your hosting provider or security specialist. Patching closes the vulnerability; it does not, by itself, remove an attacker who has already gained access.
There is no WordPress plugin that can replace the PHP security update. Temporary protections can reduce exposure to particular attack paths, but the complete remedy is a correctly patched PHP runtime.
PHP2Shell is also a timely reason to review your website’s upgrade plans. PHP 8.2 reaches the end of upstream security support on 31 December 2026. If your website runs on PHP 8.2 or an older branch, planning its next upgrade now gives you time to test compatibility and address any application changes. You can check PHP’s support schedule or talk to us about our platform upgrade services.
A well-managed website depends on more than its design and content. It needs ongoing care for the software underneath it, especially when an urgent security issue arrives. If you would like help reviewing your hosting, PHP version or upgrade options, talk to Itomic.
