PHP2Shell: Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution

23 Oct

TL;DR

Summary

PHP2Shell is the name given to a pair of critical vulnerabilities in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619. Both vulnerabilities have a CVSS v4.0 score of 9.2 (almost the highest vulnerability score), and can allow unauthenticated attackers to achieve remote code execution (RCE) on vulnerable PHP deployments. To put it bluntly, hackers can potentially gain access to your applications and servers, especially ones accessible by the internet.

Unlike vulnerabilities limited to a particular web application, PHP2Shell affects PHP itself. This significantly broadens the potential attack surface, including websites and applications built on popular platforms such as WordPress, Drupal and Joomla. According to some sources, about 70% of the websites on the internet is built off PHP.

The situation is particularly concerning because exploitation attempts were observed before public disclosure, and working proof-of-concept exploits appeared around the time the vulnerabilities were disclosed.

No time to read essays, what should I do?!?

1. Identify, then Patch, patch, patch: The number one recommendation right now is apply patches, especially for your internet-facing assets. Think of your web-facing applications and APIs, and what they’re built off (including Wordpress, Magento, Drupal, Joomla). Don’t forget potentially about your servers, routers, and anything that is potentially public-facing. Don’t neglect inside of your environment as well. If you provide network access to guests or the public (e.g. public wifi), consider whether there are any applications there that are potentially vulnerable too.

2. Apply temporary mitigations: This is not recommended if patching is available, but is a secondary option. Review the PHP team's advisory for the recommended interim mitigations. Depending on application requirements, these may include disabling session upload progress, tightening request and multipart-upload limits, and adjusting relevant PHP runtime settings. Also ensure a reputable Web Application Firewall is deployed in front of your public-facing applications to slow attackers down.

IMPORTANT: If you can’t patch in time nor apply an appropriate temporary mitigation, then time to consider a temporary shutdown if your systems are vulnerable. Not an easy decision, but if governments around the world are opting to do this, then really consider it. However, really make this decision eyes wide open when considering your risk of compromise vs impact of operational downtime.

3. Audit your environment and supply chain, ask the hard questions: Bring the skeletons out of the closet and look hard at what currently sits in across your entire environment. Identify more systems built off PHP? Repeat steps 1 and 2. If you’re hosting vendor applications that are a black box, check if they’ve published an advisory or a patch directly addressing this. Not sure if they’re affected? Ask. Got important SaaS platforms you use? Ask the question.

4. Investigate for potential compromise: If you don’t have adequate visibility and monitoring on your applications that were vulnerable, investigate whether you were compromised prior to applying a patch. Just because you applied a patch, doesn’t mean an attacker hasn’t already left themselves a backdoor. See further below for some detection tips.

If you believe you have been compromised, take action now. Consider your immediate containment actions (e.g. containing impacted systems or environments), and follow your incident response procedures. If you need help, reach out to NSB Cyber if you need professional assistance.

What Happened

On 21 October 2026, two critical vulnerabilities in the PHP runtime were publicly disclosed under the collective name PHP2Shell. The vulnerabilities were assigned CVE-2026-109618 and CVE-2026-109619, with each receiving a CVSS v4.0 score of 9.2.

PHP is a foundational technology across the web, powering a wide range of websites, content management systems and business applications. Because these vulnerabilities affect the PHP runtime rather than a specific application or plugin, the potential exposure extends across different PHP-based environments.

The two vulnerabilities involve unsafe memory handling when PHP encounters certain error conditions while processing HTTP requests:

CVE-2026-109618 — Out-of-memory corruption: Under specific conditions, PHP can encounter an out-of-memory error while internal request data is only partially initialised. Subsequent cleanup may incorrectly process that data, potentially allowing memory corruption and remote code execution.
CVE-2026-109619 — Stale global state: PHP can retain references to request memory after that memory has been released. Subsequent processing may use these stale references, potentially leading to memory corruption and remote code execution.

Both issues can be triggered through specially crafted HTTP requests without requiring valid application credentials. Depending on the PHP configuration and execution environment, an attacker may be able to exploit the runtime before application-level security controls are reached.

Researchers demonstrated exploitation against common CMS platforms, including WordPress, Drupal and Joomla. These platforms are examples of vulnerable deployment scenarios, rather than the only affected products.

The vulnerabilities also attracted attention because exploitation activity was identified before the official disclosure. Amazon Threat Intelligence reported an attempted PHP2Shell exploit against its honeypot infrastructure on 17 October 2026, several days before public disclosure. Following disclosure, additional proof-of-concept exploits and exploitation attempts emerged.

This highlights the importance of treating the disclosure date as a reference point, not necessarily the beginning of the threat.

Impact

The primary risk associated with PHP2Shell is unauthenticated remote code execution on vulnerable servers. An attacker does not necessarily need an account, a vulnerable application endpoint or user interaction to attempt exploitation.

Successful exploitation could allow an attacker to execute commands with the privileges of the affected PHP process. Depending on the server's permissions, isolation controls and network access, this could lead to several consequences:

Server compromise: Attackers may execute arbitrary commands, deploy web shells or establish a foothold on the underlying host.
Sensitive data exposure: Application configuration, environment variables, database credentials, API keys, session data and other information accessible to the PHP process may be exposed.
Application compromise: Attackers could modify website content, tamper with application files, abuse application functionality or interfere with business operations.
Lateral movement: If the compromised server can access internal services, cloud resources or other systems using trusted credentials, the initial compromise could become a stepping stone into a wider environment.
Service disruption: Exploitation may cause worker crashes, resource exhaustion or application instability, affecting service availability.

