PHP2Shell for Drupal and Joomla sites: a guide for public sector teams

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets an unauthenticated request run code on the PHP runtime underneath Drupal and Joomla sites. No Drupal or Joomla release fixes it. Whoever runs the server must move PHP to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport, restart PHP, or take the site offline.

On 21 October universities, school platforms and government portals across Europe went dark while they waited for the fix. Many such estates run Drupal and Joomla, often old versions spread across faculty and agency servers. This post covers what the two projects said, how to find the PHP your sites really use, what multisite and hosting change, and the patch or go offline call.

For the flaws themselves, start with our PHP2Shell explainer. This post does not repeat it.

What the Drupal and Joomla projects said

Drupal: PSA-2026-10-20

The Drupal Security Team published PSA-2026-10-20, dated 21 October, about the PHP release at 14:00 UTC that day. It tells site owners to set aside time to update PHP. If you manage PHP yourself, you apply the update. If your host manages PHP, follow the host's notices on timing and any steps you need to take. The PSA says in bold that a patched PHP release is "the only complete mitigation".

The PSA restates the team's policy that site owners are responsible for third-party components and the hosting platform, and that the team covers only code hosted on Drupal.org; it issues PSAs about outside software only rarely. It does not say Drupal is vulnerable, list CVEs or name affected PHP versions, and it says it is likely to be updated.

Note the timing. On 14 October the same team shipped SA-CORE-2026-014, a critical remote code execution fix in Drupal core. A site that skipped it and is waiting on PHP has two unrelated critical gaps open at once.

Joomla: no project statement found

We could not find a Joomla project statement on PHP2Shell. The announcements page on joomla.org and the developer security centre returned server errors when we tried them on 21 October, and web searches found no Joomla advisory. Joomla's latest releases, 6.2.0 and 5.4.10 on 13 October, predate the PHP fix. None of that changes the facts: Joomla runs on PHP, and PHP's advisory says every installation serving web requests is at risk.

Wiz tested both CMSs

Wiz, one of the research teams credited with the find, says it demonstrated unauthenticated remote code execution against Drupal and against Joomla, using the drupal:latest and joomla:latest container images at the time of testing. Wiz says the CMSs were representative targets; exploitation does not require them. Its timeline puts RCE against Drupal on 20 August and the report to PHP on 24 August.

Why a CMS update or maintenance mode does not help

PHP's advisory says that on Apache mod_php an unauthenticated request can trigger the attack "before any application code runs". The weak points are in how PHP parses a request and cleans up after it. Drupal's bootstrap and Joomla's router come later.

Three consequences follow for CMS teams:

1. Updating Drupal core or Joomla does nothing for PHP2Shell. Do those updates anyway, especially SA-CORE-2026-014, but they do not close this.
2. Drupal maintenance mode (drush maint:set 1) and Joomla's Site Offline setting do not protect you. Both are features of the application. PHP still receives and parses every request before Drupal or Joomla decides to show the offline page. Taking a site "offline" this way leaves the vulnerable path exposed.
3. Hardening inside the CMS has no effect. Security modules and two-factor login sit above the bug.

To take a site offline, stop the request before PHP: at the load balancer, CDN, firewall or a web server config with no PHP handler.

Which sites are most exposed

The biggest risk in public sector and university estates is not the patch itself. It is old CMS versions that pin old PHP versions, which PHP no longer fixes.

The Drupal figures come from Drupal.org's PHP requirements page, which also says no supported Drupal version runs on any PHP 7. The Drupal 7 date is from PSA-2025-01-06, which says Drupal 7 vulnerabilities may now be published without advisories.

Joomla 6 figures are from the Joomla manual; Joomla 5 figures are from mysites.guru; support dates are from endoflife.date.

Two numbers show why this matters. mysites.guru reported that 23.9% of the Joomla sites it monitors were on PHP 8.1 or older on 20 October, which gets no official PHP fix. VirusTotal, looking at internet-facing servers that disclose their PHP version, counted about 758,000 on end-of-life branches against about 272,000 on supported ones. VirusTotal also notes that roughly four in five PHP servers hide their version, so the real picture is less clear.

A Drupal 7 or Joomla 3 site cannot simply move to PHP 8.4. It needs either a backported PHP fix from a vendor, PHP's minimal source backport built by you, or to come off the internet until a migration happens.

Check what PHP your sites really run

Check the PHP that serves web pages, not the PHP your shell uses. mysites.guru puts it plainly: the CLI binary and the one serving pages are often different builds.

Drupal: Drush and the status report

1. Ask Drush for the basics. Run it from the project root.

vendor/bin/drush status --fields=drupal-version,php-version,php-bin,php-conf

Drush runs on the command line, so php-version and php-bin describe the CLI PHP. That is useful for cron and deploy scripts, but it is not proof that your web workers are patched.

