Drupal 10 End of Life: Your 4 Options After December 9th

Key Takeaways

• PHP2Shell was a flaw in PHP, not in Drupal, and Drupal’s own notice put the fix on site owners. If you self-host, Drupal security is three layers of software on three release calendars, and October delivered emergencies on all three inside eight days.
• Drupal 10 end of life is December 9, 2026. Roughly 77% of the Drupal sites W3Techs detects will be on an unsupported major version after that date, and you can’t skip from 10 to 12. The path runs through a Drupal 11 upgrade.
• A managed Drupal host takes the PHP layer off your plate. It doesn’t take core updates, module updates, major-version upgrades or the agency retainer.
• Agility is SaaS. There’s no CMS server for your team to patch, and one named company with a 99.9%+ SLA answers when something breaks. Moving costs more up front than a 10 to 11 upgrade, and it’s the last CMS upgrade project your team runs.

Drupal’s security history has always been patchy (get it?), but the recent PHP2Shell fiasco put things into perspective.

On October 21, 2026, at 14:00 UTC, the PHP project shipped an emergency release. Two flaws in PHP itself let a stranger on the internet run their own code on a web server with no password. PHP’s own release notes said there were “no complete mitigations, updating is the only safe choice.” PHP runs 69.2% of the websites whose server-side language W3Techs can identify, and it’s the language Drupal is written in. So every self-hosted Drupal site had the same urgent job that afternoon.

If you run Drupal yourself, your security depends on how fast your team can patch software it didn’t write. With Drupal 10 end-of-life landing on December 9, 2026, you’re about to run a CMS project anyway, or pay an agency a bunch of money to migrate you to Drupal 11, which also comes with an expiry date by design.

As expected, Drupal didn’t help its community with PHP2Shell

PHP2Shell is the nickname for two flaws, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 by PHP. Our CTO, Joel Varty, covers how the bugs work and exactly what to patch in his PHP2Shell post, so start there if you run PHP anywhere.

Wiz Research, one of the teams that found the bugs, says they reach every PHP version of the last decade, back to PHP 5.4, and that frontier AI models were “critical to making this process practical.” Read that twice. Flaws that sat unnoticed for ten years may now surface a lot faster, and Wiz demonstrated the attack against up-to-date Drupal, WordPress and Joomla before disclosure.

Drupal’s security team published PSA-2026-10-20 the same day. It called a patched PHP release “the only complete mitigation,” restated the team’s policy that site owners are responsible for their hosting platform and any non-Drupal components, and noted that the team’s remit covers only code hosted on Drupal.org. That’s a fair line, and the team deserves credit for clear guidance on a bad day. It also means the PHP layer was never Drupal’s to patch.

CISA went further. Its October 21 alert told organisations that couldn’t update, or were still on PHP 8.1 or older, to take those systems offline until they could. On October 26 it added both flaws to its Known Exploited Vulnerabilities catalog and gave federal agencies a deadline. Amazon’s threat intelligence team says the bugs are now broadly exploited, with a first attempt seen on October 17, four days before the patch existed.

Drupal security is three layers on three calendars

A self-hosted Drupal site is three layers your team keeps patched: the PHP runtime at the bottom, Drupal core in the middle and contributed modules on top. Each has its own release schedule. PHP2Shell sat entirely in the bottom layer, so a fully up-to-date Drupal site stayed exposed until someone updated PHP on every server and restarted every worker.

Look at what the other two layers did in the same month:

On October 14, a week before PHP2Shell, Drupal published SA-CORE-2026-014, a critical remote code execution fix in the Field UI module. Core alone wasn’t exploitable, but multiple exploit paths exist through contributed modules, and at least one needs no login. Fixes shipped for 10.6, 11.3 and 11.4 only. Sites on 10.5 or older got nothing, because those branches are already past Drupal end of life.

On October 21, the same day as the PHP patch, Drupal published 34 contributed-module advisories (SA-CONTRIB-2026-220 through 253), including a highly critical remote code execution bug in the Ffmpeg Image Toolkit module. On October 23, PHP published a third advisory for a related session issue, CVE-2026-115560, with the full fix held for the next regular release.

Three layers, three emergencies, eight days. What could possibly go wrong, guys!

It fits the year. Drupal has published 16 core security advisories on six release days in 2026, twice the eight it published in all of 2025. One of them, the highly critical SQL injection CVE-2026-9082 on PostgreSQL-backed sites, hit CISA’s exploited list on May 22, two days after the patch, with Imperva counting over 15,000 attack attempts against nearly 6,000 sites. And it isn’t new. After Drupalgeddon in 2014, Drupal told owners to assume any site not patched within seven hours was compromised. Drupalgeddon2 from 2018 is still on CISA’s catalog with known ransomware use.

None of this is a knock on open source. Researchers could read PHP’s code, which is how these bugs got found and fixed at all. It’s about who owns the server, and on a self-hosted Drupal site, every one of those advisories waits in your queue until someone tests and ships the fix.

“We’ll just move to a managed host”

This is the first thing most Drupal teams say, and I get it, it’s a fairly intelligent next step. But, there is a pretty sizable but.

A managed Drupal platform like Acquia or Pantheon patches the PHP runtime for you. For PHP2Shell, that’s a real advantage, and if you’re on one, the job on October 21 was reading their status page instead of SSH-ing into servers. Well, that’s the theory, anyway. In practice the platform owns the bottom layer and you still own the other two.

