What is PHP2Shell? The critical PHP flaw and what to do now

What is PHP2Shell? It is the name given to two critical vulnerabilities in the PHP core that allow an attacker to take control of a web server without a username or password, and they are already being exploited. The fix is to update PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later; if your system depends on PHP 8.1 or an earlier version, there's no official fix and you need to take a different approach.

On October 20, 2026, details of two PHP vulnerabilities leaked before a patch existed. The next day, PHP released the fixed versions. In less than 48 hours, security firms such as watchTowr reported real-world attacks.

At DCisGlobal, we translate this into what matters for a business: what's at risk, how to tell whether it affects you, and what to do today, without going into how the attack works.

What is PHP2Shell, in business terms?

PHP powers a large share of SMB web systems. PHP2Shell isn't a flaw in a plugin or in one particular system: it's in PHP itself. That's why its reach is so broad.

In practice, an attacker can send requests to the site and get the server to run whatever they want. That opens the door to stealing customer data, installing malicious software, using the server to attack others, or taking the system offline.

What makes it worse is the timing: the details became public before the patch did. When that happens, the window to update calmly disappears.

Need this fixed now and have nobody to do it? At DCisGlobal, we handle PHP updates for PHP2Shell, including a review of anything that can't be updated. Message us on WhatsApp

How do you know whether your company is exposed?

The answer depends on one thing only: the exact PHP version on every server that runs a web system.

Any version below the fixed one for its branch is exposed. PHP 8.3.30, for example, needs the update just as much as an older version.

If nobody at the company knows which version each system runs, your hosting provider or technical lead can confirm it in minutes. That's the first step.

Why old systems are the most serious case

According to Sansec, the affected code has existed since PHP 5.4, released in 2012. That means systems that haven't been updated in years are also exposed, and for them there's no fixed version to install.

These are precisely the cases we see most often in assessments: a Vtiger 6 or 7, a Magento 1, a PrestaShop 1.6, a Joomla 3 or Drupal 7 site, a custom system built with CodeIgniter 3. None of them runs on PHP 8.2 or later without prior work.

For those systems, “upgrade PHP” isn't a single click: the system has to be updated or adapted first. We explain this in detail in Upgrading PHP: the risk of running an unsupported system, with the table of systems and versions.

What to do today, in order

1. Take inventory. List the company's web systems, which server each one runs on, and its exact PHP version.
2. Update what can be updated right away. Everything on PHP 8.2 to 8.5 gets moved to the fixed version for its branch. If your hosting is managed, ask the provider to confirm it in writing.
3. Isolate what can't be updated. For systems on PHP 8.1 or earlier: take them off the open internet (access only via VPN or from known addresses), confirm with the provider whether they applied the unofficial patch, and plan how to move off that version. PHP has published partial measures that reduce exposure, but stresses that they don't replace the update.
4. Change sensitive credentials. Because the flaws can expose server memory, rotate the database passwords, the API keys (payments, invoicing, email), and the admin sessions of the exposed systems.
5. Check for signs of intrusion. Ask your technical lead to review the server logs and running processes since October 20. If in doubt, treat it as an incident.
6. Plan a permanent fix. Systems that don't run on a supported PHP version will show up again in the next advisory. The real fix is to update, adapt, or migrate them.

Our service: PHP update for PHP2Shell

For companies that need to fix this now, we offer a one-off remote service for Spain and Latin America. It works the same whether you use shared hosting, virtual private servers (VPS), or your own servers.

What it includes:

1. Version review. We list every server and every web system in the company along with its exact PHP version, and flag what's exposed.
2. Update to the fixed version. We bring PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later. First on a test copy, checking that the system still works, and then in production.
3. A plan for what can't be updated. If a system depends on PHP 8.1 or earlier, we isolate it immediately, verify the provider's patch if there is one, and put together a plan to update or migrate it.
4. Credential changes. We rotate the database passwords, API keys, and admin sessions of the systems that were exposed.
5. Review for signs of intrusion. We review server logs and processes since October 20 to rule out or detect an attack.
6. Final report. What was updated, what's still pending, and what you should do next, in business language.

Message us on WhatsApp: PHP update for PHP2Shell

If you'd rather have a broader review of your entire infrastructure, there's our technology assessment.

If the system needs more than an upgrade (adapting the code, hardening it while you plan, or migrating it), see legacy system modernization.

What this case shows

PHP2Shell won't be the last flaw of its kind. What separates a company that fixes it in an afternoon from one that loses a week isn't luck: it's knowing which systems it has, which version they run on, and who can update them.

For today's emergency, there's our PHP update for PHP2Shell. To avoid falling behind again, software support and maintenance keeps every system up to date. And when replacing the system is the better option, we take it on through custom software development.