2. Check the web runtime in the admin UI. Log in as an administrator and open /admin/reports/status. The PHP row shows the version as seen by a web request. Then open /admin/reports/status/php, which shows the full PHP information page for the web runtime. Look at "PHP Version" and "Server API". Acquia documents a case where the status report showed the wrong PHP version and /admin/reports/status/php showed the right one, so trust the second page.

3. On distro packages, check for the backport. A distro may fix the CVE without changing the upstream version string.

apt changelog php8.3-fpm | grep -m1 CVE-2026-109618     # Debian and Ubuntu
rpm -q --changelog php-fpm | grep -m1 CVE-2026-109618   # RHEL family

4. Note when PHP last started. A patched package does nothing until the workers restart.

systemctl status php8.3-fpm | grep -i active

Joomla: System Information and the CLI

1. Use the admin screen. In the administrator, open System, then System Information. The System Information tab lists the PHP version, the web server and the "WebServer to PHP Interface", which tells you whether you are on mod_php (apache2handler), FPM or CGI. The PHP Information tab shows the full phpinfo output for the web runtime.

2. Use the CLI for scripts. Joomla 4 and later ship a console at cli/joomla.php. Run php cli/joomla.php list to see the commands your install offers. Like Drush, it runs on the CLI PHP, so it tells you nothing about the web runtime's version.

3. Do not rely on the outside view. You can check a response header, but VirusTotal points out that expose_php = Off hides the version, not the vulnerability.

curl -sI https://www.example.gov/ | grep -i x-powered-by

An empty result means nothing. Check from inside.

Multisite, shared codebases and university hosting

Drupal multisite

A Drupal multisite serves many sites from one codebase, with each site in its own folder under sites/ and sites.php mapping hostnames to folders. In most setups every site shares one PHP runtime, which cuts both ways. One patch and one restart fixes them all. One missed pool exposes them all.

List the sites, then check each one:

cd /var/www/drupal                         # project root
grep -E '^\s*\$sites\[' web/sites/sites.php
ls -d web/sites/*/

# multisite-hosts.txt: one hostname per line, taken from sites.php
while read -r host; do
  echo "== $host"
  vendor/bin/drush --uri="https://$host" status --fields=drupal-version,site,php-version
done < multisite-hosts.txt

Drush's docs say the uri value should match what a browser uses. Then confirm which PHP pool each hostname actually reaches, because some estates run faculties on separate pools or even separate PHP versions behind one codebase:

grep -H '^listen *=' /etc/php/*/fpm/pool.d/*.conf
grep -RhoE 'proxy:unix:[^|"]+|fastcgi_pass [^;]+' \
  /etc/apache2/sites-enabled /etc/nginx/sites-enabled 2>/dev/null | sort | uniq -c
apachectl -M 2>/dev/null | grep -i php     # is mod_php loaded?

Finding every install on a shared server

University and council web servers often carry sites nobody remembers. Search the disk for the files that identify each CMS and its version:

# Drupal 8 to 12
find /var/www /srv -path '*core/lib/Drupal.php' 2>/dev/null \
  -exec grep -H 'const VERSION' {} \;

# Drupal 7
find /var/www /srv -path '*includes/bootstrap.inc' 2>/dev/null \
  -exec grep -H "define('VERSION'" {} \;

# Joomla 3.8 and later
find /var/www /srv -path '*libraries/src/Version.php' 2>/dev/null |
while read -r f; do
  echo "${f%/libraries/src/Version.php}: $(grep -oE '(MAJOR|MINOR|PATCH)_VERSION *= *[0-9]+' "$f" | grep -oE '[0-9]+$' | paste -sd. -)"
done

Older Joomla 3 releases keep their version in a different file, so treat a server with Joomla folders but no match as "check by hand".

Who patches PHP in each hosting model

mysites.guru reported that cPanel's EasyApache 4 had fixed packages within minutes of release. Linux Compatible reported that the sury.org repository, widely used on Debian and Ubuntu, shipped 8.2 to 8.5 fixes and backports for older branches back to 5.6 on 21 October. It advises reading the changelog before deploying a backport, since it is not an upstream release. PHP itself said the volunteer Remi repository would not have release-day updates.

For containers, Wiz's tests used the official drupal and joomla images. Check yours, then rebuild with a fresh pull:

docker run --rm --entrypoint php your-registry/drupal-site:prod -v
docker build --pull -t your-registry/drupal-site:prod .

Our guide to rebuilding PHP Docker images after PHP2Shell covers tags and caches in depth.

Patch or go offline: the public sector decision

What institutions did on 21 October

• University of Freiburg took PHP systems offline as a precaution, according to an IT services notice timed 10:39. That covered its relaunched WordPress sites, all sites on other data centre web servers, services behind its MyLogin sign-in such as the intranet, the ILIAS learning platform and student webmail. It told departmental admins to find their PHP services and restrict access or take servers offline until updates landed.
• Tampere University and TAMK in Finland warned they might take websites offline or restrict services to VPN users while no update existed.
• Belgium: The Brussels Times reported that the school platform Smartschool, AZ Monica hospital and several government sites went offline, and that the Centre for Cybersecurity Belgium advised going offline if sites could not patch at once.

Our post on governments taking websites offline over PHP2Shell covers the agency advice and a general decision checklist. Here is how it applies to Drupal and Joomla estates.

Decision table

How to go offline properly

Remember that Drupal maintenance mode and Joomla's offline setting still run PHP. Stop the request earlier:

1. Take a static copy first, if the content is public. It keeps opening hours, contact details and notices online.

wget --mirror --convert-links --adjust-extension --page-requisites \
  --no-parent https://www.example.gov/

Forms, search and logins will not work in the copy. Say so on the page.

2. Swap the virtual host for one with no PHP handler. On nginx:

# example-offline.conf: serves a static notice, never passes to PHP
server {
    listen 443 ssl;
    server_name www.example.gov;
    ssl_certificate     /etc/ssl/example.gov.crt;
    ssl_certificate_key /etc/ssl/example.gov.key;
    root /var/www/offline;
    error_page 503 /index.html;
    location = /index.html { }
    location / { return 503; }
}

On Apache, disable the site and enable an equivalent static vhost with a2dissite and a2ensite, and make sure mod_php is not loaded for it. Returning 503 tells search engines the outage is temporary.

3. Or block at the edge. A load balancer or CDN rule that serves a static page keeps traffic away from the origin entirely. Make sure the origin is not reachable directly by IP, as VirusTotal and mysites.guru both warn.

4. Keep the host running. You want its logs for the checks below.

After patching: Drupal and Joomla checks

1. Restart PHP and verify in the UI. Restart FPM, or fully stop and start Apache for mod_php, as mysites.guru advises. Then reload /admin/reports/status/php or the Joomla System Information tab. Our guide to finding and patching every PHP runtime has restart and verification commands for each platform.

2. Look for files that should not be there. Patching itself changes files, so compare against your deploy.

find /var/www/drupal/web -name '*.php' -newermt '2026-10-20' -ls
find /var/www/drupal/web/sites/*/files -name '*.php*'        # should be empty
find /var/www/joomla/images /var/www/joomla/tmp -name '*.php*'

