PHP2Shell: Critical PHP Vulnerabilities and How to Protect Your Website

PHP2Shell is the name given to a pair of critical vulnerabilities in the PHP runtime. Disclosed in October 2026, these flaws can allow an unauthenticated remote attacker to execute code on a vulnerable web server. In practical terms, an attacker may be able to compromise the server without first logging in to the website.

The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both have a CVSS v4.0 score of 9.2 (Critical). The PHP project has released fixed versions, and administrators should treat updating as an urgent security task.

This issue matters well beyond developers who write PHP. Many websites and business applications rely on PHP behind the scenes, including sites built with popular content management systems. A website can therefore be exposed even if its owner has never edited a line of PHP code.

What is PHP?

PHP (PHP: Hypertext Preprocessor) is an open-source, general-purpose scripting language widely used for server-side web development. Unlike JavaScript running in a visitor's browser, PHP normally runs on the web server. It processes requests, works with databases and other services, applies application logic, and generates the HTML or other response sent to the visitor.

PHP is used by a broad range of websites and platforms, including:

• WordPress, a widely used content management system powering blogs, company websites and online stores.
• Drupal, a content management framework used for complex websites and organisational platforms.
• Joomla, another established content management system.
• MediaWiki, the software behind Wikipedia.
• Custom PHP applications, such as booking systems, customer portals, e-commerce platforms, APIs and internal business tools.

PHP commonly runs with web servers and application handlers such as Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. This is important because PHP2Shell affects the PHP runtime itself, not just one particular website or plugin.

What is PHP2Shell?

PHP2Shell refers to two related security vulnerabilities in the core PHP runtime. They involve memory-management problems that can occur when PHP handles certain error conditions and request-processing states.

At a high level, the issues concern:

• CVE-2026-109618, out-of-memory (OOM) handling: under certain conditions, PHP can leave internal request data in an invalid or incompletely initialised state after an out-of-memory event. Later cleanup operations may use that invalid state.
• CVE-2026-109619, stale global state: in certain circumstances, internal state can continue to refer to memory belonging to a request even after that memory has been released. A later request may encounter and use this stale state.

These are low-level defects in the PHP engine. A specially crafted request can trigger vulnerable processing paths. Depending on the deployment and exploitation path, the result can be remote code execution (RCE) or disclosure of sensitive data from PHP process memory.

The demonstrated attacks did not require the attacker to authenticate to the affected website. The PHP project has identified Apache mod_php deployments as particularly high risk, because a demonstrated attack can be triggered before application code runs. Other web-facing PHP setups are also in scope.

You do not need to understand the internal memory-management details to take the right action: identify every PHP runtime that serves requests and update it to a fixed release.

What could happen if a server is compromised?

Successful exploitation can have serious consequences. Depending on the permissions of the PHP process and the server's configuration, an attacker may be able to:

1. Execute commands on the server. Code may run with the privileges of the PHP or web-server worker.
2. Access application data. This may include customer records, uploaded files, configuration files and other information accessible to the compromised process.
3. Steal credentials and secrets. PHP process memory may contain database passwords, API tokens, session-related data, certificates or other sensitive values.
4. Modify the website. An attacker may deface pages, inject malicious content, create unauthorised accounts or install persistent malicious code.
5. Use the server as a foothold. A compromised server may be used to target connected systems or services, depending on network access and permissions.
6. Disrupt services. Exploitation or attempts to exploit the flaws may cause worker crashes, errors or service interruptions.

These are potential outcomes, not a claim that every vulnerable website has been compromised. The actual impact depends on the environment, privileges, exposed services and whether exploitation succeeds.

Which PHP versions are affected?

The PHP project released security updates on 21 October 2026. For the actively maintained release branches listed in the advisory, the first fixed versions are:

PHP branch	First fixed version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Versions earlier than the corresponding fixed release are affected. PHP 8.1 and older branches are end-of-life or otherwise outside the current supported release branches. Some operating-system or commercial vendors may provide backported security fixes for older versions; verify the exact package status with that vendor. If no supported security update is available, plan a migration to a supported PHP branch.

Important: Installing the latest version of WordPress, Drupal, Joomla or a plugin does not automatically update the PHP runtime. The runtime must be patched separately.

How to check whether your website is affected

Website owners and administrators should not assume that PHP is absent simply because they do not maintain PHP code themselves. Check the full hosting and deployment environment.

1. Identify every PHP installation. Check hosting control panels, virtual machines, containers, managed hosting accounts, web servers and third-party products that may bundle PHP.
2. Check the version used by the website. The command php -v reports the CLI version, but a website may use a different PHP-FPM pool, Apache module or hosting-managed runtime. Confirm the version serving actual web requests.
3. Check all sites and environments. Include production, staging, development systems that are internet-accessible, secondary domains and legacy applications.
4. Check the vendor's package status. Distribution packages and hosting panels may use their own versioning or backport security fixes. Confirm that the installed package contains the PHP2Shell fixes.
5. Keep an inventory. Record the application, PHP version, hosting location, owner and patch status so that future security updates can be handled quickly.

