Drupal’s Critical Field UI Flaw: A Patch Triage Card for Site Owners Before Exploits Arrive
Drupal has fixed two remote code execution flaws, one in core and one in the Entity List module, and warned that working exploits could follow quickly. Here is a one-page triage card for anyone who owns or inherited a Drupal site.
Drupal’s security team does not usually ask site owners to block out time on their calendars ahead of a release. This month it did, warning in advance that attackers might turn the coming fixes into working exploits within hours or days. The fixes are now out, covering one flaw in Drupal core and one in a popular add-on, and both can lead to attackers running their own code on a web server.
BleepingComputer reported on the patches, and we checked the version numbers and mitigations below against Drupal’s own advisory, SA-CORE-2026-014.
The triage card
- Flaw 1: CVE-2026-108097, remote code execution in the Field UI module that ships with Drupal core. Drupal rates it Critical (19 out of 25 on its own scale). The advisory went out on October 14.
- Flaw 2: CVE-2026-108099, remote code execution in Entity List, a contributed module used to build lists of content without the Views module.
- Who is exposed: every currently supported version of Drupal core, plus Drupal 12 pre-releases before beta2 (which should not be running in production anyway).
- The catch: the core flaw cannot be triggered by Drupal core alone. Contributed modules open several paths to it, at least one of which needs no login at all, and custom code can expose it too. The Entity List flaw works the same way.
- Exploit status: at release Drupal scored exploitation as theoretical, but it explicitly warned that attack code could appear quickly.
- Fixed versions: Drupal 11.4.10, 11.3.19 or 10.6.19, depending on your branch, and Entity List 3.0.10.
- No fix coming: Drupal 10.5.x and earlier, Drupal 11.2.x and earlier, and Drupal 8 and 9 are end-of-life and get no security updates.
Three questions to answer today
- Do we run Drupal anywhere? Check beyond the main website: event microsites, partner portals, intranets and sites an agency built years ago are common places for it to hide.
- Which branch is each site on? The branch decides which release you need, or whether you are on an unsupported version that will never be patched.
- Is Entity List installed? If so, it needs its own update in addition to core.
If you cannot update right away
- Drupal says uninstalling the core Field UI module (field_ui) blocks the core flaw while you prepare the upgrade. Field UI is mainly used by administrators when changing how content is structured, so many live sites can manage without it temporarily.
- Sites covered by Drupal Steward, the project’s web application firewall service, are protected against some known attack routes, but not all. Treat it as a buffer, not a substitute for the update.
- Watch web server and application logs for unexpected requests to admin and field-management paths and for new files appearing in writable directories.
If a site is on an end-of-life version
There is no patch to wait for. Plan the upgrade now, and in the meantime consider whether the site can be taken offline, put behind a login, or replaced with a static copy until it is on a supported release.
What this means for your company
Content management systems tend to be set up once and forgotten, especially when an outside agency built them. A warning like this one is a good prompt to list every website your business owns, who maintains each one, what software and add-ons it runs, and how quickly that person can apply an emergency update. If the answer for any site is “we’re not sure,” that site is the one to look at first.
Need help finding the websites your business depends on and getting them patched and monitored? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