3. Check for new administrator accounts. On Drupal with MySQL or MariaDB:

vendor/bin/drush sql:query "SELECT uid, name, FROM_UNIXTIME(created) FROM users_field_data ORDER BY created DESC LIMIT 20"

On Joomla, query the users table with your prefix from configuration.php, for example SELECT id, username, registerDate FROM abc_users ORDER BY registerDate DESC LIMIT 20;.

4. Rotate secrets if the site was exposed and unpatched. As our explainer notes, reporting says the flaws can also leak worker memory. On Drupal that means the database credentials and hash salt in settings.php; on Joomla, the database password and the secret in configuration.php, plus any API keys either stores.

5. Bring sites back in stages, read-only pages first, then forms and logins.

What would have helped

Practices any team can use

• A register of every CMS install. Hostname, CMS and version, PHP version and SAPI, server, owner, and who can take it offline. The find commands above are a start; keep the output somewhere central.
• Track CMS end of life with PHP end of life. A Drupal 7 or Joomla 3 site is a PHP problem waiting to happen. Drupal 10 and PHP 8.2 both reach their end in December 2026, so plan now.
• Edge-level offline switches, tested. Every public site should have a prepared static vhost or CDN rule that skips PHP. Run it once a year.
• A standing instruction for decentralised admins. Freiburg's notice is a good template: find your PHP, restrict or go offline, patch when ready. Name in advance who can pull a public site, and write into hosting contracts who patches the runtime and how fast.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell and it does not patch PHP on your servers. It helps with knowing where PHP is and making the change.

• Scanning images and SBOMs. safeguard scan --image <name> builds an SBOM of a container image and matches components against vulnerability databases; safeguard scan --sbom <file> does the same for an SBOM a hosting provider or agency gives you, and safeguard scan --dir . covers a repository. Results are JSON under ./output. When PHP is compiled from source inside an image, as in the official images, confirm with php -v as well.
• "Which projects ship this version?" The platform shows which projects contain a given component and version, so a list of Drupal and Joomla images still on an old PHP is one query rather than a hunt. See SBOM incident response.
• Gates. Policies and gates evaluated in the platform can stop an image with a vulnerable PHP from shipping again.
• Making the change with approval. The Safeguard CLI's assistant can edit a Dockerfile to a patched base image, run the Drush and find checks above, and run your build and tests, asking before each command under its default mode. You can send that work from the desktop or phone app to a computer running the CLI and approve each step there.