The potential impact is amplified by the prevalence of PHP and the fact that the vulnerability resides in the runtime itself. Organisations cannot assume that their applications are safe simply because they are running a well-maintained CMS or have no known vulnerable plugins installed.

The practical risk will depend on the PHP version, server configuration, runtime integration, process privileges and available security controls. Nevertheless, internet-facing systems running vulnerable PHP versions should be treated as high priority.

Another important consideration is that patching does not reverse a compromise that has already occurred. Where vulnerable systems were exposed during the period of active exploitation, organisations should assess whether attackers may have gained access before remediation.

What You Can Do

1. Identify and patch vulnerable PHP instances

Inventory PHP deployments across production servers, development environments, containers, virtual machines and third-party-hosted applications. Include less visible services such as legacy websites, internal portals and forgotten test environments.

Upgrade supported PHP branches to the fixed releases:

PHP 8.5.12 or later
PHP 8.4.27 or later
PHP 8.3.36 or later
PHP 8.2.35 or later

PHP 8.1 and older branches are end-of-life and do not receive normal upstream security updates. Organisations running these versions should migrate to a supported branch or confirm that an appropriate security backport is available from their operating system or PHP vendor.

Verify the actual installed package and vendor security status rather than relying solely on the PHP version string, as some vendors backport security fixes without changing the upstream version number.

Ensure the relevant PHP processes and services are restarted so the patched runtime is loaded.

Important note: Prioritise your public-facing environment

Start with systems that accept requests from the public internet, particularly those running PHP through Apache's mod_php, PHP-FPM or other supported server integrations.

Prioritisation should consider exposure, business criticality, the privileges of the PHP worker, and the sensitivity of data available to the application.

If a system cannot be patched promptly, consider temporarily taking it offline or restricting access to trusted networks while a remediation plan is implemented.

2. Apply temporary mitigations where necessary

If immediate patching is not possible, review the PHP team's advisory for the recommended interim mitigations. Depending on application requirements, these may include disabling session upload progress, tightening request and multipart-upload limits, and adjusting relevant PHP runtime settings.

These measures can reduce exposure but must not be treated as a substitute for applying the security fix. Validate configuration changes carefully to avoid introducing availability issues or breaking legitimate application functionality.

3. Audit your environment and supply chain, ask the hard questions

If it’s been a while and you’re not confident on what’s hosted in your environment, perform a discovery exercise on all the systems and applications. Prioritise based on criticality of environment, asset and public-facing status.

If your PHP application is managed by a hosting provider, managed service provider or container platform, confirm that the underlying runtime has been patched. Updating the CMS, application dependencies or individual plugins alone will not fix a vulnerable PHP runtime.

For containerised environments, update the base images and rebuild and redeploy affected workloads. Check image registries and deployment pipelines to ensure vulnerable images are not reintroduced during future deployments.

For your key vendor-hosted SaaS applications, check with your vendor to see if they are affected.

4. Investigate potential compromise

Given reports of pre-disclosure exploitation, organisations should not assume that a system is safe simply because it has now been patched.

Review the period of exposure, preserve relevant logs and assess whether suspicious requests were followed by unexpected process execution, file changes, new persistence mechanisms or unusual outbound network connections.

If compromise is suspected, follow your incident response procedures, contain the affected system and preserve forensic evidence before rebuilding or restoring services.

See below for some detection and response tips.

Detection & Response

Detection of exploits against php2shell requires several sources on hosts, as the exploit impacts the underlying interpreter before the application logic runs.

Software Version inventory: Identify all assets running vulnerable PHP versions 5.4 through 8.5.11, these versions have been affected by php2shell.
Behavioural Signatures in Network & Web Application Firewalls: Organisations should monitor any abnormal HTTP payloads designed to trip memory limits or abuse file upload mechanics. This may include (but not limited to):
- Excessive repetitions of MIME header patterns such as Multipart_Header_Flood.
- Unusually long form field names such as Large_Form_Key.
- Suspicious POST requests containing strings associated with upload progress tracking such as ‘PHP_SESSION_UPLOAD_PROGRESS’.
- Serialised integer/string anomalies or repeated object structures indicative of generic payloads.
- PHP fatal errors especially memory exhaustion. Also PHP worker crashes.
- Or, if published, WAF detections on the presence of this exploitation.
Endpoint Detection and Log Analysis: Either manually or through an Endpoint Detection and Response (EDR) platform, review:
- Logs in both web server and PHP error logs which:
  - Contain any abnormal worker crashes, memory allocation failures, subsequently followed by any anomalous process spawns.
  - Unexpected shell commands executed by the web server users www-data, apache or even root.
- On the endpoint, look for any anomalous behaviour exhibiting from your potentially affected server. This may include:
  - Unusual PHP or web-server parent-child processes. E.g.
    - php-fpm or apache2 → /bin/sh or /bin/bash
    - httpd or php → curl or wget or python3
  - Unexpected network connections to an unknown or anomalous IP address
  - Check for file modifications or web shells dropped in document roots.

Want to stay on top of the latest breaches and incidents, sign up to our LinkedIn Newsletter or check our Signals page every Friday!

Shane Bell