On 21 October 2026 the PHP project published two critical security advisories that the wider community has grouped under the name ‘PHP2Shell’. By the end of 22 October, all three web servers in ViWeb’s assessed managed fleet, and every PHP runtime branch installed on them, were patched and verified. Follow-up work, including broader malware scanning, is still running on 23 October. Here is what we completed, what we are not claiming, and what to ask any provider that hosts a PHP website for you.

What was announced

PHP’s 21 October announcement (php.net) covers CVE-2026-109618, memory corruption under out-of-memory conditions (GHSA-w8hw-w9fx-j79w), and CVE-2026-109619, a stale global state and use-after-free bug (GHSA-6wmf-4rv5-p3rp). Both are rated critical because, in affected configurations, they can allow code execution without authentication. Not every site is exploitable in every setup, but PHP’s guidance is to update now. Firewalls, plugins and temporary mitigations are not full substitutes. The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older branches are end-of-life. For the older branches in our fleet, we verified vendor backports against changelogs naming both fixes; an unchanged base version string was not sufficient evidence.

Singapore’s Cyber Security Agency alert of 21 October, updated 22 October, reports exploitation attempts in the wild (CSA AL-2026-151). We have no evidence that a ViWeb client was exploited through these CVEs, and we attribute no earlier incident to them. The alert simply confirmed that this patch could not wait for a scheduled maintenance window.

Why a business owner should care

A managed WordPress or PHP site runs on a runtime the owner never sees. If that runtime allows unauthenticated code execution, an attacker needs no password, no plugin bug and no phishing email. The fix is unglamorous: update the runtime everywhere it actually runs, then prove it.

What we completed on 22 October

Inventory first. We listed the PHP branches, extension sets and the control panel’s separately bundled runtime across the three managed servers. A server can carry several PHP installations, and updating the command-line binary alone would not show that the web worker processes or the panel were patched.

Backups checked before patching. We verified local backup archive indexes and nested payload integrity, confirmed coverage for all configured website files, configuration and databases, and compared the latest weekly off-site manifests against remote object sizes and account coverage. This was a coverage and integrity check, not a full restore drill and not a fresh checksum of every remote object. Our backup strategy guide explains why that distinction matters.

Website PHP updated from verified vendor repositories. Current branches received the security releases from the vendor repositories already configured on each server. For legacy branches still in use, we used vendor builds whose changelogs explicitly named both CVE fixes, checking the changelog rather than trusting the version number. Existing branches, extensions and application configurations were preserved, so no site had to be re-tested against a new PHP major version mid-emergency. Staying on a legacy branch is not a long-term recommendation; those sites still need a migration plan.

The control panel’s own runtime. Our Hestia control panel bundles its own PHP, separate from the website runtimes, and on 22 October the panel repository still offered the vulnerable 8.5.9. Rather than leave a known-vulnerable process on an internet-facing server, we built a local emergency PHP 8.5.12 package from official PHP source, checked against the published SHA256, with the same build flags, modules and install prefix as the existing package, inside an isolated and resource-capped build container. It was independently reviewed, and configuration and module parity were verified before installation. This is a clearly labelled local emergency build, not a vendor Hestia release and not a supply-chain guarantee. Replacing it with a verified vendor package is an open follow-up item.

Verification, then staged reboots. We checked the running FPM and panel executables, looked for stale processes still mapped to old libraries, re-validated configurations and service health, and confirmed expected pages, status codes and content markers. Authorized reboots were then performed one server at a time. Each server had to recover and pass its health gate before we moved to the next. We are not claiming zero downtime, and authenticated flows such as checkouts and forms were not fully tested in this pass.

Origin checks and public checks were kept separate. Some public checks met a Cloudflare challenge, and an origin pass was never counted as proof that the public page rendered. Where an origin had a known TLS limitation, we used a labelled HTTP request over a trusted SSH transport rather than bypassing certificate verification.

Still in progress on 23 October

Patching closes known vulnerabilities. It does not prove that nothing happened earlier. We retained recovery evidence, reviewed historically suspicious files separately, and introduced report-only daily and weekly scans across the managed website inventory. The daily scan hashes every file and pattern-scans the changed ones. The weekly scan re-hashes and rescans all files with a narrower exploit rule set under a resource-capped profile, so it is not stronger than the daily pass. Scripts over 1 MiB are bounded, and there is no database, archive or reputation coverage. Nothing is deleted or quarantined automatically. Findings are retained for review; remediation requires separate approval. The broader initial full scans are still running, so we are not claiming fleet-wide malware clearance.

What this does not mean

It does not cover every client everywhere, only the three assessed managed servers as of 22 October. It is dated evidence, not a permanent guarantee. It does not replace WordPress plugin updates, a web application firewall, strong administrator credentials or application-level patching. Those are separate responsibilities, which is why our WordPress maintenance and web monitoring services run as ongoing work rather than a one-off.

Questions to ask your provider

  1. Which PHP branches run on my server, and which processes actually use them?
  2. Were backups verified for coverage and integrity before patching, and when was a restore last tested?
  3. For legacy branches, which vendor changelog names both CVE fixes?
  4. Does the control panel run its own PHP, and was that patched too?
  5. How were patched processes verified, and were reboots staged?
  6. What scanning runs after patching, and who reviews the findings?

If the answers are unclear, or you suspect a site was already compromised before the patch, our website recovery service can assess it and help you plan the next step.

FAQ

Were ViWeb's managed servers patched against PHP2Shell?

Yes. All three assessed managed web servers and every installed PHP branch on them were patched and verified by 22 October 2026. This is dated evidence, not a permanent guarantee.

Does patching mean my website is free of malware?

No. Patching closes the known vulnerabilities. Report-only scans across the managed inventory are still running on 23 October, findings are retained for review, and remediation requires separate approval.

Is an older PHP version automatically vulnerable?

An older base version can include a vendor backport. We verified package changelogs for both fixes; the base version alone is insufficient. Legacy branches should still be migrated over time.