23 October 2026 | DX3webs Security Updates
While we’re proud of the speed of our own response, it’s also important to recognise just how well the wider PHP and hosting industry came together to address these vulnerabilities.
When two critical PHP vulnerabilities were disclosed on 21 October 2026, hosting providers around the world faced a race against time to protect their customers.
At DX3webs, we were ready to respond.
Within a remarkably short window of the official PHP and Plesk security releases becoming available, we were deploying updated PHP binaries across our hosting infrastructure, protecting customer websites and verifying that the fixes were actually running.
And we didn’t stop there.
Over the following hours, we developed and deployed our own security auditing and mitigation tools, investigated previously unsupported PHP versions and established a clear picture of which applications were protected and which required further work.
It has been an intensive couple of days, but we’re extremely pleased with how quickly our infrastructure and security response came together.
A race against the clock
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell, affect PHP’s internal processing and could potentially allow serious exploitation under certain conditions.
For a hosting provider specialising in Magento, WooCommerce and business-critical PHP applications, these are exactly the vulnerabilities that demand immediate attention.
The challenge was not simply knowing that patches were coming. We needed to identify which PHP versions were affected, monitor multiple software vendors, obtain the correct packages and deploy them safely without unnecessarily interrupting customer websites.
Rapid deployment of the key Plesk PHP security releases
When the patched PHP 8.2, 8.3, 8.4 and 8.5 binaries became available through Plesk on 21 October, DX3webs moved quickly to deploy them across the relevant servers.
The gap between the release of the key security packages and our deployment was measured in hours, not days.
This was especially important for our managed Magento and WooCommerce customers, whose websites depend on stable, continuously available PHP environments.
As further Plesk security builds became available for PHP 7.4, 8.0 and 8.1, we incorporated those into the same response.
We also addressed Plesk’s own internal PHP engine as the necessary security micro-updates were released.
Rather than relying entirely on automatic updates, we actively tracked the vendor releases and verified the installed package versions.
For us, that is what proactive managed hosting should look like.
Going beyond standard security patching
One thing became clear very quickly: simply running a PHP version command was not enough to determine whether a server was protected.
Some vendors released completely new PHP versions, while others backported the vulnerability fixes into existing versions.
That meant a server could report an older PHP version while actually having the necessary security protection, or appear fully updated while still lacking the relevant fix.
We built our own PHP2Shell security audit
To solve this, we developed a dedicated DX3webs auditing tool capable of checking different PHP distributions and security backports across our hosting infrastructure.
Our audit checks:
- PHP versions and installed package revisions.
- Plesk, Ubuntu and Ondřej Surý security updates.
- Which PHP handlers individual customer domains use.
- Whether PHP-FPM processes restarted after security updates.
- Plesk’s internal PHP engine.
- Installations that remain outdated or require further verification.
We have already tested the tool against real hosting environments, including older PHP applications running alongside current PHP versions.
This gives us a much more accurate picture of our infrastructure than a conventional version scan alone.
We wanted to know that the patches were working, not simply that an update command had completed.
An additional layer of protection — developed in-house
While waiting for patches to become available, we also developed our own PHP2Shell mitigation tool.
This enables us to audit and apply additional PHP security settings across supported Plesk websites, while preserving existing configuration and rollback information.
The changes include disabling PHP session upload progress where it is not required and enabling stricter session handling.
These settings provide defence-in-depth and remain useful even after the main PHP vulnerabilities have been patched.
Crucially, we designed our approach around the needs of live ecommerce websites.
Blanket emergency restrictions can cause significant disruption to checkout processes, administration and uploads. Our aim was to provide meaningful protection without unnecessarily interfering with customers’ ability to trade.
The legacy PHP challenge — and an important breakthrough
One of the most difficult parts of the response has been protecting websites that still depend on older PHP versions.
Legacy applications are a reality of commercial hosting, particularly with established Magento 1 installations and bespoke applications.
Upgrading an application to a completely different PHP version is not always something that can be achieved safely overnight.
We therefore investigated alternative routes to obtaining security patches for PHP 5.6, 7.0, 7.1 and 7.2.
And we found some very encouraging news.
Ondřej Surý, whose widely used PHP repositories support a large number of Ubuntu installations, released security backports for these older PHP versions.
We went beyond checking package publication dates and inspected the actual package changelogs, confirming that the fixes explicitly addressed both PHP2Shell vulnerabilities.
| Legacy PHP | Confirmed patched package revision |
|---|---|
| PHP 5.6 | 5.6.40-104 or later |
| PHP 7.0 | 7.0.33-92 or later |
| PHP 7.1 | 7.1.33-80 or later |
| PHP 7.2 | 7.2.34-66 or later |
These are specific to Ondřej’s supported package builds.
We have already verified a live PHP 7.2 hosting environment using the patched packages, including confirmation that its PHP-FPM process restarted after installation.
That is a valuable result: it demonstrates that we can protect certain older applications against these vulnerabilities without immediately forcing customers onto an incompatible PHP version.
Where standard repository support is no longer available, we are also investigating TuxCare Extended Lifecycle Support and alternative supported hosting environments.
We are not treating unverified legacy installations as fixed. They remain part of our ongoing remediation programme.
Where we stand today
Less than two days after the initial PHP2Shell disclosure, we had already achieved several important milestones.
| Area | DX3webs progress |
|---|---|
| Critical Plesk PHP security releases | Rapid deployment following vendor availability |
| Plesk internal PHP engine | Security updates deployed and verified on audited servers |
| Legacy PHP 5.6–7.2 | Security backports identified and confirmed |
| Custom security audit | Developed, tested and deployed |
| Additional PHP hardening | Custom mitigation tool developed and actively deployed |
| Customer PHP handlers | Domain-level verification underway |
| Older unsupported installations | Extended-support and migration options being investigated |
There is still work to do, particularly with older PHP installations that are no longer covered by standard repositories.
But the speed of our initial response, combined with the additional verification and tooling, has put us in a strong position to finish that work systematically.
An impressive response from the wider hosting industry
While we’re proud of the speed of our own response, it’s also important to recognise just how well the wider PHP and hosting industry came together to address these vulnerabilities.
The PHP development team, Plesk, Ubuntu, Ondřej Surý, CloudLinux, TuxCare and security researchers such as Sansec all played important roles in making fixes, technical guidance and additional protection available at remarkable speed.
Particularly impressive was the effort to provide security backports for older PHP versions that have long since reached their official end of life. For hosting providers supporting established business applications, those patches made an enormous difference.
The speed at which information was shared, security packages were built and released, and guidance was refined allowed hosting providers like DX3webs to respond rapidly and decisively.
It was a fantastic example of the software and hosting industry working together under pressure, and everyone involved deserves considerable credit.
Our own rapid deployment would not have been possible without the hard work of the developers, maintainers and security teams behind those releases.
Why this matters for our customers
When a serious vulnerability emerges, there is often very little time between a security fix becoming public and attempts to exploit it.
For customers, the difference between an unmanaged server and a properly managed hosting environment can be significant.
At DX3webs, our response involved far more than running routine operating-system updates.
We monitored the upstream PHP project and its security advisories, tracked Plesk releases, investigated third-party backports, deployed patches and developed additional tooling specifically for our environment.
We also kept the operational needs of customer websites at the centre of every decision.
Security and availability should work together, not compete with each other.
That philosophy is particularly important for ecommerce businesses, where downtime can be just as damaging to day-to-day operations as many technical incidents.
Proud of the response — focused on what comes next
We are proud of how quickly DX3webs responded to PHP2Shell.
Getting the key Plesk PHP security releases deployed within hours of their availability was an important achievement, particularly across a hosting environment supporting applications with very different requirements.
Developing and deploying additional auditing and mitigation tools during the same response has given us valuable capabilities that will continue to benefit customers long after this particular security incident.
We also recognise that legacy PHP remains an ongoing challenge, and we are continuing to work through the remaining installations requiring supported fixes or alternative protection.
For us, this incident has reinforced something we have always believed:
Great managed hosting isn’t just about keeping websites running when everything is working. It’s about how quickly and effectively you respond when something goes wrong.
And this week, the DX3webs team has demonstrated exactly that.
DX3webs — Specialist Managed Magento, WooCommerce and PHP Hosting
If you have questions about your website’s PHP security or hosting environment, please contact our support team.
Official references and acknowledgements
We would like to acknowledge the exceptional work undertaken by the PHP development team, Plesk, Canonical, Ondřej Surý, CloudLinux, TuxCare and the wider security research community in responding to PHP2Shell.
The speed at which critical patches, legacy PHP backports and technical guidance became available was invaluable to hosting providers working to protect customer infrastructure.
For readers interested in the technical details, the following official resources document the vulnerabilities and the industry’s response:
- PHP Development Team — October 2026 Security Releases
- Plesk — PHP2Shell Security Advisory
- Canonical — Ubuntu Security Notice USN-8948-1
- Canonical — Ubuntu Legacy Security Notice USN-8948-2
- Ondřej Surý — PHP Package Repository
- CloudLinux / TuxCare — PHP2Shell Release Updates
- CloudLinux — PHP2Shell Package Verification Guidance
- Sansec — Ecommerce Security Research
Our thanks go to everyone involved in producing and distributing these fixes. Their work enabled providers like DX3webs to act quickly and protect customer websites.