Vulnerability

Drupal core Field UI remote code execution (CVE-2026-108097)

A remote code execution flaw in the Field UI module of Drupal core.

CVE ID
CVE-2026-108097
CVSS
No CVSS score yet (NVD has no record); Drupal rates it Critical, 19 out of 25
Affected product
Drupal core, Field UI module
Exploited
Unknown
Published
14 October 2026

In short

CVE-2026-108097 is a remote code execution flaw in the Field UI module of Drupal core. Drupal rates it Critical, 19 out of 25. It also says core alone is not enough. An attack needs a contributed module or custom code that lets a request steer a row of a Field UI table. Drupal published advisory SA-CORE-2026-014 on 14 October 2026. Fixed releases are 11.4.10, 11.3.19 and 10.6.19. Branches 11.2 and below and 10.5 and below get no fix. Fortbridge reports that no public module that makes the flaw reachable has been named.

Profile MapVulnerability
  1. CVECVE-2026-108097
  2. ProductDrupal Drupal core, Field UI module
  3. Fix Steps6actions listedCheck your Drupal version · Update Drupal core

What it allows

The flaw is in Field UI, the Drupal core module behind the admin screens where site builders manage fields and display settings. Field UI builds its tables from data. One line of core code took a function name stored in a table row and ran it, with the row as its argument. The advisory calls the result remote code execution. In 11.4.10 that line is gone, and the UK security firm Fortbridge says the deletion is the whole fix.

Why Core Alone Is Not Enough

Drupal says the flaw is not directly exploitable with core alone. It says several serious exploit paths exist with contributed modules, that at least one needs no login, and that custom code may expose it too. Fortbridge splits the problem in two. The sink is the core line, present on every stock install. The writer is contributed or custom code that lets a web request choose what goes into a table row.

Core has no such writer. The only core Field UI table Fortbridge found sits on an admin form, and an anonymous request gets a 403 error. Using a made up writer module in its own lab, Fortbridge showed that the sink can end in code running on the server. It labels that module synthetic.

No Public Writer Module Has Been Named

Fortbridge checked 117 candidate modules against their source and cloned 250 projects. It reports that no public contributed module uses the pattern today. The only one that ever did is Entity List, covered below. Its reading is that real exposure is Entity List plus custom code in your own modules. That is one firm's reading, not a Drupal statement.

Drupal rates the flaw Critical, 19 out of 25 on its own scale, with exploit maturity marked Theoretical. NVD had no record for the CVE on 23 October, so there is no official CVSS score. Fortbridge says that scored as exploitable it would be 9.8 on CVSS 3.1, and 8.1 with high attack complexity. Those are its own figures. It adds that the moment a real writer module is named, it becomes a 9.8.

What Our Checks Showed

CISA had not listed the CVE in the Known Exploited Vulnerabilities (KEV) catalog file CISA released on 21 October. Drupal did warn on 12 October that exploits might be developed within hours or days of the release, so the window to update is short.

GitHub: on 23 October our searches found 4 repositories, each with 0 stars. We read them and did not run or link them. One is a short detector that calls itself defensive. One is the Fortbridge research pack, whose README says the writer module in it is synthetic. One is a teaching lab with its own deliberately vulnerable module.

The fourth is a tool that its README calls a full chain exploiter, with a target list and search queries for finding sites. Its three writer entries are placeholders with invented paths. Against a real site, its find-the-writer stage has nothing real to find. We did not run it.

X: from 12 to 23 October we pulled 169 posts, and 106 mention Drupal or the CVE. Most repeat the advisory or the news. A few accounts claimed attacks or public exploit code with no evidence. One named post adds something real. Fortbridge wrote on 19 October:

"no real writer confirmed yet. The search continues." @FORTBRIDGE, 19 October 2026: FORTBRIDGE post on X

Fortbridge says it rebuilt the exploit on Drupal 11.4.9 and 11.4.10 pairs, and that every variant fails on the patched site.

Dark web monitoring through THANOS, 12 to 23 October: 7 posts carry the CVE id, 6 on Telegram channels and 1 on a forum. They are news reposts and links. On 21 October a Telegram bot that feeds exploit repositories listed the target tool described above as a proof of concept. This is our own reading of aggregate counts, and it is not verified.

Our conclusion: the risk is real but narrow today. Treat it as a patch now flaw, because the missing piece, a writer module, could be named any day.

Who is affected

The advisory lists four ranges of Drupal core as affected:

  • 8.9.0 up to but not including 10.6.19.
  • 11.0.0 up to but not including 11.3.19.
  • 11.4.0 up to but not including 11.4.10.
  • 12.0.0-alpha1 up to but not including 12.0.0-beta2.

Fixed releases are 10.6.19, 11.3.19 and 11.4.10, and 12.0.0-beta2 contains the fix. Drupal 8 and 9 are end of life.

Branches With No Fix

Drupal 11.2.x and below, and 10.5.x and below, are end of life and get no fix. That covers 8.9 to 10.5 and 11.0 to 11.2. A site there must move to 10.6, 11.3 or 11.4 first.

The drupal.org usage table for the week starting 4 October lists 531,499 reporting sites. Adding its columns for 8.9.x to 10.5.x and for 11.0.x to 11.2.x gives 151,442 sites, or 28.5%. The sum is ours. Drupal.org counts only sites that report. The table cannot show patch level, so we cannot say how many sites on 10.6, 11.3 or 11.4 already run a fixed release.

Time is short on the supported branches too. Drupal's release schedule ends security support for 11.3.x and 10.6.x in the week of 7 December 2026, when Drupal 12.0.0 and 11.5.0 are due. Drupal 10 reaches end of life on 9 December 2026.

