PHP2Shell and Drupal: What Site Owners Need to Do

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the Drupal Security Team's public service announcement names updating PHP as "the only complete mitigation." Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a flaw in PHP, the language and runtime Drupal is built on. It is not a bug in Drupal core or in contributed modules. A Drupal site is exposed if the PHP build serving it is unpatched, and updating Drupal does not change that. What protects you is a patched PHP build on the server and a restart of every PHP worker.

This guide covers what researchers showed against Drupal, which PHP versions each Drupal release supports, why Drupal 7 sites need extra attention, and the steps to take today. For the full background, read what PHP2Shell is and who it affects.

Is Drupal Vulnerable to PHP2Shell?

Drupal is exposed through PHP, not because of its own code. PHP describes CVE-2026-109618 as out-of-memory handling that "can interrupt PHP while internal request data is only partially initialized," and CVE-2026-109619 as internal state that "can survive after its backing memory has been freed" and be used by a later request on the same worker. Both happen in PHP's own request handling.

The Drupal Security Team published PSA-2026-10-20, "Critical PHP update on Wednesday, October 21, 2026 (14:00 UTC)". It says "PHP has announced a critical PHP security release" and that the only complete mitigation is "Updating to a PHP release containing the patch to these vulnerabilities." It does not say Drupal core is vulnerable, and it reminds owners that "site owners are responsible for maintaining the security of third-party libraries." PHP is one of those.

The PSA also splits the job by who runs PHP: "If you manage PHP yourself, you'll need to apply the update." "If your host manages it, follow their communications for timing and any required action."

What Researchers Showed Against Drupal

Drupal was one of the first test targets.

• Wiz says it could "execute code remotely without authentication on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest)." Wiz's timeline says unauthenticated remote code execution was "confirmed against Drupal" on 20 August 2026. Per Wiz's write-up, its Drupal chain used the fatal-error backtrace bug, and an upload-progress chain worked against all three CMSs.
• Calif, which reported the first bug to PHP, lists Drupal 11.4.3 among the applications it confirmed.

Wiz is careful to add: "They are representative targets - exploitation does not require one of these CMSs." Drupal was used to prove the point that a normal, current CMS install is enough. Nothing in Drupal needs to be misconfigured.

The fatal-error backtrace detail matters for Drupal 11. PHP's advisory for CVE-2026-109619 calls the PHP 8.5 fatal error backtrace path "the strongest demonstrated case." The official drupal:latest image (Drupal 11.4.11 on PHP 8.5 with Apache, rebuilt 22 October 2026) runs exactly that combination. Our explainer on CVE-2026-109619 and stale global state covers the paths in more depth.

Drupal PHP Requirements by Version

Which PHP versions you can move to depends on your Drupal version. This table comes from Drupal's PHP requirements page (last updated 4 August 2026), with the PHP2Shell fixed release for each branch added.

Drupal's page says "Drupal 10 requires at least PHP 8.1." That is the trap for Drupal 10. A Drupal 10 site can be fully within Drupal's requirements on PHP 8.1, but the PHP project stopped updating 8.1 on 31 December 2025 and published no official 8.1 release for PHP2Shell. It published only minimal source backports for people who build PHP themselves. If your Drupal 10 site runs on PHP 8.1, either confirm your host or Linux distribution ships a patched 8.1 build, or move to PHP 8.3 or 8.4, which both Drupal 10 and Drupal 11 support.

If you are on PHP 8.2, update to 8.2.35 now, then plan the next move: PHP 8.2's security support ends on 31 December 2026. Drupal 11 doesn't support PHP 8.2 at all, so a Drupal 11 upgrade and a PHP upgrade often go together. The full branch-by-branch list, including distribution packages, is in PHP2Shell fixed versions.

Drupal 7 Sites on Old PHP

Drupal 7 is the highest-risk group. Drupal's Drupal 7 end-of-life page says "Drupal 7 security support has ended as of 5 January 2025," and calls that "the final extension." The Drupal Security Team no longer fixes Drupal 7.

