PHP2Shell: 22.6 million potentially exposed? Who needs to act now

The number is alarming. What does it actually count?

Headlines about PHP2Shell can make it sound as if every PHP website has already been breached. The facts are narrower: the PHP project patched two critical remote-code-execution flaws on 21 October 2026. Palo Alto Networks Unit 42 reported more than 22.6 million internet-exposed instances potentially vulnerable in its telemetry. This is neither a count of confirmed compromises nor necessarily a count of distinct businesses.

AWS MadPot sensors recorded an attempted exploit dated 17 October, before public disclosure. AWS explicitly said it was unclear whether those early attempts would have succeeded against real systems. The useful response is to verify exposure, patch rapidly and review relevant evidence, rather than assume a breach from a version number or a headline.

What is PHP2Shell and why does it matter?

PHP2Shell is the collective nickname for CVE-2026-109618 and CVE-2026-109619. Both concern memory handling in the PHP runtime. Under their respective conditions, an unauthenticated remote attacker may execute code with the permissions of the PHP web worker. The official PHP advisories describe different mechanics and prerequisites, so a single simplistic exploit story does not fit every deployment.

The flaw lives below the application layer. Updating WordPress core or a plugin is still important, but it does not replace a vulnerable PHP binary. Equally, seeing WordPress on a site does not prove that its current PHP build is vulnerable. The actual web-serving runtime matters.

WordPress, shops, Laravel, Plesk: which environments come first?

The highest operational priority is an internet-reachable application served by an unpatched PHP runtime. Examples include WordPress and WooCommerce, Drupal, Joomla, Magento, Laravel, Symfony, custom PHP APIs and admin panels. The product name helps locate PHP; it does not determine exposure by itself. The PHP project describes Apache mod_php as especially concerning because some processing can occur before application code runs.

PHP-FPM must not be treated as automatically safe. The official advisories describe different prerequisites for FPM, including a validated route for the stale-global-state flaw. Plesk also warned that its shipped PHP builds and some panel components need separate checks. Containers, NAS devices and vendor appliances can embed PHP that is invisible to a website owner's usual dashboard.

What could a site owner lose?

Successful code execution grants the permissions of the PHP process, not automatically root access. That can still be serious: if the worker can write to the web root, an attacker may alter pages, plant malicious code or redirect visitors. The process may also read accessible configuration and secrets or reach data available to the application. Actual consequences depend on filesystem privileges, network isolation and application configuration.

For an online shop, an incident could mean downtime, altered content and a data-protection investigation. A hosting provider must also assess shared runtime and tenant separation. A vulnerable version is not proof of data theft; logs, file changes and other forensic evidence are needed before claiming compromise.

Were there real attacks? Yes. Does that prove mass compromise? No.

AWS documented attempts against its honeypots starting on 17 October and later broader exploitation attempts. Cloudflare observed targeting of its customers and changing payloads, then deployed protective WAF rules. Those observations show real attacker interest. A blocked request or payload sent to a sensor is not the same as a confirmed takeover of a production website.

Unit 42 retracted a previous claim on 25 October about a European government incident: it could not confirm that initial access was caused by these specific PHP2Shell CVEs. This correction matters because incident reporting should distinguish verified attribution from an early hypothesis.

Which PHP releases contain the fixes?

The PHP project fixed both CVEs in 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on 21 October 2026. Older unsupported branches may receive vendor or distribution backports. In that case, compare the package against a vendor advisory for both CVEs rather than relying on a version string alone. Plesk lists some older builds with the same PHP version number but a different build date.

Cloudflare WAF rules and temporary configuration controls can reduce exposure while a change is prepared, but PHP's advisories say the updated runtime is the only complete mitigation. Replace or restart all web workers after updating so no old process remains in service.

Three questions to ask your provider today

On a self-managed VPS or container, inspect all live PHP-FPM pools, Apache modules, bundled binaries and control panels. A terminal `php -v` often reports only the command-line version, which can differ from the binary serving the website. On shared hosting, the provider must confirm the effective build for your domain.

Ask: (1) Which patched PHP build currently serves my site? (2) When were all web workers replaced and restarted? (3) Have relevant logs and file changes since 17 October been reviewed? Ask for a written patch confirmation if the answer is vague. On your own infrastructure, back up, deploy the fixed runtime, restart workers, verify the live build and investigate suspicious events.

• Static site: direct PHP2Shell exposure only exists if a separate PHP component is also running.
• WordPress or WooCommerce: verify the server-side PHP build; plugin updates do not replace it.
• Managed hosting: request the exact build and a patch confirmation from the provider.
• VPS or containers: check every running image and worker, not just the default CLI binary.

How this assessment was prepared

As of 29 October 2026, this article is based on the PHP project's security advisories, AWS and Cloudflare's own observations, Unit 42's exposure estimate and correction, and Plesk's vendor matrix. We did not perform our own internet-wide scan, audit Montavio customers for this article or claim first-hand incident detection. The priority groups above are operational inferences from the cited sources, not remote diagnoses.

Figures and vendor patch statuses can change. For an individual environment, confirm the running PHP build, web-server integration, reachability and vendor advisory together. The linked remediation guide provides a detailed checklist; it is currently available in Hungarian.