Entity List (CVE-2026-108099)

Entity List is the one module known to have used the vulnerable pattern. Advisory SA-CONTRIB-2026-218 of 14 October rates it Critical, 19 out of 25, with remote code execution. It carries CVE-2026-108099 and the same wording: not directly exploitable with the module alone, and at least one known path with no login. Entity List 3.0.10 fixes it, and versions below 3.0.10 are affected. Its project page says 191 sites report using it.

Related Advisories

The same core release fixed two cross-site scripting flaws, SA-CORE-2026-015 and SA-CORE-2026-016, both rated Moderately critical. On 21 October Drupal also published SA-CONTRIB-2026-253 for the Monster Menus module, rated Critical, 16 out of 25. It needs the RSS Page submodule and a role that may create RSS Feed content.

This Is Not PHP2Shell

The PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, are a separate bug in the PHP engine itself. A Drupal site needs both the PHP update and the Drupal update. Our PHP2Shell analysis lists the fixed PHP versions, and the first 60 hours of PHP2Shell shows how the wave moved.

Timeline

  1. 12 Oct 2026

    Drupal announces a core security release for 14 October and warns that exploits might be developed within hours or days.

  2. 14 Oct 2026

    Drupal publishes SA-CORE-2026-014 with fixes, and SA-CONTRIB-2026-218 for the Entity List module.

  3. 15 Oct 2026

    News reports spread on X. A GitHub repository that calls itself a defensive detector is created.

  4. 18 Oct 2026

    Fortbridge publishes a deep dive with a lab that uses a synthetic writer module.

  5. 19 Oct 2026

    Fortbridge says on X that it searched 117 candidate modules and 250 projects and confirmed no real writer.

  6. 20 Oct 2026

    A GitHub repository with a mass-target exploit tool appears. Its writer entries are placeholders.

  7. 21 Oct 2026

    The CISA KEV file released on this day does not list the CVE.

What to do

  1. Check your Drupal version

    Open Reports, then Status report in the admin menu, and read the Drupal version. In a Composer project, run composer show drupal/core. If you use Drush, drush status prints the version too. Compare it with 11.4.10, 11.3.19 and 10.6.19.

  2. Update Drupal core

    Move to 11.4.10, 11.3.19 or 10.6.19 or newer, then run database updates and clear caches. A site on 11.2 or 10.5 or older needs a move to a supported branch. Plan it now, because 11.3 and 10.6 lose security support in early December. This is the fix. Everything below is a stopgap.

  3. If you cannot update today, uninstall Field UI

    In the admin menu go to Extend, then Uninstall, tick Field UI and confirm. With Drush, run drush pmu field_ui. Drupal names this as protection while sites are updated. It removes the screens for managing fields and display settings until you turn the module on again. It does not replace updating. Drupal Steward covers some known attack vectors, not all.

  4. Search your own code

    Search your custom and contributed modules for region_callback, field_ui_table and tablePreRender, as Fortbridge advises. A match that takes input from a request needs a developer's review. Also update Entity List to 3.0.10 if you use it.

  5. Watch the files folder

    Fortbridge advises keeping the stock .htaccess rule that blocks PHP in the public files folder, and alerting on changes to files/.htaccess. A copy of settings.php or a new .php file under sites/default/files is a strong sign of a problem.

  6. Update PHP as well

    Check the PHP version on the same servers. PHP2Shell is a separate flaw, and Drupal sites need both updates.

Questions

Is my Drupal site at risk if I have no extra modules?

The advisory says core alone is not directly exploitable. Fortbridge found that the only core Field UI table sits on an admin form. But custom code and contributed modules count. Update anyway, because it takes the sink away.

Is CVE-2026-108097 being exploited?

CISA had not listed it in the KEV file released on 21 October. A public lab exists, but it needs a synthetic writer module, and no real writer has been named.

Which Drupal versions are affected and which are fixed?

Affected: 8.9.0 up to the fixed releases. Fixed: 11.4.10, 11.3.19 and 10.6.19, and 12.0.0-beta2 contains the fix. Branches 11.2 and below, and 10.5 and below, get no fix.

Should I uninstall Field UI?

Only as a stopgap if you cannot update at once. Drupal names it as protection while sites are updated. It removes the admin screens for fields and display settings, and it is not a substitute for updating.

Is there a public exploit?

There is public technical detail and a lab that works only with a synthetic module. A mass-target tool exists, but its writer entries are placeholders.

Does updating PHP fix this Drupal flaw?

No. PHP2Shell is a separate bug in the PHP engine. A Drupal site needs the Drupal update and the PHP update.

In our research

  1. PHP End of Life: Which Versions Still Get Security Fixes October 2026
  2. PHP2Shell: Two Critical PHP Flaws Reported as RCE, CVE-2026-109618 and CVE-2026-109619 October 2026

Sources

  1. Drupal core critical: Remote code execution, SA-CORE-2026-014 Drupal.org
  2. PSA-2026-10-12: Drupal core security release announcement Drupal.org
  3. Entity List critical: Remote code execution, SA-CONTRIB-2026-218 Drupal.org
  4. Monster Menus critical, SA-CONTRIB-2026-253 Drupal.org
  5. Drupal core cross-site scripting, SA-CORE-2026-015 Drupal.org
  6. Drupal core cross-site scripting, SA-CORE-2026-016 Drupal.org
  7. CVE-2026-108097 deep dive: turning a Drupal Field UI callback into RCE Fortbridge
  8. Known Exploited Vulnerabilities catalog CISA