Drupal has shipped fixes for two critical remote code execution flaws affecting every supported version of its content management system. With proactive vulnerability management now time-critical, UK operators running Drupal sites have a narrow window before exploit code is expected to appear.
View the data behind this chart
| Phase | Starts (week) | Duration (weeks) |
|---|---|---|
| Advance warning issued | 0 | 1 |
| Patches released | 0 | 1 |
| Public disclosure | 1 | 1 |
| Exploit risk window | 2 | 2 |
What Drupal disclosed and why it matters
Drupal's security team confirmed two critical vulnerabilities this week: CVE-2026-108097, a remote code execution flaw in the core Field UI module, and CVE-2026-108099, an RCE issue in the widely used contributed Entity List module. Drupal has stated plainly that "all currently supported versions of Drupal core are affected."
The project issued an advance warning ahead of disclosure, telling administrators to reserve time for core updates because, in its own words, exploits might be developed within hours or days of the fixes going public. That is a blunt, specific timeline rarely attached to CMS advisories, and it reflects how quickly attackers now reverse-engineer patches to build working exploits.
Inside the two flaws
Neither vulnerability is exploitable through Drupal core alone in isolation, but both become dangerous once contributed modules or custom code are involved — which describes the vast majority of production Drupal sites. CVE-2026-108097 cannot be triggered by core by itself, but Drupal has confirmed that certain contributed modules open multiple exploitation paths, including at least one that requires no authentication at all.
CVE-2026-108099, affecting the Entity List module used to build entity listings without Views, works in a similar way: successful exploitation depends on interaction with contributed modules or custom code, and again includes at least one unauthenticated path. For buyers weighing severity, this is the detail that matters most — an unauthenticated route to code execution on an internet-facing CMS is about as serious as web application risk gets.
- •CVE-2026-108097 — Field UI module (Drupal core), RCE, unauthenticated path possible via contributed modules
- •CVE-2026-108099 — Entity List (contributed module), RCE, unauthenticated path possible
Who in the UK should be paying attention
Drupal is used on more than one million websites globally, and its user base skews heavily toward sectors such as government agencies (including UK councils and departments), universities, and non-profit organizations. These organisations often run Drupal instances built years ago by third-party agencies, with contributed modules added incrementally and rarely audited end to end — precisely the conditions where an unauthenticated exploitation path can sit undetected.
If your organisation, or a client you host for, runs Drupal without a clear inventory of which contributed modules are active, this advisory is a reminder of why understanding CVE and CVSS severity ratings matters for prioritisation — a critical, unauthenticated RCE on a public-facing CMS should jump to the top of any patch queue, ahead of lower-severity findings elsewhere in the estate.
The fix, and what to do if you can't patch immediately
Drupal has released fixed versions: core should be updated to 10.6.19, 11.3.19 or 11.4.10 depending on release branch, and the Entity List module to 3.0.10. Drupal has also confirmed that all versions prior to 10.6.x, and all Drupal 11 releases before 11.3.x, are end-of-life and no longer supported — meaning sites still running on those branches have no official patch path and are exposed indefinitely unless upgraded to a supported branch first.
Drupal 12 pre-release builds before beta2 are also affected, though these are not intended for production use; the eventual stable 12.0 release will include both fixes. For administrators who cannot immediately apply the update, Drupal's own advice is to uninstall the core Field UI module (field_ui) as an interim mitigation. This should be treated as a stopgap, not a substitute for proper effective patch management strategies that get affected sites onto a fixed release quickly.
Why patching alone won't close the whole gap
Drupal has pointed to its own Steward service as protection against some known attack vectors, but it is explicit that this does not cover every possible exploitation route — a useful reminder that vendor-side shielding is not a replacement for patching the underlying flaw. It also underlines a wider truth for UK buyers assessing defence posture: once an attacker has valid credentials or a foothold, prevention controls alone do far less work than most teams assume.
That is why hosting providers and site owners should pair rapid patching with layered detection. Managed detection & response capability that can spot post-exploitation behaviour — unusual file writes, outbound connections or privilege escalation on a web server — gives a second line of defence if an exploit lands before patching completes.
The Servnet view for hosting providers and site owners
For UK hosting providers managing fleets of Drupal sites on behalf of clients, this advisory is a scheduling problem as much as a technical one: every affected instance needs to be identified, version-checked, and either patched or mitigated within days, not weeks, given Drupal's own exploit-timeline warning. Providers that maintain a live inventory of CMS versions and installed modules across their customer base will move through this far faster than those discovering exposure site-by-site.
Organisations evaluating their broader resilience against this kind of unauthenticated web RCE should treat it as a prompt to review coverage through comprehensive cybersecurity services that combine patch visibility, detection and incident response rather than relying on any single control.