PHP2Shell: What This Week Tells Us About the Web We Built

What it is

PHP2Shell is the collective name for two unauthenticated remote code execution flaws in the PHP engine: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4 and affect every PHP version back to 5.4 (2012). The PHP Foundation shipped fixes on 21 October 2026, a day earlier than planned, after the embargo leaked on 20 October. The post is by Orca Security.

How it works

CVE-2026-109618 abuses how PHP bails out of an out-of-memory condition while request data is only half initialised. CVE-2026-109619 abuses global state that still points at request memory after it has been freed. Both can also be used to read process memory, where database passwords, API keys and session secrets sit. The usual outcome is a web shell on a trusted, certificated site.

The out-of-memory weakness was first noticed in 2020 and rediscovered in 2024, but was never fixed because nobody could show it was exploitable. In August 2026 a small group of researchers, including Calif and OpenAI, used frontier AI models to build the exploit chain.

Preconditions / Affected

Any host that serves PHP web requests is in scope, whether through PHP-FPM, mod_php, php-cgi, FrankenPHP or LiteSpeed. Censys counts about 2.58 million internet-facing hosts and 54.9 million web properties. Patch availability by version:

• PHP 8.2 and above: a clean update.
• PHP 7.4 through 8.1: source backports that you must compile yourself.
• Anything older: no fix.

The PHP team says there are no complete mitigations, and configuration changes only narrow specific attack paths.

What to do

Within 72 hours:

1. Inventory every PHP runtime, scanning from the outside in. Include container images, serverless functions, appliances with embedded web interfaces, acquired brands and agency-built sites.
2. Patch hosts on 8.2 or later immediately, without waiting for a change window.
3. For 7.4 through 8.1, compile the backports or upgrade. For older versions, take the host off the internet or put it behind a WAF with PHP2Shell rules, which the post calls a bandage.
4. Treat any internet-facing PHP host that was unpatched after 17 October as compromised. Hunt for web shells, new admin users, modified core files and unexpected outbound connections.
5. Rotate every secret held in PHP process memory on an exposed host: database credentials, API keys, cloud access keys and signing secrets.
6. Ask each vendor, agency and SaaS provider which PHP version they run, when they patched, and what they found.

Within the quarter: retire end-of-life PHP from internet-facing systems with an owner and budget; move to short-lived credentials, workload identity and a secrets manager; put a CDN or WAF in front of everything for virtual patching; set up a pre-authorised emergency change path; and prioritise by exposure rather than CVSS.

The post says edge virtual patching bought well-prepared organisations about eleven hours. Orca's detection for both CVEs went live on 21 October 2026. The product section describes Orca's own queries and alerts, and they are not needed to follow the steps above.

Caveats

The post is a vendor piece with opinion mixed in. The author expects similar AI-driven finds in Python, Ruby, Node, OpenSSL and the kernel, and advises treating embargoes as a courtesy with 24 to 48 hours of warning. The "assume compromise" cutoff of 17 October rests on Amazon seeing exploitation attempts four days before the intended disclosure, according to the post. Exact patched version numbers are not given here beyond a link to the PHP 8.4.27 release notes.