Core updates, module updates, custom code and the Drupal 11 upgrade are still yours, or your agency’s, and the agency bills for each one. On October 14, a managed host didn’t install SA-CORE-2026-014 on your site for you. Your codebase is still a single-tenant PHP application that someone has to keep current, and when the next major version lands, the migration project lands on your budget.

A managed host also doesn’t remove the end-of-life expiry date. In fact, Acquia ends support for Drupal 10.x on its platform on December 9, 2026, the same day Drupal does.

Drupal 10 end of life: You have four options

Drupal 10 reaches end of life on December 9, 2026. The core release schedule makes 10.6 the last minor release, so after that date new core advisories carry no Drupal 10 fix at all.

The numbers around that date are stark. Of the Drupal sites W3Techs detects, 28.9% still run Drupal 7, which lost support in January 2025, and 48.6% in total run a major version that’s already unsupported (that figure includes the Drupal 7 sites). Add Drupal 10’s 28.4% and roughly 77% of detected Drupal sites will be unsupported after December 9. The runtime lags too: 34.4% of the PHP sites W3Techs detects still run PHP 7 or older. PHP shipped minimal source backports for 7.4, 8.0 and 8.1, and nothing for anything older. PHP 8.2 itself reaches end of life on December 31.

So you’re running a project in the next six weeks either way. Here’s what each one costs now and what you still own afterwards.

Option	What it costs now	What you still own after
Upgrade to Drupal 11	Module compatibility work, testing, an agency sprint or two	PHP, core, modules, the next major upgrade in two years
Jump to Drupal 12	Not possible directly. Drupal’s upgrade path runs 10 to 11 to 12, and 12 ships the week of December 7	Same as above, plus release-week bugs on a brand-new major
Move to a managed host	Hosting migration, a higher monthly bill	Core, modules, custom code, major upgrades, the agency retainer
Migrate from Drupal to SaaS	Content modelling, migration, usually a new front end. More than a 10 to 11 upgrade	A front end. Nothing on the CMS side

The honest trade-off sits in that last row. Moving off Drupal costs more up front than a Drupal 11 upgrade. What you get for the extra spend is the last CMS upgrade project your team ever runs.

Why brands, organizations, and universities are choosing Agility CMS over Drupal

You model your content in Agility, move it across and connect your front end to our content APIs. If Drupal renders your pages today, that usually means building a new front end too, so scope that part first. Nobody should pretend it’s a weekend job.

After that, the editor, the APIs and the CDN are ours to run and patch. Agility is a SaaS platform on Microsoft Azure, one system we run and update for every customer at once, so nobody on your team installs a CMS patch or a major-version upgrade again. Our platform doesn’t run PHP, so PHP2Shell left nothing to patch on the CMS side. A PHP front end is still yours, and Joel’s post covers that.

When something does go wrong, you know which company answers for it. Enterprise plans include 24x7 critical support for outages and publishing problems, a customer success manager, a private Slack channel, security audit support and a 99.9%+ uptime SLA written into the contract.

For regulated teams: we’ve held SOC 2 Type II since December 1, 2021, recertified every year, with third-party penetration tests on the platform. Enterprise single sign-on runs through your own provider, and admins can enforce multi-factor authentication. Scotiabank has run on Agility since 2008, with staff signing in through the bank’s own Azure Active Directory and its security team auditing our platform independently every year. The feature-by-feature detail is on our Agility CMS vs Drupal page.

The next critical PHP or Drupal bug will land on somebody’s calendar. The only choice you get is whose. Send us the scope you’ve drafted for your Drupal 10 to 11 upgrade and we’ll show you what the same budget looks like as a migration instead, or ask for a free proof of concept built around your content.

FAQ

Is PHP2Shell a Drupal vulnerability?
No. The flaws are in PHP, and Drupal’s security team didn’t name Drupal core as affected. But Wiz demonstrated unauthenticated code execution against a current Drupal install before disclosure, so Drupal sites were squarely in scope even though no Drupal code was at fault.

Was my Drupal site hacked through PHP2Shell?
CISA added both flaws to its exploited catalog on October 26, and attack code is circulating, so an unpatched server is worth checking rather than assuming it’s clean. Joel’s post lists the compromise checks: unexpected child processes from PHP workers, new files in the web root, new cron jobs and accounts.

Should I upgrade to Drupal 11 or migrate off?
If your team is happy owning three patch calendars and a major upgrade every two years, upgrade to 11. If the October 14 and October 21 emergencies cost you days you didn’t have, that’s the signal to treat Drupal 10 end of life as the moment to change who owns the next one.

Can I skip Drupal 11 and go straight to Drupal 12?
No. Drupal’s upgrade policy requires moving through each major version in order, so a Drupal 10 site reaches 12 by way of 11. Drupal 12 ships the week of December 7, 2026, two days before Drupal 10 support ends.

Does a managed Drupal host make the deadline go away?
No. Acquia ends support for Drupal 10.x on December 9, 2026, in line with Drupal.org. A managed host patches PHP for you and keeps the platform running; the version your site is on is still your responsibility.

How long does it take to migrate from Drupal to Agility?
It depends on how much custom content modelling you have and whether the front end needs rebuilding. We build a free proof of concept from your content first, usually in a couple of days, so you see the shape of the migration before committing budget.

Is open source less secure than proprietary software?
No. CISA’s exploited-vulnerabilities catalog is led by proprietary vendors, with Microsoft alone past 380 entries, against five for Drupal. Exploited bugs follow how widely software is used, not how it’s licensed. What changes your exposure is who patches and how fast.