What PHP2Shell means for your web and API security testing scope

On October 26, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog. Both carry a CVSS v4.0 score of 9.2, both let an unauthenticated attacker run code on the server, and both sit in PHP itself.

W3Techs measures PHP on 70.8% of the websites whose server-side language it can identify, and PHP also ships inside vendor products and control panels. Because the flaw sits in the runtime, every application on a host shares it, including systems nobody labels as PHP applications.

Six areas belong in a web and API testing scope when the runtime carries the flaw. Each answers a question leadership will be asked this quarter: where PHP runs, which pages answer without a login, whether the APIs share the runtime, what a compromised host could reach, whether the SOC would see it, and whether the patch reached the runtime serving traffic. The sections below cover what PHP2Shell is, why patching leaves those questions open, and how to validate each one with offensive testing before year end.

What is PHP2Shell?

PHP2Shell is the name for two critical PHP vulnerabilities:

• CVE-2026-109618: remote code execution through out-of-memory corruption during request cleanup.
• CVE-2026-109619: remote code execution through stale request-owned global state that a later request on the same worker reuses.

Neither needs a login. PHP states that every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates the risk highest for mod_php, where it has demonstrated an unauthenticated request triggering the attack before any application code runs.

PHP2Shell timeline

• October 17, 2026: Amazon Threat Intelligence logged an exploitation attempt against its honeypot network, four days before disclosure.
• October 21, 2026: PHP shipped fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. VulnCheck recorded probing against internet-facing hosts, starting with a GET to index.php and a multipart POST behind it.
• October 21 and 23, 2026: UltraViolet's TIDE team published an initial PHP2Shell threat advisory and an updated advisory covering new exploit activity, configuration guidance and patch steps.
• October 26, 2026: CISA added both CVEs to its Known Exploited Vulnerabilities catalog.

Does patching PHP resolve PHP2Shell exposure?

Patching closes the flaw on every host your team has inventoried. Hosts outside that inventory keep the open questions.

PHP ships inside products as well as web servers. The CERT-EU and NCSC-NL tracker lists Cisco, NetApp and Broadcom products as affected or under review, and hosting panels, bundled binaries and container images each carry their own PHP version. PHP 8.1 and older no longer receive updates from the PHP project, which published minimal source backports for 8.1, 8.0 and 7.4. PHP 8.2 reaches end of life on December 31, 2026, so a host patched to 8.2.35 still needs an upgrade plan before year end.

A CISO answering the board needs four facts:

1. Where PHP runs.
2. Whether each instance is fixed.
3. Whether anything ran against it before the fix.
4. What an attacker could reach from a host that fell.

Testing produces evidence on where PHP runs, whether the fix holds and what a compromised host could reach.

Amazon Threat Intelligence advises starting log review from October 17, 2026, the date of the earliest exploitation attempt it recorded. A patch closes the flaw and leaves in place anything an attacker installed earlier.

What should a web and API testing scope cover for PHP2Shell?

Six areas belong in a web and API testing scope when the runtime carries the flaw.

The last two rows are where UltraViolet’s red, blue and purple teams work as one program: offense informs defense; defense sharpens offense. A finding from the web test reaches the SOC as a detection requirement, and the retest confirms both the patch and the alert.

How does the 3D Security Testing Subscription cover PHP2Shell testing?

UltraViolet Cyber's 3D Security Testing Subscription gives teams a pool of penetration testing capacity they steer on three dimensions: what they test, when they test, and how deep they test.

• What. Web and mobile applications, APIs, networks and cloud infrastructure draw from one allocation, so all six areas above sit under one agreement. A scheduled web test can pivot to an API target mid-subscription without a new contract cycle.
• When. Self-service scheduling lets teams book the exposure test and the retest through the portal. Findings rated critical, high or medium can be revalidated within 90 days, triggered when the team is ready to confirm the fix.
• How deep. Targeted penetration testing confirms exposure across a host class. A full application assessment covers the systems that carry the most business risk. A purple team exercise tests whether detection holds.

Customer example: A global financial software company used the subscription for 150+ tests and retests across multiple regions. The program identified 50 security defects, improved coverage across 80% of the application portfolio and met regulatory reporting requirements.

See how the 3D Security Testing Subscription works through UltraViolet's Penetration Testing Services.

Sources