PHP2Shell: What Happened, What to Do and How We Protected Sites on SeedCloud

On October 21, 2026, the PHP team released emergency versions to fix two critical flaws. With them, an attacker can take control of a web server without a username or password. Drupal runs on PHP, so any Drupal site that has not updated PHP is still exposed.¹

Here we sum up what happened, what you should check if you manage a Drupal site and what we did on SeedCloud, the managed hosting service from Seed EM.

What PHP2Shell Is and Who It Affects

PHP2Shell is the name given to two vulnerabilities in the PHP interpreter, registered in the CVE (Common Vulnerabilities and Exposures) system as CVE-2026-109618 and CVE-2026-109619. The PHP security team rated them 9.2 out of 10 on the CVSS v4.0 (Common Vulnerability Scoring System) scale, which is used to measure how severe a flaw is. They allow remote code execution on the server, without credentials.

Because the problem lies in PHP, it affects any application running on a vulnerable version: Drupal, WordPress, Magento or Laravel. It also doesn't matter how PHP runs on the server (PHP-FPM (FastCGI Process Manager), Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed).²

These are the fixed versions, released on October 21:³

Attacks began before the patch existed. Amazon recorded the first attempt on October 17, four days before the release.⁴ On October 26, the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its catalog of actively exploited vulnerabilities (KEV, Known Exploited Vulnerabilities).⁵

Why Updating Drupal Is Not Enough

Updates to Drupal core and its modules do not fix PHP2Shell. Drupal runs on PHP, and the flaw sits in that layer. In its PSA-2026-10-20 (Public Service Announcement), the Drupal Security Team reminded site owners that the server and any non-Drupal components are the responsibility of the site owner or their hosting provider.⁶

Sites on unsupported PHP versions, such as PHP 8.1 or PHP 7.4, face an additional problem. No ready-to-install release came out for them. The PHP project published source code patches, which the technical team has to apply, compile and test. They get you through the emergency, but the site remains on an unsupported version.⁷

And if the server was exposed before it was updated, you need to check whether anyone managed to get in.

What to Do Now

1. Check the PHP version of each site. If your hosting provider manages it, ask them to confirm in writing that the patch has been applied.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on your branch. If you are on 8.2, plan to move to 8.4 or 8.5 before December.
3. If you are on PHP 8.1 or earlier, apply the patch published for your branch (or ask your hosting provider to do it) and plan the migration, because those branches no longer receive new releases.
4. Look for signs of intrusion since October 17: server logs, new or unknown files and Drupal administrator accounts that no one on the team created.
5. Keep Drupal up to date. Maintenance releases 11.4.11, 11.3.20 and 10.6.20 of core also came out on October 21.⁸

How We Responded on SeedCloud

SeedCloud customers did not have to do anything. The Seed EM technical team took care of the following:

• On October 21, the same day as the release, we updated the entire infrastructure to fixed versions, such as PHP 8.3.36 and PHP 8.5.12. Sites running PHP 8.1 were moved that same day to PHP 8.2.35.
• Sites on PHP 7.4 needed the source code patch. While we prepared and tested it, we protected them with rules in the web application firewall (AWS WAF, Amazon Web Services Web Application Firewall), limited the maximum request size and disabled a PHP function those sites don't use. By October 23 they were running a patched PHP 7.4.
• We sent our main customers a report on the status of their site and the PHP version it ended up on.
• No deployment required a maintenance window and no site went down. We verified every site after each update, with no incidents, and detected no exploitation attempts.

With managed hosting, this work is the provider's job, not the customer's team. See how SeedCloud works.

What This Means for Organizations in Colombia

If your organization runs a Drupal site, whether it is a university, a public agency or a company, PHP2Shell is a good reason to review three things.

First, which PHP version the site runs on and who updates it. Many organizations keep track of Drupal versions, but not PHP versions. That responsibility should be written into the hosting contract.

Second, legacy sites. Drupal 7 has had no official support since January 2025, and many of those sites still run on PHP 7.4. In this emergency, protecting them required manual patches and temporary measures. If you have a site like this, it is worth planning a migration to a current version of Drupal.

Third, the next deadline. PHP 8.2 stops receiving security patches on December 31, 2026. Sites on that branch have two months to move.

Not Sure Which PHP Version Your Site Runs On?

If you manage a Drupal site and don't know which PHP version it runs on, or whether it is protected against PHP2Shell, we can review it with you.

Get in touch. You can also learn about our Drupal support and maintenance service or SeedCloud, our managed hosting for Drupal.

Sources

1. Help Net Security, Week in review. ↩
2. Patchstack, PHP security alert. ↩
3. The Drop Times, PHP 8.2 to 8.5 security releases and Drupal. ↩
4. BleepingComputer, Amazon detected attacks four days before the patch. ↩
5. The Drop Times, CISA adds PHP2Shell to its KEV catalog. ↩
6. Drupal Security Team, PSA-2026-10-20. ↩
7. watchTowr, PHP2Shell FAQ (patches for 7.4, 8.0 and 8.1). ↩
8. The Drop Times, Drupal maintenance releases of October 21. ↩

Published by Angie Vera, Seed EM · November 2026.