PHP2Shell: Patch PHP, Then Keep Testing

A website can look healthy while the software underneath it needs an urgent fix. Pages load, customers sign in, and the application behaves as expected. None of that tells you whether the PHP runtime serving those requests is vulnerable.

On 21 October 2026, the PHP project shipped fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers call PHP2Shell. Both allow unauthenticated remote code execution. The immediate job is to update PHP and verify the running deployment. The wider lesson is just as practical: security work has to continue as your systems and the threats around them change.

Key takeaways

Patch PHP itself. Updating a CMS, theme, or plugin does not fix a flaw in the runtime.
Verify the live deployment: install the patched build, then restart or replace the workers so the running process uses it.
Make the next test part of the plan, not an afterthought, so coverage survives the next change.

The weakness sits below your application

PHP is the engine behind a large share of the web. A flaw in that engine can create a security problem even when your application code has not changed.

PHP's advisory identifies installations that serve web requests as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. It places the highest risk on mod_php, where researchers demonstrated exploitation before application code runs. The exact attack conditions still depend on the build, configuration, and request handling.

That distinction matters when you assign the work. A developer updating WordPress and a hosting provider updating PHP are changing different layers. Confirm who owns the runtime behind each application, because the application and its PHP runtime are separate parts of the deployment and both need an owner.

Two flaws, different failure paths

The PHP project rates both vulnerabilities Critical, with a CVSS v4.0 score of 9.2. (CVE records that circulated before the release carried an incorrect 10.0.) Both involve unsafe memory handling, but they arise through different paths.

Vulnerability	What goes wrong	Potential impact
CVE-2026-109618	An out-of-memory interruption leaves request data partly initialized, and later cleanup treats that incomplete state as valid.	Memory corruption leading to remote code execution.
CVE-2026-109619	A worker retains state that points to freed request memory, and a later request can use that stale state.	A use-after-free condition leading to remote code execution, and disclosure of process memory.

Successful exploitation runs code with the PHP worker's permissions. It does not automatically grant root. For the stale-state flaw, the request sequence, configuration, and reuse of the same worker all affect the attack path. Wiz also reports that CVE-2026-109619 can leak sensitive process memory, such as tokens and keys belonging to other requests, even without full code execution.

Which versions contain the fixes

The first fixed upstream releases are below. Use the relevant release or a later supported build that contains the fixes.

PHP branch	Affected upstream releases	First fixed release
8.2	8.2.x before 8.2.35	8.2.35
8.3	8.3.x before 8.3.36	8.3.36
8.4	8.4.x before 8.4.27	8.4.27
8.5	8.5.x before 8.5.12	8.5.12

PHP 8.1 and older receive no official release, only minimal source backports from the security team, so those branches need explicit vendor coverage or a move to a supported release. Distribution vendors may backport the fix without changing the upstream version number, so check your vendor's package advisory as well as the version string.

What has been demonstrated

Wiz reports researcher demonstrations of unauthenticated code execution against representative WordPress, Drupal, and Joomla deployments, alongside exposure of sensitive process memory. These show possible impact; they are not reports of those sites being breached.

Exploitation attempts in the wild have been reported. Amazon Threat Intelligence says it saw an attempt against its honeypot network on 17 October, before public disclosure, and watchTowr reports reproducing both flaws and observing attempts. Cloudflare separately reports attack traffic against its customers and payload changes aimed at evading protections. Attempted exploitation does not establish that any specific business was compromised, but it does raise the urgency of applying the update and reviewing your own evidence.

What to do now

Find every PHP deployment. Include production, staging, old campaign sites, containers, and supplier-managed services. Give each one an owner who can confirm the deployed runtime.
Apply the security update. Patch hosts and rebuild affected container images. Update deployment templates too, so a later rollout does not bring back an old build.
Restart or replace affected workers. Installing a package does not prove that a running process has loaded it. Confirm that the workers serving web requests use the patched build. This matters most for long-lived FPM and mod_php processes.
Check the correct runtime. The command-line PHP version can differ from the version serving the site. Verify the web-server integration and FPM pools through administrative access, and keep any diagnostic pages private.
Record the result. Keep the host or image identity, patch evidence, restart time, and validation outcome together, and check important application journeys after the change.
Investigate signs of compromise. Review web, PHP, and endpoint records. If you suspect compromise, coordinate evidence preservation and containment with your incident response team, because patching alone does not remove an attacker's existing access.

If you cannot update at once, make the exposure a service-owner decision: restrict access, or take the affected service offline while you arrange the patch. PHP warns that its temporary configuration mitigations cover particular paths and do not make an installation safe. Keep any applicable WAF protection enabled, but still update the runtime. Cloudflare makes the same point: its rules are an added layer, not a replacement for the patch.

Why security needs to be continuous

An update is complete when the fix reaches the systems that need it and the team can show the result. That takes ownership and follow-up. Consider a team that patches its main website but leaves a staging environment on an older image: production has the fix, while staging still needs attention.

The same gap appears between assessments. New endpoints ship, infrastructure settings change, and suppliers update components. A penetration test tells you about the system and the scope examined at that time. Keeping that evidence useful means returning to the parts that change. Build the next check into the work: test after a meaningful release, retest a reported finding once its fix lands, and schedule reviews of systems that would otherwise be forgotten.

How Breachline helps

Nebula is Breachline's autonomous AI security engineer. Give it a task, an authorized scope, and the access it needs, and it plans and runs security tests, investigates findings, provides evidence and fix guidance, and retests changes. You can run work on demand or on a schedule you set, and projects keep the context so testing continues across releases and follow-up work.

For PHP2Shell, the runtime patch is still the essential step. Confirm coverage for these specific CVEs before you rely on any testing result. Ongoing testing supports that response by keeping findings, fixes, and verification connected. You can see how Nebula works or book a demo within a scope you authorize.

Sources

Research checked 22 October 2026. This article analyses public disclosures; it is not an original Breachline vulnerability disclosure.