If you use shared hosting, contact your hosting provider and ask whether the PHP runtime serving your account has been updated to a fixed release.

What should website owners and administrators do?

1. Update PHP immediately

This is the primary and complete remediation. Install the fixed PHP release for your branch, or the equivalent security-patched package supplied by your operating-system or hosting vendor.

After updating, restart or reload the relevant services so that old PHP workers stop running and the patched runtime is loaded. Depending on the setup, this may include PHP-FPM, Apache, LiteSpeed, application pools or other PHP worker processes.

For containerised deployments, update the base image or PHP package, rebuild the image and redeploy it. Updating the host does not patch PHP that is bundled inside an existing container image.

2. Verify the running version

Do not rely only on the package manager reporting a successful installation. Confirm the PHP version used by the live website, check that the relevant workers have restarted, and verify that no older PHP runtime is still exposed through another domain or service.

Avoid leaving publicly accessible phpinfo() pages in production. If you create a temporary diagnostic page, restrict access and remove it immediately after verification.

3. Ask your hosting provider for confirmation

If you do not administer the server yourself, ask the provider to confirm:

• which PHP version and handler serve your website,
• whether the PHP2Shell security fixes have been applied,
• whether all relevant PHP workers and services have been restarted,
• whether any older or bundled PHP installations remain exposed.

A hosting provider's general statement that its platform is updated is not a substitute for confirming the runtime used by your specific website.

4. Use temporary mitigations only as a short-term measure

If an immediate update is not possible, follow the current mitigation guidance published by the PHP project and your hosting or security vendor. Depending on the application and deployment, temporary measures may include restricting public access, disabling functionality that is not required, or applying protective rules at a web application firewall (WAF).

These measures can reduce exposure to particular attack paths, but they do not provide complete protection and are not a replacement for installing the security update. Configuration changes can also affect uploads, application functionality, performance or availability. Test them carefully and prioritise patching.

5. Review logs and investigate suspicious activity

If a server was exposed while running a vulnerable version, consider a security review. Useful investigation areas include:

• web server, reverse proxy and WAF logs for unusual or malformed requests, especially unexpected multipart form submissions,
• PHP and web server error logs for unusual memory-exhaustion errors, repeated HTTP 500 responses or worker crashes,
• process and system monitoring for unexpected child processes launched by PHP or the web server,
• website files for unexpected PHP scripts, recently modified files or unfamiliar web shells,
• outbound network connections from the web server to destinations that are not part of normal operation,
• application accounts, administrator logins, API credentials and other authentication activity.

No single log pattern proves that PHP2Shell was exploited, and the absence of obvious indicators does not prove that a system is clean. Some exploitation paths may leave limited application-level evidence. If compromise is suspected, preserve relevant logs, involve a qualified incident-response specialist, and assess whether credentials and secrets accessible to the server need to be rotated.

6. Apply broader server security practices

Patching PHP should be part of a wider security programme:

• run PHP and web-server processes with the least privileges necessary,
• keep the operating system, web server, CMS, plugins, themes and dependencies updated,
• remove unused plugins, extensions, applications and exposed services,
• restrict administrative interfaces and use multi-factor authentication where available,
• keep tested, offline or otherwise protected backups,
• monitor server activity and maintain centralised logs,
• separate applications and environments where practical, and limit unnecessary access between them.

Does this affect WordPress websites?

Potentially, yes. WordPress is built on PHP, so a WordPress website can be exposed when it runs on a vulnerable PHP runtime. The same principle applies to Drupal, Joomla and custom PHP applications.

This does not mean that WordPress itself is the root cause of PHP2Shell. The vulnerabilities are in the PHP engine. Updating WordPress or installing a security plugin alone does not fix a vulnerable PHP runtime.

If your WordPress website is hosted by a provider, ask the provider to confirm the PHP runtime version and the status of the security update. If you manage your own server, update PHP and restart the relevant services.

Key takeaway

PHP2Shell is a critical reminder that website security depends on more than application code. A website may use a well-maintained CMS and still be exposed through the underlying runtime.

If your website uses PHP, check the actual runtime, install the appropriate security update, restart the affected services and verify the result. Do not rely on a CMS update, a WAF rule or a temporary configuration change as a substitute for patching.

If you are unsure which PHP version your website is running or whether your hosting environment has been patched, a technical review can help identify the relevant systems and prioritise remediation. You can read more on the page Network and server administration.

Official references and further reading

• PHP: Critical security advisory and fixed releases (21 October 2026)
• PHP: What is PHP? Official documentation
• Cyber Security Agency of Singapore: Critical Vulnerabilities in PHP (PHP2Shell)
• CERT-EU: Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Sophos: PHP2Shell security advisory and investigation guidance

This article is provided for general information and security awareness. It is not a substitute for a technical assessment of a specific server or application. PHP security guidance and vendor package status can change; consult the official PHP advisory and your provider before making production changes.