Vulnerabilities

Drupal fixes critical Field UI RCE as NHS warns sites to patch

Drupal’s critical Field UI flaw CVE-2026-108097 can allow unauthenticated code execution. NHS England Digital urges patching; old branches get no fix.

Warning symbol over a web server illustrating a critical Drupal core remote code execution flaw

Drupal has shipped emergency fixes for a critical remote code execution flaw in its core Field UI module, and NHS England Digital has told health organisations to patch. No exploit is public yet, but Drupal’s own security team warns one could follow quickly, and sites still on unsupported branches get no fix at all.

What happened

On 12 October the Drupal Security Team published an advance notice, PSA-2026-10-12, telling site owners to keep time free on 14 October for a critical core release. That release arrived on 14 October, in a window scheduled for 16:00 to 21:00 UTC, as advisory SA-CORE-2026-014. It fixes CVE-2026-108097, a remote code execution flaw in Field UI, the core module that lets administrators add and configure fields on content types. The team scored it 19 out of 25, which puts it in Drupal’s “critical” band.

A companion advisory, SA-CONTRIB-2026-218, covers CVE-2026-108099 in Entity List, a contributed module that assembles entity lists without needing Views. It has the same 19/25 rating and the same basic shape: the module cannot be exploited on its own, but other code can open a route to it. Entity List users need version 3.0.10.

Two days later, on 16 October, NHS England Digital published cyber alert CC-4871, telling organisations to read the Drupal advisory and apply updates “as soon as possible”. Drupal’s advance notice had already warned that exploits might be developed within hours or days, a point BleepingComputer repeated on 17 October. The CVE is credited to Drew Webber of the Drupal Security Team and to Octavio Galland.

The technical picture

The advisory is short on detail, which is deliberate, but its wording is worth reading closely. Drupal says core by itself does not give an attacker a direct way in. The danger comes from contributed modules, which provide “several serious exploit paths”. At least one of those paths needs no login at all. Custom code that calls the affected Field UI functionality may also be exposed. The risk vector also flags default configurations as exploitable and rates the impact on confidentiality and integrity as total. Exploit maturity is listed as theoretical, meaning no public proof of concept existed when the fix shipped.

The affected range is wide. Every release from 8.9.0 up to the fixed builds is vulnerable, along with the Drupal 12 pre-releases before 12.0.0-beta2. The fixed releases are:

  • Drupal 11.4.x: move to 11.4.10
  • Drupal 11.3.x: move to 11.3.19
  • Drupal 10.6.x: move to 10.6.19
  • Entity List: update to 3.0.10

The awkward part is what’s missing from that list. Drupal 11.2 and earlier, 10.5 and earlier, and all of Drupal 8 and 9 are end-of-life. They are affected and will not be patched. For anyone who can’t upgrade straight away, the official stopgap is to uninstall the core Field UI module (field_ui). Sites protected by the Drupal Steward service get partial cover, but the team says plainly that it will not block every attack.

Timeline showing the Drupal advance notice on 12 October, the core fix on 14 October, the NHS alert on 16 October and the recommended actions

Why it matters for UK organisations

Drupal has a large footprint in exactly the parts of the UK economy that tend to patch slowly: central and local government, universities, research bodies, NHS trusts and charities. BleepingComputer puts the global installed base at more than a million sites. Many of these are marketing or information sites that were built by an agency, handed over, and then left running with only occasional maintenance. That is the profile that worries me most here.

The NHS alert is notable for another reason. CC-4871 rates the issue as medium severity, while Drupal calls it critical. Health organisations triaging by the NHS score alone could easily drop it down the queue. In my view the Drupal rating is the one to act on, because the vendor knows which contributed modules create the unauthenticated path and the NHS alert does not.

The end-of-life problem matters too. In my experience, plenty of UK public sector and third-sector sites still run Drupal 9, or older Drupal 10 point releases, because a major upgrade needs budget and developer time. Those sites are now carrying a known critical remote code execution flaw with no vendor fix. For organisations working towards Cyber Essentials, unsupported software in scope is an automatic problem, and it has been for some time.

Expert view

Advisories that say “not exploitable in core alone” tend to get read as reassurance, and they shouldn’t be. Very few production Drupal sites run bare core. When we test Drupal estates, it is normal to find dozens of contributed modules plus custom code that nobody on the current team wrote. The question is not whether core is safe but whether your particular mix of modules opens one of the paths Drupal has in mind, and most owners can’t answer that quickly.

The pre-announced release is also a double-edged sword. It gives defenders a fixed window to plan around, but it gives attackers the same date to start diffing the patched and unpatched code. Turning a patch into a working exploit is getting faster as tooling improves. I would treat the four days since release as most of the safe window already gone.

Finally, removing Field UI is a reasonable short-term measure, but check what it breaks. Some editorial workflows depend on it, and a mitigation that a content team quietly re-enables a week later is no mitigation at all.

What to do now

  1. Find every Drupal site you own. Include agency-hosted microsites, campaign pages and staging copies. Check the core version on each one.
  2. Patch supported branches today. Move to 11.4.10, 11.3.19 or 10.6.19 as appropriate, and update Entity List to 3.0.10 wherever it is installed. This maps to the Cyber Essentials security update management control.
  3. Deal with end-of-life sites. Anything on 11.2, 10.5, 9 or 8 cannot be fixed in place. Uninstall field_ui now, then plan an upgrade or take the site offline. Unsupported software also undermines Cyber Essentials compliance.
  4. Use Field UI removal as a bridge, not a fix. If you must delay patching, uninstall the module and confirm it stays off.
  5. Don’t rely on the WAF alone. Drupal Steward and other web application firewalls may stop known patterns, but Drupal says coverage is incomplete.
  6. Look for signs of compromise. On sites that were exposed after 14 October, review web server logs, new administrator accounts, unexpected PHP files and recent configuration changes.
  7. Talk to your suppliers. If an agency or hosting provider manages your site, ask in writing when they patched and what version you are now on.

Bottom line

CVE-2026-108097 is the kind of flaw that looks narrow on paper and broad in practice, because real Drupal sites are built from exactly the add-on modules that make it reachable. Supported sites can be fixed in minutes. The harder job for many UK public bodies and charities is the forgotten, out-of-support site that nobody has touched in years, and that is where attackers will look first.

Sources

Related Posts