The short answer: On October 14, 2026, Drupal released emergency security updates for a critical remote code execution flaw (CVE-2026-108097, advisory SA-CORE-2026-014) in its core Field UI module. If you run Drupal 10.6, update to 10.6.19. On Drupal 11.3, update to 11.3.19. On Drupal 11.4, update to 11.4.10. The flaw is not directly exploitable through core alone, but contributed modules or custom code can expose attack paths, and at least one known path requires no login at all. If you cannot patch right now, the official temporary mitigation is to uninstall the Field UI module until you can update.
What happened on October 14
The Drupal Security Team published a security advisory on October 14, 2026, rating a remote code execution vulnerability in the Field UI module as critical, with a score of 19 out of 25 on Drupal’s own risk scale. Field UI is the core module that provides the administrative interface for managing website fields and their display settings, so it ships with every standard Drupal installation.
The advisory (SA-CORE-2026-014) was unusual in one respect. The Drupal team stated plainly that the vulnerability is not directly exploitable with Drupal core alone. The risk comes from interaction: contributed modules and custom code can expose the vulnerable functionality, and multiple serious exploitation paths exist. At least one of those known paths does not require authentication, which means an unauthenticated attacker could potentially reach it on an affected site.
That wording matters. Almost every real-world Drupal site runs contributed modules, and many run custom code written for the site. The question site owners should ask is not whether they run a bare core install, but whether anything in their build reaches the vulnerable code. Because that is hard to answer quickly, the practical guidance is simple: treat your site as at risk and update.
The vulnerability, explained
The flaw, tracked as CVE-2026-108097, sits in how Field UI builds its administrative tables. Field UI constructs admin tables using Drupal’s render system, and before the fix, a pre-render step would execute whatever PHP callable a table row carried in its #region_callback property, without validating that callback.
In normal operation that is just internal plumbing. But once a contributed module or a piece of custom code builds an admin table through that same code path, an attacker can smuggle in a malicious callback. When the table renders, the server runs the attacker’s code. Remote code execution on a server usually means the worst-case outcome for a web application: stolen data, planted backdoors, or the site being turned into a launchpad for further attacks.
The vulnerability was reported by Drew Webber of the Drupal Security Team and Octavio Galland, and the fix was prepared by security team members including catch, Lee Rowlands, Dave Long, Drew Webber, and Jess, with coordination from Swan Kalata and Bram Driesen.
This is the kind of flaw that pairs dangerously with third-party code. We have seen the same pattern all week in other ecosystems: a supply-chain compromise in a Rank Math SEO Pro update turned a trusted plugin into malware distribution, and a critical SQL injection in the Backuply backup plugin put 600,000 WordPress sites at risk. The lesson repeats: extensions and add-ons are where attackers look first.
Which versions are affected
The advisory lists the affected range and the fixed release for each supported branch:
| Branch you run | Affected range | Update to |
|---|---|---|
| Drupal 10.6.x | 8.9.0 through 10.6.18 | 10.6.19 |
| Drupal 11.3.x | 11.0.0 through 11.3.18 | 11.3.19 |
| Drupal 11.4.x | 11.4.0 through 11.4.9 | 11.4.10 |
| Drupal 12.0.0 (alpha/beta) | 12.0.0-alpha1 through 12.0.0-beta1 | 12.0.0-beta2 |
There is a catch for older sites. Drupal 11.2.x and below are end-of-life and do not receive security coverage, and neither do Drupal 10.5.x and below. Drupal 8 and Drupal 9 are long retired. If your site sits on any of those branches, there is no official patch for you. The Drupal 12 fix is a beta release, which is not intended for production websites.
If you are on an unsupported branch, your path is: apply the temporary mitigation below immediately, upgrade to a supported branch (10.6.19, 11.3.19, or 11.4.10) as fast as you can, and plan the full Drupal 11 upgrade. Drupal 10 reaches its end of life on December 9, 2026, so 10.x sites need to finish that migration anyway.
Who is actually at risk
The honest answer: most production Drupal sites should assume exposure until patched. Here is how to think about it:
- Every site running contributed modules is in scope. Contributed modules are the primary way the vulnerable functionality gets exposed, and real sites almost always run them.
- Custom code counts too. If your site has custom modules that build Field UI-style admin tables, those can open a path just as easily.
- Authentication may not protect you. At least one known exploit path requires no login, so access controls are not a reliable defense on their own.
- Bare core installs are not directly exploitable, per the advisory. But “not directly exploitable” is not the same as safe, and it is not a reason to delay.
To check your exposure, find your Drupal version first. In the admin toolbar go to Reports, then Status report, or run drush status from the command line. Match your version against the table above.
How to patch
Back up first. Take a full database backup and a file backup, and if you have a staging environment, test the update there before touching production. That is standard practice for any core update, and doubly so for a security release.
For most sites, the update path depends on how Drupal was installed:
- Composer-based installs: run
composer update "drupal/core-*" --with-all-dependenciesto pull the fixed release for your branch, then rundrush updatedbanddrush cache:rebuild. - Confirm the new version on the Status report afterward. It should show 10.6.19, 11.3.19, or 11.4.10 depending on your branch.
- Reinstall Field UI if you had uninstalled it as a temporary measure (see below), provided your site builders need it.
After updating core, do not stop there. The October 14 security release day included several related advisories, so check for updates to contributed modules and themes as well, particularly the Gin administration theme and the Entity List module (covered below).
The temporary mitigation if you cannot patch today
Drupal’s advisory names an official workaround for sites that cannot update immediately: uninstall the core Field UI module (machine name field_ui). Removing it blocks this vulnerability while you prepare the update.
You can do this with Drush:
drush pmu field_ui
or through the admin interface under Extend, then the Uninstall tab. Be aware this removes the field management interface, so site builders who manage fields through the UI will lose that capability until the module is reinstalled after patching. It is a mitigation, not a fix, and it does not replace the update.
It is worth noting that uninstalling modules as a stopgap has limits, as we saw recently with a Collabora/Nextcloud flaw where simply disabling the app did not protect servers that had already been attacked. In this Drupal case the advisory explicitly names uninstalling Field UI as effective protection for the window before you patch, so it is a sound move. It just does not excuse staying on an unpatched version.
What about Drupal Steward?
The advisory says this issue is being protected by Drupal Steward, the project’s virtual patching service used by hosting platforms including Acquia, Pantheon, Ironstar, and Skpr. That is genuinely helpful if your site is on one of those platforms: Steward blocks some known attack vectors automatically.
The advisory is equally clear that this protection will not cover all possible exploits, and that additional attack vectors could be discovered. Steward buys time; it does not replace the update. If you are on Steward-protected hosting, patch in the near future anyway.
The other flaws fixed the same day
The October 14 release was not a one-advisory day. The Drupal Security Team published five advisories covering:
- SA-CORE-2026-014 (this one): critical remote code execution in Field UI, 19/25.
- SA-CORE-2026-015: cross-site scripting in the core Link module, rated moderately critical, 13/25.
- SA-CORE-2026-016: cross-site scripting in the core Navigation module, rated moderately critical, 12/25.
- A second critical remote code execution flaw in the contributed Entity List module, with known exploitation paths that also do not require authentication.
- Cross-site scripting issues in the Gin administration theme.
The same core releases (11.4.10, 11.3.19, 10.6.19) address the three core issues. The contributed module and theme fixes ship separately, so check for their updates too. A recent WordPress page-builder flaw showed how quickly attackers move once details are public: active exploitation began within days of disclosure. Drupal’s pre-release announcement on October 12 warned that exploits could appear within hours or days of the advisory, and that timeline has held true in past Drupal incidents.
What to do if you were already attacked
As of October 15 reporting, no public exploit code and no confirmed in-the-wild exploitation of this specific flaw had been identified. That can change fast. If you suspect compromise on a site that was running a vulnerable version, treat it as an incident:
- Take the site offline or isolate it so it cannot attack others.
- Check access and error logs for unusual requests, especially to administrative table pages and any requests around the time modules were added or updated.
- Look for unexpected administrator accounts, unfamiliar files, and unknown scheduled tasks or cron entries.
- Do not just patch over a compromised site. Restore from a known-good backup taken before the exposure window, then update, or rebuild from clean sources.
- Rotate credentials, API keys, and secrets that lived on the server.
Frequently asked questions
Is my Drupal site vulnerable if I only run core?
According to the advisory, the flaw is not directly exploitable with core alone. However, contributed modules and custom code can expose it, and at least one known path needs no authentication. Since almost every production site runs contributed modules, you should update regardless.
Which Drupal versions fix CVE-2026-108097?
Drupal 10.6.19, Drupal 11.3.19, and Drupal 11.4.10. A fix is also in Drupal 12.0.0-beta2, but beta releases are not for production sites. Branches 11.2.x and below, 10.5.x and below, and all of Drupal 8 and 9 are end-of-life and receive no fix.
What is the temporary fix if I cannot update right away?
Uninstall the core Field UI module (drush pmu field_ui, or Extend, then Uninstall in the admin UI). This blocks the vulnerability while you prepare the update. Reinstall it after patching if your site builders need the field management interface.
Does Drupal Steward fully protect my site?
No. Steward blocks some known attack vectors, but the advisory states it will not cover all possible exploits. Sites on Steward-protected hosting still need to apply the core security update.
Has anyone been attacked through this flaw?
At the time of the advisory, Drupal said no public exploit code was available, and reporting through October 15 had not identified confirmed exploitation. Drupal’s pre-release notice warned exploits could be developed within hours or days, so do not treat the absence of known attacks as safety.
What else was fixed in the October 14 Drupal security release?
The same release day covered two cross-site scripting flaws in Drupal core (Link and Navigation modules), a second critical remote code execution flaw in the contributed Entity List module, and XSS issues in the Gin administration theme. Update those contributed components as well.