Drupal Critical Security Release, October 2026: What Site Owners Must Do

Drupal fixed a critical Field UI remote code execution flaw on October 14, 2026, rated 19/25. Which versions are safe, the stopgap and a patch checklist.

By the MakeItFlow team Updated 7 min read
Share LinkedIn X Facebook WhatsApp
Drupal Critical Security Release, October 2026: What Site Owners Must Do

On October 14, 2026 the Drupal Security Team released fixes for SA-CORE-2026-014, a critical remote code execution flaw in the core Field UI module, rated 19 out of 25. Anyone running a Drupal site should confirm it is on 11.4.10, 11.3.19 or 10.6.19 now. If you cannot update today, Drupal says uninstalling Field UI mitigates the flaw.

Drupal gave two days' notice that this release was coming and warned that exploits "might be developed within hours or days". If your site was not updated in the week of October 14, treat it as urgent.

Key takeaways

  • On October 14, 2026 Drupal fixed SA-CORE-2026-014, a critical remote code execution flaw in the core Field UI module rated 19 out of 25.
  • Safe versions are Drupal 11.4.10, 11.3.19 and 10.6.19; Drupal 11.2.x, 10.5.x and older, and Drupal 8 and 9, get no security fixes.
  • Drupal says at least one known exploit path needs no login, so update now or uninstall Field UI as a stopgap.
  • The same day brought two core XSS fixes and a critical Entity List fix, and a week later PHP itself needed patching.

What happened

On October 12, 2026 Drupal published PSA-2026-10-12, warning of a critical core security release on October 14 between 16:00 and 21:00 UTC. It said the issue affected all supported branches (11.4.x, 11.3.x, 10.6.x and 12.0.0-beta1) and urged site owners to "reserve time for core updates".

The release landed on schedule. The main advisory, SA-CORE-2026-014, describes the problem in plain terms: "A remote code execution vulnerability exists within the Field UI module in Drupal core." It is tracked as CVE-2026-108097.

Remote code execution is the most serious class of web vulnerability: an attacker who exploits it can run their own code on your server. From there they can change pages, steal data, add spam or plant a backdoor.

The advisory says Drupal core on its own is not directly exploitable, but contributed modules create "multiple serious exploit paths", and custom code can expose the same function. Most importantly, "at least one known exploit path does not require authentication." In other words, an attacker may not need an account on your site.

Affected and fixed versions

Your branch Status What to do
Drupal 11.4.x Affected below 11.4.10 Update to 11.4.10
Drupal 11.3.x Affected below 11.3.19 Update to 11.3.19
Drupal 10.6.x Affected below 10.6.19 Update to 10.6.19
Drupal 12.0 pre-releases Affected below 12.0.0-beta2 Pre-release only; keep off production
Drupal 11.2.x, 10.5.x and older End of life, no security coverage Upgrade to a supported branch
Drupal 8 and 9 End of life Plan a migration

The advisory lists the affected range as everything from 8.9.0 onwards up to the fixed releases, so long-forgotten Drupal 8 sites are in scope too, and they will never get an official patch.

The other October 14 fixes

The same day, Drupal's security advisories page listed four more fixes:

  • SA-CORE-2026-015 (moderately critical): Link field markup not sanitized in some cases, a cross-site scripting (XSS) flaw in core.
  • SA-CORE-2026-016 (moderately critical): Navigation module attributes not sanitized, another core XSS flaw.
  • SA-CONTRIB-2026-218 (critical): Remote code execution in the contributed Entity List module, where some exploit paths need no authentication.
  • SA-CONTRIB-2026-219 (moderately critical): Attributes not sanitized in the Gin admin theme.

Updating core covers the two core XSS issues. Entity List and Gin are separate projects, so they need their own updates if you use them.

And then PHP

A week later, on October 21, Drupal posted a further public service announcement (PSA-2026-10-20) about a critical PHP security release due that day. That is a problem in the language that runs Drupal, not in Drupal itself, so a Drupal update does not fix it. Our PHP critical security release guide explains which PHP versions are safe and what to ask your host. The same day, Drupal also published dozens of contributed module advisories, several of them rated critical, so check your module list as well as core.

