Vulnerability Management

PHP2Shell Vulnerabilities: Critical PHP Flaws and What to Do Now

PHP has addressed two critical remote code execution vulnerabilities that can be exploited without authentication. Exploitation attempts were recorded before patches were released, so we strongly recommend immediate remediation of all internet-facing PHP systems.

What happened

Details of the two vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (nicknamed PHP2Shell), leaked online on 20 October, a day before PHP’s scheduled release. PHP released fixes on 21 October. Both are rated 9.2 (critical) under CVSS v4.0.

Calif identified a critical flaw through OpenAI’s Patch the Planet initiative, and Wiz independently discovered and reported both vulnerabilities.

PHP has confirmed that an unauthenticated request can trigger remote code execution against Apache mod_php before any application code runs. Independent researchers, including watchTowr and Datadog, have reported reproducing the flaws in lab conditions. Exploit code has been published on GitHub, but its reliability has not been independently verified. Amazon reported an exploitation attempt against its MadPot honeypot on 17 October, four days before public disclosure, and further attempts from multiple actors on 21 October. Cloudflare and watchTowr have also reported exploitation attempts since 21 October. As of 22 October, no vendor has publicly confirmed a successful compromise of a production server, although Amazon assesses that PHP2Shell is being broadly exploited in the wild.

In plain terms, one vulnerability corrupts memory when PHP runs out of it, and the other lets data left over from one web request be misused by the next. Either can allow an unauthenticated attacker to execute code with the privileges of the web server process.

Who is affected

Any PHP that serves web traffic and is older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12. PHP confirms that all the common server setups are in scope: Apache mod_php, PHP-FPM, CGI, FrankenPHP and LiteSpeed. Command-line PHP cannot be reached over the web, but scripts that handle untrusted files or input remain a risk.

PHP 8.1 and earlier get no official update from PHP, and Cisco Talos reports that the flaws affect every PHP build since 5.4. PHP has published minimal source code fixes for 7.4, 8.0 and 8.1, but these only help teams that build PHP themselves. Some Linux distributions and support vendors offer packaged fixes for older versions. Where none is available, isolate the system or move it to a supported branch.

This is a PHP runtime issue rather than a vulnerability in the application itself. Even fully patched WordPress, Magento, or other PHP-based applications remain at risk if they are running on a vulnerable PHP version. Remediation must therefore be performed by the party responsible for maintaining the PHP runtime, whether that is an internal IT team, a hosting provider, or a software vendor.

Why it matters

Three things make this more serious than a typical PHP advisory.

The first is that many systems cannot simply be updated. Cisco Talos estimates that around half of PHP systems will not receive a patch. PHP 8.1 and earlier are already end of life, and security support for PHP 8.2 ends on 31 December 2026. For those systems, closing the gap means a backport or migration, rather than a routine update.

The second is unclear ownership. Asset inventories tend to list applications, not the runtimes underneath them. PHP inside an appliance, a hosting panel or an inherited container image may have no clear owner. In practice, a runtime nobody owns is a runtime nobody patches.

The third is that defenders had no head start. Exploit code was public before the fix, so attackers did not need to reverse-engineer the patch. The flaws can also leak server memory, so an attack that fails to take control may still expose data.

What to watch for

Successful exploitation of a server-side PHP vulnerability often leaves similar traces regardless of the underlying flaw. One of the clearest indicators is a PHP process spawning programs it would not normally execute.

Examples include command shells, scripting interpreters such as Python or Perl, file download utilities such as curl or wget, or network utilities used to establish outbound connections. Attackers frequently run simple reconnaissance commands such as whoami, id, or uname -a immediately after gaining code execution.

None of these activities is conclusive on its own. Administrative scripts, deployment tools, and monitoring agents may exhibit similar behavior. The key is identifying unexpected process trees, suspicious command lines, or activity that coincides with a specific web request or the creation of new files on the server.

Linux administrators can perform a quick review of running processes to determine whether web-server processes are launching unexpected child processes:

Where available, endpoint detection and response (EDR) tools, Linux audit frameworks, or process monitoring solutions such as Microsoft Defender for Endpoint, CrowdStrike, Sysmon for Linux, or auditd can provide a more complete record of process execution and parent-child relationships.

If suspicious activity is identified, isolate the affected server and preserve web, application, and system logs before beginning remediation.

Importantly, patching a compromised system does not remove a threat actor who has already gained access. Remediation should include both patching and incident response activities to determine whether the host was successfully exploited.

For systems that cannot be patched immediately, consider reducing exposure by removing internet-facing access where practical or by implementing compensating controls such as reverse proxies, VPN access restrictions, or web application firewall rules. These measures may reduce risk but should not be considered a substitute for applying the vendor’s security update.

What to do now

Identify and inventories all PHP applications. Check web servers, containers, build images and third-party products that bundle PHP.
Patch internet-facing systems first, then internal systems.
Engage with your providers to understand their remediation timelines. Hosting providers, managed service providers, and appliance vendors may release fixes on different schedules. In some cases, vendors backport security updates without changing the reported version number, so review vendor advisories before concluding that a system remains vulnerable.
Make sure the updated version is actually running.
Limit exposure while you wait. Restrict admin panels and take unneeded PHP apps offline. PHP has published a temporary measure for each flaw. For CVE-2026-109619, set session.upload_progress.enabled=0, and on PHP 8.5 also set fatal_error_backtraces=0. Apply these in php.ini, the PHP-FPM pool or the server configuration, not through ini_set() or an FPM .user.ini file. Then restart every PHP worker. Each measures blocks only some attack paths and is no substitute for patching.
Look for signs of compromise. Watch for PHP processes launching shells, unexpected file changes and unusual outbound traffic.

How Theos Cyber is responding

For Managed Threat Detection and Response (MTDR) clients, our team is hunting for signs of exploitation across monitored environments. We will contact you directly if we find anything.

For Vulnerability Management clients, we have added checks for both flaws and will report affected systems through your usual channel.

For Incident Response Retainer clients, our DFIR team is on standby. Contact us if you suspect compromise.

If Theos Cyber does not monitor your environment, we can still help. Our MTDR team can hunt for signs of compromise, our offensive security team can confirm your fixes hold, and our DFIR team can investigate if you suspect a breach. Get in touch to talk it through.

Sources