Security Advisory: Critical “PHP2Shell” Remote Code Execution (CVE-2026-109618 & CVE-2026-109619) — How Virtue IT Protected Hosted Clients

1. Executive Summary

On 21–22 October 2026, the PHP Foundation and the Australian Signals Directorate's Australian Cyber Security Centre (ACSC) issued emergency alerts regarding two critical vulnerabilities in the core PHP engine: CVE-2026-109618 and CVE-2026-109619 (collectively tracked in the security community as “PHP2Shell”).

Both vulnerabilities carry a critical CVSS v4.0 severity rating of 9.2 and allow unauthenticated remote attackers to execute arbitrary code on vulnerable web servers over standard HTTP/HTTPS requests without logging in. Because PHP powers over 75% of the web—including every WordPress and WooCommerce website—automated scanning and exploitation attempts began globally within hours of the public disclosure.

2. Technical Breakdown: Why WordPress Security Plugins Cannot Stop This

Many business owners assume that installing a WordPress security plugin (such as Wordfence or iThemes Security) protects their website from server compromises. In this case, application-level plugins offer zero protection.

Both vulnerabilities exist inside the core C-level request lifecycle of the PHP engine itself, meaning an attack can succeed before a single line of WordPress or application code ever executes:

• CVE-2026-109618 (Out-of-Memory Cleanup Corruption): By sending specially crafted multipart HTTP requests (such as malformed form or file upload payloads), an attacker can force a PHP worker to hit an out-of-memory (OOM) condition while internal request structures are only partially initialized. During request shutdown, PHP attempts to clean up those uninitialized pointers, corrupting memory and enabling Remote Code Execution (RCE)—particularly devastating on legacy Apache mod_php servers.
• CVE-2026-109619 (Cross-Request Use-After-Free / Stale State): In persistent worker environments where a PHP process handles multiple consecutive HTTP requests, fatal errors or timeouts can leave internal pointers referencing freed memory. The very next request picked up by that worker can interact with leftover stale state before standard initialization resets it, creating a cross-request Use-After-Free exploit vector.
• End-of-Life Trap (PHP 8.1 and Older on Standard Distros): The PHP Foundation released official patched builds solely for active branches (PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35). Legacy websites running on unmanaged servers with standard PHP 7.4, 8.0, or 8.1 receive no official upstream release from PHP.net and remain permanently exposed unless protected by commercial CloudLinux backporting or migrated.

3. How Virtue IT Mitigated This Threat for Our Web Hosting Customers

If your business website or WooCommerce store is hosted with Virtue IT — whether on our primary Australian cPanel / CloudLinux hosting platform (Synergy Wholesale Sydney data centres) or our dedicated TTVPS / OpenLiteSpeed VPS infrastructure — your systems are already patched and no action is required on your part.

Here is the exact timeline and multi-layered defense deployed across our hosting environment on 22 October 2026:

1. Immediate Interim File-Upload & Multipart Mitigation (09:40–14:44 AEDT, 22 Oct 2026): Immediately following the 01:00 AEDT upstream disclosure—while patched vendor binaries were being compiled and verified—temporary server-wide file-upload and multipart request mitigations were enforced across all cPanel shared and managed hosting nodes (and at our Cloudflare/Sophos WAF edge) to block CVE-2026-109618 exploitation before it could reach PHP workers.
2. CloudLinux Backported Patches Deployed Across PHP 5.2 – 8.5 (Completed 21:06 AEDT, 22 Oct 2026): Our cPanel hosting fleet runs CloudLinux OS with CageFS and LSAPI process isolation (never legacy Apache mod_php). CloudLinux published backported security patches covering every PHP branch from 5.2 through 8.5, which were rolled out across all Sydney production servers by 21:06 AEDT on 22 October, at which point temporary file-upload restrictions were cleanly removed.
3. Why Your cPanel or WordPress “Site Health” Version Number May Look One Release Lower: Please note that CloudLinux applies security fixes as backports while retaining the existing package version string (for example, patched ea-php84 continues to report as 8.4.26 rather than 8.4.27). If you or your web developer check Tools → Site Health in WordPress, do not be alarmed by the displayed minor number — you can verify the patched build timestamp by running php -v in your cPanel Terminal (which displays the 22 October 2026 build date) or via the upstream status notice.
4. Dedicated TTVPS Nodes & Off-Server Backups: All standalone TTVPS OpenLiteSpeed/LSAPI nodes were simultaneously updated to the upstream patched releases (8.2.35 / 8.3.36 / 8.4.27) with full worker pool restarts, backed by daily automated off-server backups.

4. Recommended Actions for Unmanaged Businesses (Hosted Elsewhere)

If your business website is hosted with a third-party provider that does not run CloudLinux backporting, a marketing agency that doesn't manage server internals, or an unmanaged VPS/cloud instance, your site may still be exposed. We recommend verifying the following today:

1. Confirm How Your Host Patches PHP: Check your WordPress Site Health screen (Tools → Site Health → Info → Server). If your server runs standard upstream PHP on 7.4, 8.0, or 8.1 without commercial CloudLinux backporting, those branches are End-of-Life and receive no patch from PHP.net.
2. Verify Patch Levels or Build Dates on PHP 8.2–8.5: On non-CloudLinux servers, confirm your binary is at least PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12. On cPanel / CloudLinux servers, run php -v in the terminal to confirm the binary build timestamp is 22 October 2026 or newer, and ensure all PHP worker processes have been restarted.
3. Eliminate Apache mod_php: Ensure your web server is using isolated LSAPI or PHP-FPM workers rather than legacy mod_php.