{"id":22774,"date":"2026-10-22T09:48:00","date_gmt":"2026-10-22T07:48:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=22774"},"modified":"2026-10-22T10:53:36","modified_gmt":"2026-10-22T08:53:36","slug":"php2shell-protection-updates-unpatched-websites","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/php2shell-protection-updates-unpatched-websites\/","title":{"rendered":"PHP2Shell: What Provides Protection and Why Unpatched Websites Will Remain"},"content":{"rendered":"

As of 22 October 2026.<\/strong> PHP2Shell affects the runtime beneath a large part of the web. Two critical vulnerabilities can allow unauthenticated remote code execution under suitable conditions. Security updates have been available since 21 October. The practical question is now which internet-facing installations are actually running corrected PHP. [1]<\/a> [6]<\/a><\/p>

Updated situation: attempts before public disclosure<\/h2>

AWS reports a PHP2Shell exploitation attempt on 17 October 2026 in its own MadPot telemetry, before public disclosure. For additional observed attempts, success against real-world systems remained uncertain. This is documented warning evidence, not a global count of compromised systems. Investigations of potentially affected installations should therefore reach back before the publication date. AWS: first-hand observations and limitations<\/a><\/p>\n

What PHP2Shell means<\/h2>\n

The identifiers are CVE-2026-109618<\/strong> and CVE-2026-109619<\/strong>. The first involves invalid internal memory state following an out-of-memory condition. The second involves internal references surviving after the underlying memory has been freed. Subsequent processing can turn either condition into a security failure. Both flaws are inside PHP itself. [3]<\/a> [4]<\/a><\/p>\n

\u201cEvery version since PHP 5\u201d conveys the exceptional reach, but does not replace package verification. Old PHP 5 and 7 branches require scrutiny alongside PHP 8. cPanel lists older packages and specific corrected vendor revisions. Moving from PHP 7 to an arbitrary PHP 8 release is therefore insufficient evidence of protection. [7]<\/a><\/p>\n

Apache with mod_php presents a particularly serious case: a demonstrated attack path operates before application code starts. PHP-FPM is not a safe exemption; the PHP Foundation also reports confirmed code execution through application-dependent paths. A WordPress login cannot reliably protect against a flaw below the application layer. [2]<\/a><\/p>\n

Which updates provide protection?<\/h2>\n

The corrected official releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12<\/strong>, or a later corrected release in the corresponding branch. PHP 8.1 and earlier no longer receive regular PHP-project releases. Exceptional minimal source backports exist for 7.4, 8.0 and 8.1, while distributions and LTS vendors may supply corrected packages. [1]<\/a><\/p>\n

An old base version does not necessarily mean an absent patch. The complete package revision and confirmation covering both<\/em> CVEs matter. Conversely, a \u201cPHP 8\u201d label establishes no protection. [7]<\/a><\/p>\n

\"Four
The update must reach the running web service.<\/figcaption><\/figure>\n

From updated packages to protected services<\/h2>\n
  1. Inventory:<\/strong> Domains, PHP pools, containers, forgotten test installations and embedded administration tools all belong in scope.<\/li>
  2. Evidence:<\/strong> Each runtime needs a recorded package source, revision and confirmation that both CVEs are addressed.<\/li>
  3. Running instances:<\/strong> PHP workers must load the corrected build. Custom containers require an updated image and redeployment; updating the host does not modify an existing container image. [8]<\/a><\/li>
  4. Web verification:<\/strong> The command line may use a different PHP installation from the website. Mapping each domain to the active runtime, followed by functional checks, completes the operational verification.<\/li><\/ol>\n

    Where immediate patching remains impossible, ENISA recommends considering isolation of exposed applications. A static maintenance page served before PHP can stop requests reaching the vulnerable runtime. A maintenance plugin running inside that same PHP application does not reliably provide that separation. [5]<\/a><\/p>\n

    Official configuration mitigations only offer temporary reductions in exposure. For example, session.upload_progress.enabled=0<\/code> blocks specific confirmed session paths, not every possible variant. Changes to memory limits are not a universal repair either. Unlimited PHP memory can introduce availability risks; appropriate limits outside PHP require careful coordination. None of these measures replaces patching. [3]<\/a> [4]<\/a><\/p>\n

    The consequences of a missing update<\/h2>\n

    The starting point is code execution with the web worker account\u2019s permissions, not automatic root access. Depending on permissions and accessible secrets, consequences can include stolen database credentials, exposed customer records, altered content, planted malware and abused API keys. Reachable internal services may become further targets where network access and credentials permit. [3]<\/a><\/p>\n

    For an online shop, a modified payment page can be more damaging than an obvious outage. Investigation, recovery, downtime and loss of trust add further costs. A later patch does not remove an existing backdoor. Concrete intrusion indicators call for isolation, evidence preservation, credential review and recovery from a trusted state.<\/p>\n

    Will administrators actually install the updates?<\/h2>\n

    Assessment:<\/strong> A rapid initial reduction in exposed installations is plausible; complete coverage within days is not. Centrally operated platforms can update large numbers of websites together. Individual servers depend on ownership, package availability, compatibility and controlled restarts. Google Cloud explicitly distinguishes automatically updated runtimes from services requiring redeployment. [8]<\/a><\/p>\n

    The remaining population is likely to be persistent: abandoned projects, old agency deployments, containers without maintenance processes and applications tied to unsupported branches. Delays do not automatically indicate administrator negligence. Missing budgets, unclear responsibilities and untested legacy dependencies can obstruct a technically straightforward patch. A specific global update rate would currently be speculation.<\/p>\n

    How many websites will remain at risk?<\/h2>\n

    On 22 October, W3Techs reports PHP on 69.3% of websites with a known server-side programming language<\/strong>. Within the detected PHP population, PHP 7 accounts for 26.9% and PHP 5 for 7.7%, totaling 34.6%. These figures describe adoption and legacy usage, not measured unpatched exposure. [9]<\/a><\/p>\n

    No reliable absolute remainder follows from those figures. Vendor backports, configuration differences, hidden version information and multiple websites sharing a server prevent direct conversion. Individual web pages, domains and servers also represent different counting units.<\/p>\n

    A purely illustrative calculation: in a population of one million genuinely affected installations, a successful 95% update rate would leave 50,000 unpatched. This is neither a measurement nor a forecast<\/strong>. The arithmetic simply explains why even a high completion rate can leave a substantial remainder at internet scale. Verified patch status matters more for a particular website than a global percentage.<\/p>\n

    Linux operations: inventory the runtime actually in use<\/h2>\n

    The following package examples apply to Debian\/Ubuntu systems using APT with existing trusted repositories. The relevant PHP branch must already be installed. RPM systems, hosting panels and custom containers require the corresponding vendor workflow. Adding an arbitrary third-party repository is not a reliable repair strategy.<\/p>\n

    A recoverable backup, a mapping of domains to PHP pools and a short functional test plan belong before the change. Package installation may restart services itself, so the maintenance window starts before the installation command. This inventory covers the CLI and services, but does not yet establish the web handler:<\/p>\n\n

    Shell<\/span>Linux: inventory PHP installations<\/span>