Critical Field UI Flaw in Drupal: A Patching Guide for Your CMS Site and Why "Theoretical" Isn't Reassuring Enough
On 14 October the Drupal team patched a critical remote code execution flaw (CVE-2026-108097) in core's Field UI module and a similar flaw in the Entity List module. Core alone can't be exploited, but contributed modules can open the door. Who is affected and what should you do?
In brief: On 14 October 2026 the Drupal Security Team patched a critical remote code execution (RCE) flaw affecting core's Field UI module, CVE-2026-108097 (SA-CORE-2026-014), and a similar flaw, CVE-2026-108099 (SA-CONTRIB-2026-218), in the contributed Entity List module. According to BleepingComputer, Drupal core alone does not allow exploitation; but contributed modules and custom code open paths that make it possible, and at least one path needs no authentication. Drupal says “all currently supported versions of Drupal core are affected.” The fixed versions: Drupal 10.6.19, 11.3.19 and 11.4.10; Entity List 3.0.10. If you can't upgrade right away, uninstalling the Field UI module is a workaround. Drupal had warned exploits could be developed “within hours or days;” the report did not mention exploitation in the wild. This article relies on BleepingComputer's 17 October report; the situation may have changed.
Last updated: 26 October 2026
What happened?
| Flaw | Module | Severity | Note |
|---|---|---|---|
| CVE-2026-108097 (SA-CORE-2026-014) | Drupal core, Field UI | Critical, RCE | Core alone doesn't allow exploitation; contributed modules and custom code open exploit paths, at least one unauthenticated |
| CVE-2026-108099 (SA-CONTRIB-2026-218) | Contributed module Entity List | Critical, RCE | Exploitation requires interaction with contributed modules or custom code; at least one known path unauthenticated |
Drupal's wording: “All currently supported versions of Drupal core are affected.” The flaw also affects Drupal 12 pre-releases before beta2, which are not meant for production; the stable 12.0 includes the fixes.
Fixed versions
- Drupal core: 10.6.19, 11.3.19 or 11.4.10 (depending on your branch)
- Entity List: 3.0.10
- End-of-life versions: All versions before 10.6.x and all Drupal 11 versions before 11.3.x are end of life and receive no security patches. If you are on those, you need not only a patch but an upgrade.
The workaround
If you can't upgrade right away, Drupal's recommendation is to uninstall the Field UI core module (field_ui). That module is mostly used to define fields during development/administration and can be kept off in production on most sites. Drupal Steward blocks some known attack vectors but not all. A workaround is not a fix; the patch is still needed.
Exploitation status
- The Drupal security team had warned that exploitation could be developed within hours or days.
- BleepingComputer's report (17 October) did not report exploitation in the wild.
- According to a Cloud Security Alliance note dated 19 October (secondary source), no public exploit code had been observed as of 15 October. This may have changed; as with PHP2Shell, the situation can change within days.
Why can the “theoretical” label mislead?
Some sources label the exploit status “theoretical.” But:
- The exploit path depends on your site's contributed modules and custom code. A general “no risk” assessment doesn't represent your site.
- At least one path needs no authentication.
- After a patch is released attackers can reverse-engineer the fix; AI is speeding up that process (our patch timing article).
If you have a Drupal site: 7 steps
- Find the version: In the admin panel Reports > Status, or
drush status. - Upgrade: to 10.6.19, 11.3.19 or 11.4.10, and to Entity List 3.0.10 if you use it.
- If you're on an end-of-life line plan the upgrade; no patch will come.
- If you can't upgrade, remove Field UI and set an upgrade date in writing.
- Inventory your contributed modules and custom code; have your software team assess which interact with Field UI or Entity List.
- Review the logs: Unusual requests, unexpected files, new administrator accounts.
- Consider rotating secrets (if in doubt): database, API keys, administrator passwords.
If you run PHP on the same server, don't forget the PHP2Shell patch: Drupal runs on PHP and PHP2Shell was also demonstrated against Drupal images.
Which CMS, which risk?
This week urgent patches came out across different CMSs and runtimes. We covered how much maintenance burden each technology brings in our tech stack guide and in our WordPress or Next.js comparison. Choosing a CMS is also choosing a continuing patch responsibility.
Maintenance with Aktaş Digital
In CMS and custom software projects we set up version tracking and a patch routine. To have your site's current state assessed, use our quote form. Related services: web applications.
Frequently Asked Questions
What happens to my site if I remove Field UI?
Field UI is usually used to manage field definitions and can often be turned off on a production site. Test your site's dependence before removing it.
My site is on Drupal 9; what should I do?
Drupal 9 and earlier have lost support and get no patches. Plan a move to a supported version.
Does this flaw affect WordPress?
No; this is specific to Drupal. For WordPress, PHP-sourced issues like PHP2Shell apply separately.
Has exploitation started?
The report did not mention exploitation in the wild; but Drupal warned it could be developed quickly. Don't delay the patch.
Conclusion
Even if “core alone can't be exploited,” Drupal's Field UI flaw is a real risk that depends on your site's modules. Move to a patched version, get off end-of-life lines and temporarily turn off Field UI. First step: confirm in writing your Drupal version and whether it is supported.
