Start a project ↗

October 22, 2026

Updating Your Plugins Won’t Fix php2shell. Do You Know Where PHP Runs in Your Business?

By Akram Abouzeid

On October 21, the PHP project released fixes for two critical flaws in the PHP engine, known together as php2shell. They let an attacker who is not logged in run their own code on a server that handles web requests with PHP.

Attackers did not wait. Amazon saw an exploit attempt four days before the fixes came out, and Cloudflare saw attack traffic aimed at its customers on release day.

PHP runs about 69% of websites whose server-side language is known, according to W3Techs. Most businesses run it somewhere. Some do not know it.

Updating your plugins will not fix this

These bugs live in the PHP runtime, the layer that runs the code, not in one app. Calif, one of the research firms, traced the affected code back to PHP 5.4. So WordPress, Drupal, Laravel and Magento sites are exposed whenever they sit on a vulnerable PHP version.

As Vercel’s advisory puts it, updating application code or plugins does not solve it. The PHP version on the live server has to change.

The fixes look like this:

  • Supported branches: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
  • PHP 7.4 to 8.1: no official release, only minimal source backports or packages from your Linux distribution or support vendor.
  • PHP 5.4 to 7.3: end of life, no fix from the PHP project.

If the app runs in containers, the image has to be rebuilt and redeployed, and PHP workers need a restart. A patched laptop does not count.

The hard part is knowing where PHP runs

Before you can patch, you need a list. PHP is often a component inside other software, where you cannot easily see it.

For a small or medium business, that list might include the company website, an online store, a customer or supplier portal, an internal tool someone built years ago, or a reporting add-on next to the ERP. Each one may be managed by a different hosting company, agency or vendor.

In ERP and custom software work, I have often seen this gap: the system works fine, but nobody is sure who is responsible for updating the server it runs on.

So the useful questions this week are simple. What do we run on PHP? Which version? Who updates it? If a system cannot be updated quickly, the safe option may be to take it offline until it is fixed. That is a hard call for a store taking orders, so it helps to know the answers early.

AI found it, and the clock got shorter

The flaws went unnoticed for more than a decade. Researchers at Calif and Wiz both say they used AI models to find them. Wiz wrote that frontier models let its team build working exploits across several applications in hours.

The ending was messy. The CVE identifiers leaked on October 20, and the PHP Foundation moved its release up by a day. Amazon Threat Intelligence reported an exploitation attempt on October 17, four days before public disclosure, and now says php2shell is being broadly exploited.

If AI helps defenders find old bugs faster, it can help attackers too. The gap between a fix and an attack is getting shorter, and a monthly or quarterly update routine may not be enough for anything that faces the internet.

Practical takeaways

If you own or pay for any web-facing system:

  • List every website, store, portal and internal tool, and find out which ones run PHP.
  • Ask your host, agency or vendor whether they have moved to a fixed version, and get the actual version number.
  • Start with anything public, like stores, portals and login pages.
  • Treat firewall rules as temporary. Cloudflare, which deployed rules for this, calls them a stopgap.
  • Review logs from at least October 17, as Amazon suggests, and look for PHP processes starting shells or downloading tools.
  • Write down who owns updates for each system, so the next one moves faster.

How does your team keep track of what runs where? I would like to hear if anyone has found a simple method that works for a small business.

Sources

← Back to field notes