- The Drupal Security Team disclosed a remote code execution flaw in core's Field UI module. Core alone is not directly exploitable, but contributed modules create exploit paths, at least one without login.
- Exposure depends on each site's own mix of modules and custom code, so the advisory alone cannot tell an owner whether they are at risk.
- Update to 11.4.10, 11.3.19 or 10.6.19. Uninstalling field_ui is the interim mitigation. Sites on end-of-life lines get no fix.
The flaw sits in core, but the danger sits in your stack
On October 14, the Drupal Security Team published advisory SA-CORE-2026-014. It describes a remote code execution flaw in the Field UI module that ships with Drupal core. Remote code execution means an attacker can make the server run commands of their choosing.
Field UI is the part of Drupal's admin interface where site builders manage content fields. The advisory does not explain how the flaw works, so this article does not either.
The advisory adds a condition that matters. The flaw is not directly exploitable with core alone. But the team says multiple serious exploit paths exist through contributed modules, the add-ons written by the wider community. At least one known path needs no authentication, so the attacker does not need an account. The team also warns that custom code may expose the same functionality.
The lesson here is that a vulnerability can be dormant in the product and live in the combination. The flaw is one ingredient. Your modules and your developers' code may supply the other.
Why the advisory cannot answer the main question
A normal patch notice tells you whether you run the affected version. This one asks for more. You also need to know which contributed modules your site uses and what custom code your team has written. The Drupal team cannot see that. Your own people can.
That shifts the work onto the site owner. Someone has to inventory the installed modules, check whether any of them touch the vulnerable functionality, and review custom code for the same exposure. The advisory does not name the affected contributed modules, so this review falls to each organization.
Think of a kitchen with one hazardous ingredient on the shelf. It does no harm until someone mixes it with something else. The safe approach is to know what is on your shelf, or to remove the ingredient.
What the fix and the stopgap look like
The Drupal team lists patched releases for the supported lines. Sites on 11.4.x should move to 11.4.10. Sites on 11.3.x should move to 11.3.19. Sites on 10.6.x should move to 10.6.19.
For sites that cannot update at once, the team names a mitigation: uninstall the core Field UI module (field_ui). That protects the site while updates are prepared.
The team also notes that Drupal Steward already protects against some known attack vectors. Steward is a protection service for Drupal sites. The team says that protection does not cover all possible exploits and advises upgrading in the near future in case more attack vectors are found.
Sites on old lines have no patch coming
Older lines are outside the fix. The advisory says security coverage has stopped for Drupal 11.2.x and earlier, and for Drupal 10.5.x and earlier. It also notes that Drupal 8 and Drupal 9 have reached end-of-life. An organization on one of those lines cannot patch this flaw. Its choices are a version upgrade or the mitigation, and the advisory frames only the supported releases as fixed.
How much Drupal is in view
WebPulse scanned the Tranco top 10,000 domains in September 2026. Of 7,064 that responded, a platform was detected on 2,491. Drupal was detected on 188 of those, or 7.5% of detected sites.
Two limits apply. The percentage covers only sites where a platform was detected, not the whole web. The scan also cannot show which Drupal version a site runs, or whether Field UI or any contributed module is installed. It shows that Drupal is common in this sample. It does not show how many sites are exposed.
Questions to put to your team this week
Ask which Drupal release line each of your sites runs, and whether any is on an end-of-life line. Ask whether field_ui is installed in production, and whether it can be uninstalled until patching is done. Ask for a list of contributed modules and custom code on each site, and who has checked them against this advisory. Ask whether the sites use Drupal Steward, and what the team assumes that covers.
Ask for dates, not reassurance. A patch plan for each site should name an owner and a deadline. The Drupal team's own words set the tone: protection is partial, and upgrading is the answer.
Exposure to a flaw like this depends on what is wired to it, which is why every site should still patch. Knowing your own stack tells you how urgent the work is and where to look first.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Drupal Security Team.
