Drupal has patched two critical remote code execution flaws that affect every currently supported version of its core, and the security team is telling administrators that working exploits could appear within hours or days.
The two issues are CVE-2026-108097, in Drupal core's Field UI module, and CVE-2026-108099, in Entity List, a contributed module for building entity lists without Views. Both can end in arbitrary code execution on the server. Drupal's own summary says all currently supported versions of core are affected.
Neither flaw is a clean one-shot against stock core. The advisory for CVE-2026-108097 says it cannot be exploited using Drupal core alone, but contributed modules open multiple exploitation paths, and at least one of those needs no authentication. Custom code can expose the same functionality. CVE-2026-108099 is similar: exploitation runs through a contributed module or custom code, and again there is at least one known path that requires no authentication. For a platform where most real deployments run a stack of contributed modules, "core alone is safe" is close to no reassurance.
The fix is a version bump. Update core to 10.6.19, 11.3.19, or 11.4.10 depending on your release branch, and update Entity List to 3.0.10. Anything older than 10.6.x, and any Drupal 11 before 11.3.x, is end-of-life and will not get a patch, so sites on those branches have to move to a supported line first. Drupal 12 pre-releases before beta2 carry the flaws too, but those are not meant for production, and the stable 12.0 release will ship with both fixes included.
Drupal gave notice ahead of the release. Earlier in the week the project published the two CVE IDs and the affected-version statement, and told administrators to clear time for the update because "exploits might be developed within hours or days." It also recommended getting onto the latest bugfix release for your branch before October 14, so any unrelated upgrade trouble is sorted out before the security patch lands.
If you genuinely cannot upgrade in the window, Drupal's recommended mitigation is to uninstall the core Field UI module (field_ui). That removes the vulnerable functionality behind CVE-2026-108097, at the cost of the admin interface for managing fields, so it fits a site in maintenance mode better than one under active development.
Drupal Steward, the project's platform-level protection, blocks some known attack vectors for these flaws but not every possible exploit. Treat it as a speed bump, not a substitute for patching.
The reach is why the timeline matters. Drupal runs more than a million sites, and it is common in government, universities, and non-profits, which tend to sit on older branches and patch slowly. That is exactly the population an exploit author looks for once a pre-disclosed security window closes.
Top comments (1)
Useful writeup. One addition for anyone triaging a fleet of client sites: the advisory's short-term mitigation is uninstalling the core Field UI module (field_ui). Fields keep working with it disabled, so it's a no-deploy stopgap while you schedule the full update to 11.4.10 / 11.3.19 / 10.6.19.
For the first pass across many sites, we built a free version checker - paste a Drupal version, get affected/not and the exact target release: shuttlewright-drupal-patch.pillar-...
Drupal reports no known active exploitation at the time of the advisory, but the r/netsec deep dive today maps the callback path clearly - patch on the assumption that scanners are catching up.