Where it does not help: PHP on shared or managed hosting you cannot inspect, sites nobody has scanned, restarting workers across a fleet, blocking traffic, or detecting a break-in. Reachability analysis does not lower the priority either, since the bug fires before Drupal or Joomla code runs. Database matching can lag a same-day advisory, and distro backports make version matching noisy, so confirm against your vendor's changelog.

Zero-Day Discovery and Gold

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.
• Gold Open Source (gold.safeguard.sh, free, no login) offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action.
• Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3+ and Sigstore-signed, with evidence pages; an artifact loses its badge on regression. The habit it supports is the one that mattered on 21 October: pull patched, signed components from a curated source and rebuild fast.

To try the CLI, download Safeguard at https://safeguard.sh/download and read the CLI docs at https://docs.safeguard.sh/docs/cli .

Common mistakes and troubleshooting

• Trusting drush status or php -v. Both report the CLI PHP. Check /admin/reports/status/php or Joomla's System Information.
• Using maintenance mode as the offline switch. PHP still parses every request. Block before PHP.
• Patching one pool in a multisite. Map every hostname to its pool first.
• The admin screen still shows the old version. Workers have not restarted, or the site uses a different pool or PHP version than the one you patched. Check the FPM master start time and the vhost's handler.
• The status report and the PHP info page disagree. Trust the PHP info page; Acquia documents a module-defined value causing this mismatch.
• Forgetting the origin IP. A CDN rule does nothing if attackers can reach the server directly.

FAQ

Did the Drupal Security Team say Drupal is vulnerable?

No. PSA-2026-10-20 says PHP is releasing a critical fix, that site owners should update PHP, and that updating is the only complete mitigation. It says the hosting platform is the site owner's responsibility and does not describe Drupal itself as vulnerable.

Has Joomla published guidance?

We found none as of 21 October, and Joomla's own sites returned errors when we checked. Joomla still runs on PHP, so the PHP update applies.

Is my Drupal 7 site safe if the host patched PHP 8.4?

Only if the site actually runs on that patched PHP. Many Drupal 7 sites sit on older PHP, which needs a vendor backport. Check /admin/reports/status/php.

Does Drupal maintenance mode protect against PHP2Shell?

No. PHP processes the request before Drupal shows the maintenance page. The same applies to Joomla's Site Offline setting.

We run 40 sites on one Drupal multisite. Do we patch 40 times?

Usually once, if all sites share one PHP pool. Confirm by mapping each hostname to its FPM socket or Apache handler, then verify a few sites in the admin UI.

Should a university take faculty sites offline?

If a site is public, unpatched and nobody can verify a fix, going offline at the edge is defensible, as Freiburg did. Bring it back in stages once patched.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These demos are real sessions on other tasks, not PHP2Shell; each intro says how the same flow applies.

The first shows the Safeguard CLI fixing a lodash CVE in a Node repository. It reads the finding, asks before each command, edits the dependency, runs install and tests with approval, and pushes nothing. For a Drupal or Joomla site in a container, you would ask it to move the Dockerfile to a patched PHP base tag, rebuild and run your tests, approving each command the same way.

Click through it at your own pace, or open it full screen.

The second is the desktop app. A CLI session shows in the conversation list, you ask for work on your computer, pick the folder, and approve or deny each command and file edit, ending with an upgrade done and tests passing. For a multisite, the folder is the Drupal project root and the work is running the Drush loop above and reporting which hostnames still show an old PHP, each step waiting for your yes.

Click through it at your own pace, or open it full screen.

The third is a real Android session: you send work to a computer running the CLI and approve a command on the phone with Allow once, Allow for turn or Deny. On a day like 21 October, the on-call admin could approve the static vhost swap or the worker restart from wherever they are.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Drupal Security Team: PSA-2026-10-20, Critical PHP update on 21 October 2026
• Drupal.org: Public service announcements list
• Drupal.org: Security advisories, including SA-CORE-2026-014
• Drupal.org: PSA-2025-01-06, Drupal 7 end of life
• Drupal.org: PHP requirements
• PHP news archive 2026: advance notice, advisory and releases (php.net)
• Wiz: PHP2Shell research
• Drush 13: core:status
• Drush 13: site aliases
• Drush 13: maint:set
• Joomla manual: technical requirements
• endoflife.date: Joomla
• mysites.guru: PHP's critical security release for Joomla and WordPress
• Acquia: Drupal status report does not display correct PHP version
• University of Freiburg IT Services: action taken on the critical PHP vulnerability
• Tampere Universities: web services may need to be taken offline
• The Brussels Times: Major websites go offline as critical PHP vulnerability triggers security fears
• VirusTotal: Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619
• Linux Compatible: Sury.org ships Debian and Ubuntu updates for PHP2Shell

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.