PHP2Shell: What Today’s Critical PHP Patch Means for Your Website

PHP2Shell: What Today’s Critical PHP Patch Means for Your Website

If your business runs a website on WordPress, Magento, Drupal, Joomla or almost any other popular platform, it runs on PHP. Today, October 21, 2026, the PHP project is shipping an emergency fix for two critical flaws, and security researchers expect attackers to move fast.

This post explains what happened, who is exposed, and how disciplined patching keeps an event like this from becoming an incident.

What happened

On October 20, the PHP security team gave advance notice of a release fixing two critical vulnerabilities, each rated 9.2 out of 10 under CVSS v4.0. The release is scheduled for 14:00 UTC today (10:00 AM Eastern). PHP says it may ship earlier if details go public or attacks appear.

The notice followed a leak. According to Ars Technica, unconfirmed details circulated alongside a video of an exploit tool called PHP2Shell running code on servers. Security firm watchTowr confirmed the flaws are real remote code execution bugs, tracked as CVE-2026-109618 and CVE-2026-109619.

The warning signs are serious:

  • Speed of attack: Sansec told Ars Technica it expects mass exploitation within about 15 minutes of the patch going public.
  • Possible early exploitation: Sansec’s timeline notes Cloudflare reported early attacks and deployed firewall rules on October 21.
  • Scale: One researcher cited by Ars Technica estimates about 1.3 million internet-connected hosts are likely affected.

PHP has not yet published root cause, affected versions or fixed version numbers. Those arrive with the release, so some details in this post may change.

Who is affected

Until PHP publishes the details, Help Net Security advises treating every PHP installation as potentially vulnerable. The leaked exploit was reportedly shown against WordPress 7.1.3, and Ars Technica lists MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal and WHMCS among the platforms at risk.

Two groups deserve special attention:

  • Managed hosting customers (for example, WP Engine). The flaw is in PHP itself, not in WordPress or your plugins. On managed platforms, the host controls the PHP version on its servers, so the fix has to come from them. At the time of writing, we had not found a public statement from WP Engine on its patch timeline; customers should check its status page or contact support.
  • Anyone on an old PHP version. Huntress reports that the flaws may reach back to PHP 5, while fixes are expected only for currently supported branches. A site on end-of-life PHP may have no patch at all.

How WheelHouse IT prepares for events like this

Emergency patches are stressful when they are the first time anyone has looked at a server in months. They are routine when patching is already a habit. Our approach rests on five practices:

  1. Know what you run. We keep an inventory of client systems and applications, so when a component like PHP is flagged, we can quickly see which environments use it and which version.
  2. Patch on a schedule, not on a whim. Regular update cycles keep systems on supported versions. That matters here: a site already on a supported PHP branch can take today’s fix, while one stuck on PHP 5 or 7 may have nothing to install.
  3. Back up before you change anything. Verified backups of site files and databases mean an urgent update can be rolled back if it breaks something.
  4. Coordinate with hosting providers. For clients on managed platforms, we track the provider’s response and confirm when their patch is in place, rather than assuming it is.
  5. Watch for signs of compromise. Patching closes the door; monitoring tells you whether anyone got in before it closed.

 

What to do right now

These steps follow the preparation guidance reported by Ars Technica and Help Net Security:

  • Identify who manages PHP for each of your sites: your team, your IT provider or your host.
  • List every PHP-based application you run, including staging sites and forgotten microsites.
  • Back up site files and databases before updating.
  • Plan a maintenance window starting at 14:00 UTC (10:00 AM Eastern), with a fallback in case PHP releases earlier.
  • If you use managed hosting, confirm with your provider when the patch will be applied.
  • Check whether any site is on an end-of-life PHP version and plan an upgrade.
  • Consider taking nonessential PHP systems offline until they are patched.
  • Watch php.net for the official affected and fixed versions.

The takeaway

PHP2Shell is a reminder that the most important security work happens before the headline. Businesses with current inventories, supported software versions and tested backups can apply today’s fix in a planned window. Businesses without them are scrambling.

If you are not sure which PHP version your sites run, or who is responsible for patching them, contact WheelHouse IT. We can help you assess your exposure and build update habits that make the next emergency patch routine.

Sources