PHP2Shell Explained: What Website Owners Need to Know About This Critical PHP Vulnerability

Website security · PHP & Laravel · Checked 24 October 2026

A critical PHP security vulnerability can put websites, customer portals, and online stores at risk, even when their application code is well maintained.

On 21 October 2026, the PHP project released security updates for two critical vulnerabilities known as PHP2Shell. Tracked as CVE-2026-109618 and CVE-2026-109619, these flaws can allow remote code execution on affected servers. Security researchers have also reported exploitation attempts in the wild.

If your business uses PHP, WordPress, Laravel, or another PHP-based platform, checking your server's PHP version and applying the appropriate security updates should be a priority.

In this guide, we explain what the PHP2Shell vulnerability means, which websites may be affected, and how to improve your website security.

01 · OverviewWhat is the PHP2Shell vulnerability?

PHP2Shell refers to two critical security vulnerabilities in the PHP runtime, the software that executes PHP code on a web server.

Both vulnerabilities have a CVSS v4.0 severity score of 9.2 out of 10 and can potentially allow an attacker to execute commands on a vulnerable server without logging in.

These issues affect PHP itself, rather than only a particular website or application. This means that even a well-developed website may remain vulnerable if its server runs an affected PHP version.

The risk is particularly serious for certain Apache configurations using mod_php, where an attacker may trigger the vulnerability before the application's own code runs.

PHP announced the release one day in advance, on 20 October. The security firm watchTowr reports exploitation in the wild since 21 October, the day the fixes came out.

02 · ExposureWhich websites Are Affected by PHP2Shell?

Any website or application that uses PHP to answer web requests is in scope until its PHP build is fixed. That includes:

• WordPress websites: Business websites, blogs, and online stores running PHP.
• Laravel applications: Custom web applications, customer portals, booking systems, and business platforms.
• Other PHP frameworks: Applications built with Symfony and similar frameworks.
• E-commerce websites: Platforms such as WooCommerce, Magento, and Shopware.
• Custom PHP websites: Internal business tools and applications developed specifically for an organization.

The actual exposure depends on the PHP version, server configuration, and how the application is deployed. PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, and FrankenPHP deployments are among the environments that require attention. Managed hosting providers may already have applied the relevant security updates. However, businesses operating their own cloud servers or on-premises infrastructure need to verify that the correct patches have been installed.

Older websites deserve particular attention. An abandoned campaign page, outdated staging environment, or application previously maintained by another developer may still be running vulnerable software.

Look hardest at the servers nobody owns any more: a campaign microsite, an old staging copy, or a portal built by a vendor who has since moved on. If that last one sounds familiar, our guide to taking over a project from another vendor covers how to recover access.

03 · ImpactWhat could happen if a server is vulnerable?

Successful exploitation of a PHP remote code execution vulnerability can give an attacker the ability to run unauthorized commands on the affected server.

Depending on the server's permissions and configuration, possible consequences include:

• Data exposure: Attackers may access customer records, database credentials, configuration files, or API keys.

• Website compromise: Malicious code may be installed or existing website files may be modified.

• Unauthorized access: Attackers may attempt to establish continued access to the server.

• Service disruption: A compromised server may be used to disrupt services or attack other systems.

• Business and compliance risks: A personal data breach may trigger notification and other obligations under applicable data protection laws.

  
  

  
  

These are possible outcomes. A vulnerable server is not automatically a compromised one, and none of the official advisories lists confirmed breaches of specific sites. Exploitation has been reported, though, so an internet-facing server that is still unpatched needs attention today. A server that stayed unpatched for several days after 21 October also deserves a review of its logs and files.

04 · ActionHow to protect your PHP website

1. Find the PHP version that serves web requestsThe command line and the web server can run different PHP builds, so php -v in a terminal may not match what visitors hit. Check from the web side, or ask your hosting provider in writing.
2. Read the official advisory and your vendor's noticeIf PHP comes from your operating system (Ubuntu, Debian, Red Hat) or a control panel such as cPanel or Plesk, the vendor may ship the fix under its own version number. Their security notice tells you which build is fixed.
3. Update, then restart every PHP processInstall the fixed build and restart PHP-FPM pools, Apache, queue workers and other long-running PHP processes. A process that has not restarted is still running the old code.
4. Review the logsCheck web server and PHP-FPM logs from 21 October onward for unusual requests and worker crashes, and look for new or changed PHP files in web and upload folders.
5. Check backups, access and secretsConfirm you have a backup from before 21 October that you have actually restored in a test. If anything looks wrong, rotate database passwords and API keys, review who has server access, and follow your incident response plan.
6. Add a WAF as an extra layerA web application firewall filters requests before they reach the server and can block known attack patterns. It leaves the flaw in PHP untouched, so it supports the update and cannot replace it.

# command-line PHP (may differ from the web server)
php -v

# web PHP: put this in a temporary file, read
# "PHP Version", then delete the file

The PHP project lists these fixed releases for the two original PHP2Shell vulnerabilities:

05 · FrameworksDoes updating Laravel or WordPress solve the problem?

No. Laravel, WordPress, plugins and Composer packages are application code, and PHP2Shell sits in the PHP runtime underneath them. A WordPress site with every plugin up to date, running on PHP 8.3.35, is still exposed. The reverse holds too: patching PHP does nothing for an outdated plugin, so keep both current.

Laravel applications have one extra catch. The framework version limits which PHP versions you can run. If an old Laravel release keeps your application on PHP 8.1 or earlier, there is no php.net fix for your branch, and the lasting answer is an upgrade. Our application upgrade service moves Laravel and PHP versions forward one step at a time.

06 · ChecklistWhat should businesses do next?

• List every server and hosting account that runs PHP, including microsites and staging copies.
• Record the PHP version each one uses for web requests.
• Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or your vendor's fixed build, then restart PHP.
• Ask your hosting provider, in writing, whether and when they patched.
• Review logs and file changes since 21 October.
• Confirm you have a clean backup that restores.
• Plan upgrades for anything on PHP 8.1 or older.
• Watch php.net for the full CVE-2026-115560 advisory.

With one day's notice and exploitation reported from release day, there was little time to find out who looks after each server. A maintained application already has someone responsible for updates, a list of servers and their PHP versions, monitoring, and a backup that has been tested. Companies that supply software to Saudi government entities have a further reason: the NCA Essential Cybersecurity Controls include vulnerability and patch management.

Once the patch is done, a web application security audit or a vulnerability scan can confirm nothing else is left open.

Sources: PHP, Security advisory: critical remote code execution vulnerabilities and Informational advisory: session upload progress; GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; watchTowr, PHP2Shell FAQ; Sansec, PHP2Shell research.