Drupal Core Field UI Flaw Opens an Unauthenticated RCE Path — Patch Now
The Drupal Security Team has shipped fixes for CVE-2026-108097, a critical flaw in the core Field UI module that can let an attacker execute code on the web server. Drupal scores it 19/25 on its own risk scale — the "critical" band. Fixed releases landed on 14 October 2026.
What happened
Field UI powers the admin screens where site builders manage content fields and how they are displayed. Those screens are built from render arrays, and the table element's pre-render step would invoke whatever PHP callable a row supplied in its #region_callback property — via call_user_func_array, with no validation of what that callable was.
Drupal's renderer has blocked untrusted render callbacks since 8.8 (2019), but the check applied to callbacks the renderer runs directly. Because the table element's own pre-render method is trusted, the callable it then executed was never inspected. The vulnerable call has been present since at least Drupal 8.9.0.
Core on its own does not expose the flaw. The advisory notes, however, that several contributed modules open a route to it — and at least one known path requires no login. Those modules have not been named, and custom code could create a similar path.
The patched code no longer executes the callback at all: it reads each row's region value directly and falls back to the table's hidden (or first) region when the value is unknown. The flaw was credited to Drew Webber of the Drupal Security Team and Octavio Galland.
Why it matters
- Huge exposed base. Field UI is enabled by Drupal's Standard install profile, so most sites built from it carry the module.
- Many sites can't simply patch. In the week of 4 October, roughly 151,000 of ~531,000 sites reporting their version to drupal.org (about 28.5%) ran an affected branch that receives no fix.
- The clock is short. No public exploit or in-the-wild attacks had been reported as of 15 October, but the Security Team pre-announced the release warning that exploits could follow "within hours or days". In May, exploit attempts against a Drupal core SQL injection flaw appeared within two days of its advisory, and CISA later added it to its Known Exploited Vulnerabilities catalog.
The same release cycle also addresses:
- CVE-2026-108099 — a critical RCE in the contributed Entity List module with the same conditions (including an unauthenticated path). Fixed in 3.0.10; updating core does not update this module.
- CVE-2026-108515 (Link module) and CVE-2026-108514 (Navigation module) — moderately critical XSS issues that require an authenticated user.
What to do
- Update core now to the fixed release for your branch:
- 11.4.x → 11.4.10
- 11.3.x → 11.3.19
- 10.6.x → 10.6.19
- 12.0.0 beta → 12.0.0-beta2 (not for production)
- If you run an end-of-life branch (11.2.x or older, 10.5.x or older, Drupal 8 or 9), there is no patch — plan an upgrade to a supported branch. Note that 11.3.x and 10.6.x themselves lose security coverage in December 2026. Drupal 7 sites on commercial long-term support should look for the backported 7.107 release.
- Can't update immediately? Uninstall the
field_uimodule as a stop-gap. The field-management admin pages will be unavailable until you reinstall it after patching. - Update Entity List to 3.0.10 if you use it.
- Review custom code that sets
#region_callbackonfield_ui_tablerows — it will stop running after the update. Test the Manage fields and Manage display pages afterwards. - Don't rely on a WAF alone. Drupal Steward and hosting-provider rules block some known vectors, but not every possible one. Patch anyway.
- Inventory and monitor. Confirm which of your sites run Drupal, which branch, and which contributed modules — then watch logs for unusual admin-route requests in the coming days.
Not sure which of your web assets run an exposed Drupal version? 4Tify's vulnerability assessments map your stack and flag outdated, end-of-life components before attackers do.
Source: reported by The Hacker News, based on the Drupal Security Team advisories.
