Drupal administrators are being urged to update supported installations after maintainers disclosed a critical remote-code-execution weakness in the core Field UI module. Tracked as CVE-2026-108097, the vulnerability can expose private site data and allow information to be changed or deleted if an attacker reaches a viable exploitation path.

The Drupal Security Team published advisory SA-CORE-2026-014 and assigned the issue 19 out of 25 under Drupal’s own risk scale. That figure is not a CVSS score. More importantly, the advisory confirms that at least one known route can be used without authentication, meaning an attacker would not necessarily need a valid account.

Core is vulnerable, but site composition determines reachability

The affected component ships with Drupal core, yet core by itself does not provide a direct route to exploitation. Serious attack paths emerge when certain contributed modules are installed, and custom application code may also expose the vulnerable functionality. Site owners therefore cannot determine risk by checking the Drupal version alone.

This dependency makes assessment more complicated than a conventional core-only flaw. Two sites on the same Drupal release may have different practical exposure because they use different extension sets or custom integrations. Teams should inventory enabled modules and locally developed code while treating the core update as the primary remedy.

The public advisory does not name the contributed modules that create the known paths and does not include working exploit code. Drupal describes exploitation as theoretical, with no public proof of concept or development documentation. That language does not mean the issue is harmless: maintainers have confirmed multiple serious paths, including the unauthenticated one, even though attacks in the wild have not been reported.

Affected branches and fixed releases

The vulnerable ranges span several generations of the platform:

• Drupal 8.9.0 through versions before 10.6.19 are affected.
• Drupal 11.0.0 through versions before 11.3.19 are affected.
• Drupal 11.4.0 through versions before 11.4.10 are affected.
• Drupal 12 development builds from 12.0.0-alpha1 through versions before 12.0.0-beta2 are affected.

Administrators on the 11.4 branch should install 11.4.10; those on 11.3 should move to 11.3.19; and 10.6 users should install 10.6.19. Drupal 11.2 and earlier, 10.5 and earlier, and all Drupal 8 and 9 releases no longer receive security coverage. Sites on unsupported branches need a supported upgrade path rather than a narrow patching strategy.

Temporary measures have limits

Uninstalling the core Field UI module, whose machine name is field_ui, protects a site while an update is being prepared. Teams should first confirm whether their editorial and administrative workflows depend on that module, then use controlled change procedures to avoid unnecessary disruption.

Drupal Steward can block some known attack paths, but it does not cover every possible route. It should not be treated as a substitute for installing a supported security release. Network filtering is similarly incomplete when contributed modules and custom code can create different application-level exposure.

Priorities for Drupal operators

Organizations should enumerate every public and internal Drupal deployment, map its core branch, and record enabled contributed modules and custom functionality. Internet-facing sites and systems containing sensitive information deserve first priority, particularly where updates have accumulated or ownership is unclear.

After upgrading, defenders should review web and application logs for unusual requests, unexpected administrative changes, modified PHP files and newly created scripts. A webshell or altered account may survive the original entry point, so finding a patched version does not by itself establish that a previously exposed site is clean.

The broad affected range and extension-dependent attack paths reward disciplined asset management. Apply the supported release, remove Field UI temporarily if an immediate update is impossible, and avoid relying solely on partial filtering. Although no exploitation has been reported, the confirmed unauthenticated path makes postponement an unnecessary gamble.