Drupal 7 sites are often long-lived sites that were never moved to newer PHP. If yours runs on PHP 8.1, 8.0, 7.4 or older, there is no official PHP release that fixes PHP2Shell for it. Your options are:

1. Get a vendor-patched PHP build. Some Linux distributions and long-term support vendors have shipped fixed packages for old PHP branches. For example, Ubuntu lists fixed packages for PHP 7.4 on 20.04 and PHP 8.1 on 22.04 LTS, and cPanel's EasyApache 4 release covers ea-php74 through ea-php85. Ask your host which applies to you.
2. Use extended support for Drupal 7 itself. Drupal names "HeroDevs and Tag1 Consulting" as the certified vendors in its Extended Security Support Provider Program. That covers Drupal 7 code. It does not patch PHP on your server, so you still need step 1.
3. Take the site offline if neither is possible soon. CISA's 21 October alert says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." If you do, Beazley advises using "a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials."
4. Plan the migration. A supported Drupal release on supported PHP is the only long-term answer. Our Drupal security guide explains why Drupal's deadlines are unforgiving.

Who Patches PHP for Your Drupal Site

Our explainer on the shared responsibility model for websites helps if you're not sure where your host's job ends and yours begins.

Step-by-Step: What to Do Today

1. Find your PHP version. In Drupal, open Reports > Status report (/admin/reports/status) and look for the PHP entry. Your hosting panel shows it too. See how to check your PHP version for every method.
2. Don't trust the number alone. Linux distributions backport fixes without changing the version string. AlmaLinux: "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change." Also, the command-line PHP can differ from the PHP that serves your site. Check the package version, or ask your host.
3. Patch PHP. On a server you manage, install the fixed packages. Generic Debian or Ubuntu example: sudo apt update then sudo apt upgrade. On RHEL-family systems: sudo dnf upgrade.
4. Restart every PHP worker. For example, sudo systemctl restart php8.3-fpm (replace 8.3 with your version), or restart Apache if you use mod_php. Include queue workers and other long-running PHP processes.
5. Turn off session upload progress if you don't use it. Set session.upload_progress.enabled=0 in php.ini or the FPM pool, not with ini_set() or .user.ini, and restart. PHP's 23 October advisory recommends keeping it off until the next regular PHP release, because of a separate, unlikely issue (CVE-2026-115560) that also affects patched builds.
6. On PHP 8.5, consider fatal_error_backtraces=0 until you're patched. PHP says this "blocks the confirmed fatal backtrace path only."
7. Check for signs of compromise from at least 17 October 2026 onward. See was my site hacked through PHP2Shell.

The settings in steps 5 and 6 are partial. PHP says only an update "is a complete solution." Every setting and its side effects are covered in PHP2Shell interim mitigations.

What Updating Drupal or Composer Does Not Do

Running Drupal core or module updates, through Composer or otherwise, keeps your Drupal code current. It does not touch the PHP engine on the server. Cloudflare's advice applies to Drupal as much as to any CMS: "updating website code or a plugin(s) alone does not fix these vulnerabilities." Bitdefender adds that on mod_php, "CMS updates, plugin hygiene and application hardening do not change exposure."

For CVE-2026-109618 on mod_php, PHP's advisory says the problem "happens entirely before any application-specific code begins execution." That means no Drupal module, including a security module, gets the chance to run first. A web application firewall in front of the server can filter some attack requests. Cloudflare says its free and paid WAF customers have been protected by default since 21 October 2026, 03:02 UTC. That is useful, but partial. Use it to buy time, not as a reason to skip the PHP update.

Conclusion

As of 23 October 2026, PHP2Shell affects Drupal sites only through the PHP they run on. The Drupal Security Team has told owners to update PHP, and no Drupal update fixes the flaws. Confirm your PHP build is patched and restarted, watch for Drupal 10 sites on PHP 8.1 and Drupal 11 sites on PHP 8.5, and treat any Drupal 7 site on old PHP as urgent. If your team needs help patching a server quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions