PHP2Shell: What PHP website owners should do now

2026-10-21T17:04:12Z

The PHP team has released security updates for two critical vulnerabilities that can let attackers run their own instructions on affected web servers without signing in. WordPress sites, Laravel and Symfony applications, and PHP-based shops all need their underlying PHP installation checked. An up-to-date application does not prove that the server runtime has been patched.

The flaws, CVE-2026-109618 and CVE-2026-109619, are discussed under the name PHP2Shell. Both have a CVSS v4.0 severity score of 9.2 out of 10. [2] [3] [8]

Ask your host or technical team: Have both CVEs been fixed in the PHP installation that actually serves my website?

The PHP project released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 with the fixes. A vendor may provide a security backport under a different package version. [1]

What does 9.2 out of 10 mean?

CVSS, the Common Vulnerability Scoring System, describes technical severity on a scale from zero to ten. Scores from 9.0 to 10.0 are critical, the highest category. The assessment considers how an attack can reach a system, what conditions it needs, and the possible effects on data and service availability. [13]

For these flaws, the published assessment describes a network attack requiring neither an existing account nor a user's involvement. It also assigns high attack complexity and additional attack requirements. 9.2 does not mean a 92 percent chance of being hacked. Exposure depends on the installation, configuration and reachable attack paths. The score does not establish that a break-in has already happened. [2] [3]

Beyond WordPress: Laravel, Symfony and larger PHP systems

PHP is the runtime that executes application code on the server. Laravel, Symfony and Laminas are frameworks used to build systems such as customer portals, booking tools and APIs. Updating their libraries does not replace a PHP runtime update. [14]

System	Examples	What could be at stake after a successful compromise
Websites and content systems	WordPress, Drupal	Content, publishing accounts and stored user information
Custom business applications	Laravel, Symfony, Laminas	Customer documents, account data and connected business processes
Online shops	WooCommerce, Shopware, Magento Open Source, Adobe Commerce	Orders, customer information and checkout behaviour

These products use PHP. This is not a finding that every installation is exploitable through the same path. The actual consequences depend on access rights and application design. [4] [14] [15] [16]

A Laravel or Symfony example: A business stores invoices and uploaded documents in a customer portal. If an attacker achieves code execution in the web process, files or databases accessible to that process could become accessible to the attacker. A login screen is not sufficient protection if the vulnerable request handling can be reached before authentication. This is a hypothetical damage scenario, not a report of a named victim.

What running code on a server actually means

A PHP website already runs code during normal visits: WordPress loads posts, a Laravel application processes a booking, and a shop creates an order. Remote code execution means an attacker can make the server execute additional, attacker-controlled instructions.

The following are possible consequences of a successful compromise. They depend on permissions, stored secrets, available services and permitted network connections:

Remote control through a reverse shell. The server opens an outbound connection to an attacker-controlled system, through which the attacker can send further commands and receive results. The outbound connection must be possible. Commands initially run with the compromised process's rights, not automatically with administrator or root privileges. [18]
A later entry point through a webshell. With sufficient write access, an attacker could leave malicious code in a website file that the server can execute. Subsequent web requests can invoke it. A PHP update does not remove that file. A reverse shell connection is a different mechanism and does not automatically survive a restart. [17]
Data theft. An attacker could copy customer names, addresses, orders or documents if the process can read them or access the relevant database. Application configuration can contain database connection details. [9]
Website manipulation and SEO spam. Write access could allow altered content, fraudulent login pages or unwanted advertising pages. SEO spam uses injected content to draw search visitors towards the attacker's offers.
Spam and phishing emails. If mail sending or usable mail credentials are available, the server could send unwanted or fraudulent messages. An abused sending IP being blocked can also disrupt legitimate business email. [19]
Botnet participation and DDoS. A botnet is a group of remotely controlled machines. The server could help overwhelm another service with traffic while its own website still appears normal. [19]
Cryptomining and proxy abuse. Attackers could use computing power to mine cryptocurrency, or bandwidth to relay other traffic. Slow applications, exhausted quotas and additional usage-based charges are possible consequences. Permissions and network access determine what is feasible. [17]
Deleted or encrypted files. With the necessary write permissions, attackers could damage application files or accessible data. Recovery depends on usable backups and a clean environment. [19]

These are post-compromise scenarios, not confirmed activities at a named PHP2Shell victim.

Recent cases show what the damage can look like

These investigations concern other compromises and entry paths. They illustrate documented consequences of malicious code on websites. Their dates are publication dates, not evidence of attacks using the current PHP2Shell flaws.

September 2026: a WordPress backdoor returned after removal

On 30 September 2026, Sucuri described a WordPress infection whose backdoor returned within seconds of deletion. Components were distributed across files, the database and shared memory, allowing surviving components to restore others. The investigated code could also create a hidden administrator account. Deleting the visible malicious file did not end access. [10]

May 2026: repeated spam redirects traced to a server backdoor

A Wordfence investigation published on 20 May 2026 described a WordPress site opening spam pages in new browser tabs. Removed code returned within hours. A server investigation eventually found a root-level backdoor around webmail software. That privilege escalation belonged to this specific incident; it is not an automatic consequence of every PHP flaw. [11]

March 2025: stolen checkout information in a WooCommerce shop

On 14 March 2025, Sucuri reported malicious checkout code sending card and billing information to another server, alongside a hidden PHP backdoor. Customers had reported unusual card activity after shopping there. The report did not establish the original entry method or a reliable financial loss total. Ordinary shoppers were affected by the shop's compromise. [12]

Why an updated application can still sit on vulnerable PHP

Application updates, plugin updates and PHP updates are separate maintenance tasks. The host determines which runtime packages are available. Managed hosting can include runtime maintenance, but operators should obtain confirmation that the fix is deployed. [4]

For example, a fully updated WordPress installation could still use PHP 8.3.35 without a vendor security backport. New WordPress files do not fix the runtime underneath them. The same separation applies to Laravel, Symfony and PHP-based shops.

The official advisory describes a demonstrated attack against Apache with mod_php that starts before application code runs. Application-level protection may therefore act too late for that path. A WordPress maintenance plugin is not reliable isolation of vulnerable PHP. [2]

What is established about the vulnerabilities

CVE-2026-109618 concerns memory exhaustion interrupting initialization of internal request data. CVE-2026-109619 involves internal state surviving beyond the lifetime of its backing memory and being reused by a later request. Both can lead to attacker-controlled code execution. [2] [3]

Describing the issue solely as an upload-progress flaw is incomplete. session.upload_progress is involved in confirmed paths, but the reports describe others. The initial rights are those of the PHP web process. CERT-EU's early warning described potential exposure going back to PHP 5; release decisions should now follow the fixes and vendor guidance for the actual package. [3] [5]

Which PHP versions contain the fixes?

Release branch	Fixed release
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Source: PHP's 21 October 2026 security announcement. PHP 8.1 and older no longer receive normal updates from the PHP project. Exceptional minimal source backports for 7.4, 8.0 and 8.1 do not replace installing a corrected package or planning an upgrade to a supported branch. Distribution and LTS customers should request confirmation for both CVEs. [1]

What website operators should do now

Name the owner. Identify whether the host, agency or internal team can patch PHP. One person should collect confirmation for every affected website.
Check the actual web runtime. In WordPress, look under Tools → Site Health → Info → Server. For custom applications, ask the responsible team for the production web service's package and patch status. [4]
Arrange the security update. Where possible, patch within the current supported branch first. A larger version upgrade with old plugins needs a separate compatibility check. Keep a usable backup and run a focused functionality check.
Verify deployment. Obtain the package version or vendor backport reference, confirm all relevant processes use it, then check login, forms, uploads and checkout.
Contain unpatched systems. If patching cannot happen promptly, the technical team should assess isolation from public networks. A static maintenance page can remain visible if requests genuinely stop reaching vulnerable PHP. [5]

A message you can send to your host

Please confirm whether CVE-2026-109618 and CVE-2026-109619 are fixed in the production PHP installation serving my domain or application. Which package version or security backport is active? Do all affected web processes use the corrected runtime? If not, when will you update it, and how will the site be protected until then?

Why one configuration setting is not a complete fix

Disabling session.upload_progress.enabled blocks confirmed session paths for CVE-2026-109619 only when the setting applies early enough and every worker is restarted. Other paths remain. Application-level ini_set() is not sufficient for this purpose. [3]

The PHP team states that only an update completely addresses the vulnerabilities. Firewall rules and filters are additional controls. A normal-looking website or one negative online test does not prove that its runtime is fixed. [1]

A deployment checklist for Laravel, Symfony and other PHP applications

The following is operational guidance based on the published findings:

Check the web service, not just the terminal. php -v reports the invoked CLI binary. The website may use a different PHP-FPM pool, container or server.
Inventory all instances. Include production, publicly accessible staging, old subdomains and PHP-based administration tools. Updated container images must actually be deployed.
Renew running processes. Updated files alone do not prove that workers and long-running processes use the corrected runtime.
Separate library and runtime updates. composer update installs application dependencies; PHP itself is a separate deployment component.
Record evidence. Keep package identifiers, vendor references covering both CVEs, deployment scope, restarts and functionality checks.

Should you switch languages or platforms?

My assessment: Patching takes priority during the incident. Moving to Node.js, Python or another platform is a separate migration project with testing and new operational responsibilities. A language change offers no blanket security guarantee.

Situation	What to assess after patching
WordPress works and updates are reliable	Continue with clear ownership of PHP, plugins, backups and emergency updates.
A simple company website or blog without customer accounts	Consider static generation, for example with Astro. Prebuilt HTML can be served without executing PHP. [6]
A shop or feature-rich business application	Compare managed operation with self-hosting, including patch ownership and response times.
An old custom application repeatedly blocks updates	Assess modernization or migration, including budget, data transfer, integrations and maintenance.

A new frontend does not remove an old backend. If WordPress remains publicly reachable as a CMS or API, its PHP installation still needs maintenance. [7]

A patch does not settle whether an earlier break-in happened

Patching closes the flaws. It does not automatically remove planted malware or undo stolen credentials. Unknown accounts, changed files and suspicious processes warrant a separate investigation. A lack of suspicious log entries is not proof of a clean system. [3]

Investigators should also examine outbound connections, mail activity and load spikes. Where compromise is suspected, isolate the server, preserve logs and investigate both the entry point and any retained access or exposed credentials. [17] [19]

Sources and reporting method

This article synthesizes publicly available primary sources. It does not report original exploit testing or an investigation of affected customer systems. Operational recommendations and platform comparisons are the author's assessment. Check for newer vendor guidance before acting at a later date.