Drupal Patches Critical Field UI Flaw With Unauthenticated RCE Path via Contributed Modules

Drupal core has a critical flaw in its Field UI module that could let an attacker run code on the site’s server, and fixes were shipped on October 14 in Drupal 11.4.10, 11.3.19, and 10.6.19.

An attacker cannot reach the flaw through core alone, the Drupal Security Team said in its advisory. Several exploit paths exist through contributed modules, and at least one known path needs no login.

Tracked as CVE-2026-108097, the flaw sits in Field UI, the core module behind the admin pages where site builders manage fields and how they display. Drupal rates it 19 out of 25 on its own risk scale, the level the project calls critical.

The advisory does not name the contributed modules that open a path to the flaw, and custom code may also expose it. Drew Webber of the Security Team and Octavio Galland are credited with reporting it.

What to Do Now

The fixed release for each supported branch:

• Drupal 11.4.x: update to 11.4.10
• Drupal 11.3.x: update to 11.3.19
• Drupal 10.6.x: update to 10.6.19
• Drupal 12.0.0 beta: 12.0.0-beta2, which is not for production use
• No fix: Drupal 11.2.x and below, 10.5.x and below, and Drupal 8 and 9, all of which are end-of-life

Both 11.3.x and 10.6.x lose security coverage in December 2026.

In the week starting October 4, 151,442 of the 531,499 sites that reported their Drupal core version to drupal.org (28.5%) were on a branch that the advisory lists as affected and that received no fix.

A site that cannot update yet can uninstall the Field UI module, field_ui, which “will provide protection while sites are updated,” the advisory says. The admin pages for managing fields and their display are unavailable while the module is uninstalled.

Field UI is installed by Drupal’s Standard install profile, so a site built from that profile has the module unless someone removed it.

Drupal Steward, a web application firewall service with rules written by the Security Team, already blocks some known attack vectors for this flaw. Acquia, Pantheon, Ironstar, and Skpr run it for their customers. It does not cover every possible exploit, and those sites should still update, the advisory says.

The advisory rated the flaw as having no publicly available exploit code at the time of publication. As of October 15, none had surfaced, and neither the advisory nor public reports described attacks using it.

The Security Team had pre-announced the release on October 12 and told sites to reserve time for it “because exploits might be developed within hours or days.”

In May, Drupal reported exploit attempts within two days of its advisory for a core SQL injection flaw that affected only sites on PostgreSQL, and CISA added that flaw to its catalog of exploited vulnerabilities.

What the Fix Changed

Field UI builds its admin tables from render arrays, the PHP arrays Drupal turns into HTML. Before the fix, the table element’s pre-render step ran whatever PHP callable each table row carried in its #region_callback property, through call_user_func_array, with no check on what that callable was.

Drupal’s renderer has refused to run untrusted render callbacks since version 8.8 in 2019, a restriction added after earlier advisories showed that the render system could too easily call arbitrary callbacks. The renderer trusts the table element’s own methods, so it ran the pre-render step, and the check never reached the callable that step then executed.

The 11.4.10 code no longer calls the callback. It reads each row’s region from the row’s own region value and uses the table’s hidden region, or its first region, when that value is not a known region. The same call had been in the code since at least Drupal 8.9.0 in 2020.