Who this affects

  • Any organization running Drupal 8.9 or later that has not updated since October 14.
  • Sites with many contributed modules. Drupal says contributed modules are what turn the core flaw into a practical attack, so module-heavy builds carry more risk.
  • Agencies and IT providers looking after several Drupal installs for clients.
  • Owners of old Drupal 8 or 9 sites that "just work" and have not been touched in years. These get no fix and should be treated as exposed.

If you are not sure what your site runs, ask your developer or host.

The stopgap: uninstall Field UI

If you genuinely cannot update straight away, the advisory says "the vulnerability can be mitigated by uninstalling the core Field UI module" (machine name field_ui). Field UI is the admin interface for adding and editing fields on content types. Most sites only need it while building, so removing it temporarily rarely affects visitors. Reinstall it after you update if editors need it.

Drupal Steward, Drupal's web application firewall service, offers some protection, but the advisory warns it "will not cover all possible exploits". A general web application firewall can help too, as our guide to what a WAF does explains, but none of these replaces the patch.

Practical checklist

  1. Find your version. In the Drupal admin, open Reports, then Status report. Or run drush status on the server.
  2. Back up first. Take a copy of the database and files and keep it off the server. Our website backup guide covers what a usable backup looks like.
  3. Update core to the fixed release for your branch using your usual method (usually Composer), then run database updates and clear caches.
  4. Update Entity List and Gin if installed, and review the October 21 contributed module advisories against your module list.
  5. Uninstall Field UI if you are blocked, then schedule the real update.
  6. Ask your host about PHP. Confirm the server has the October 21 PHP fixes, separately from Drupal.
  7. Look for signs of compromise if the site sat unpatched for days: new admin accounts, unfamiliar files, changed pages or spam in search results. Our guide to the signs your website was hacked lists what to check first.
  8. Confirm the site still works. Check key pages return 200 with our free HTTP status checker, confirm the site is reachable with the website down checker, and make sure your headers survived the update with the security headers checker.

If your business has a backlog of CMS updates across several sites, the fix is a routine, not heroics. Our small business website security checklist sets out a monthly rhythm, and Make It Flow can help automate version checks and alerts so a person only steps in when an update needs a decision.

Frequently asked questions

Is the October 2026 Drupal flaw being exploited?

The advisory rates exploitability as "theoretical" at the time of publication, but Drupal warned before release that exploits might be developed within hours or days. Once a fix is public, attackers can study it. Assume unpatched sites are being probed and update without waiting.

My site runs Drupal 10.5. Will it get a fix?

No. Drupal says 11.2.x, 10.5.x and earlier are end of life and get no security coverage, and the same applies to Drupal 8 and 9. You need to upgrade to a supported branch such as 10.6.19 or later. Until then, uninstalling Field UI reduces the risk from this specific flaw.

Do I need to log in to be attacked?

Not necessarily. The advisory says at least one known exploit path does not require authentication. That is why it is rated critical: an outsider with no account on your site may be able to reach the vulnerable code through a contributed module.

Does updating Drupal also fix the October PHP vulnerabilities?

No. PHP is the language your server uses to run Drupal. The October 21, 2026 PHP fixes are a separate update that your host or server administrator must install. Check both: Drupal core in your admin and the PHP version with your host.

What does uninstalling Field UI break?

Field UI provides the admin screens for adding and managing fields on content types, comments and users. Existing fields and content keep working without it. Editors who need to change content structures will lose those screens until you reinstall the module after updating.

Sources

#drupal security #drupal update #website security #cms updates #remote code execution

More guides for your industry

Free checklist (PDF)

Free web developers website checklist

31 practical checks for web developers: website speed and mobile, Google Business Profile and reviews, email security, booking and enquiry handling, and AI search visibility. Each one says why it matters, and many link to a free tool that checks it.

We email you the PDF and nothing else unless you tick the box. See the privacy policy.

Written by the MakeItFlow team

We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 12 November 2026 . How we research and check

Share LinkedIn X Facebook WhatsApp

Check your own site in 30 seconds

Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.

Weekly newsletter

One practical website fix, every week

New guides on speed, SEO, email deliverability and security — straight to your inbox. No spam, unsubscribe in one click.

Keep reading