What is CVE-2026-108097?
CVE-2026-108097 is a remote code execution vulnerability in Drupal core’s Field UI module, published by the Drupal security team as SA-CORE-2026-014 on 14 October 2026. Drupal rates it Critical, 19 out of 25, with the vector AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:Default.
The flaw sits in how Field UI builds its tables. A row in the render array can carry a region callback, and that callback was executed as a PHP callable. Data that should have been treated as markup instructions was treated as code instead. The October releases replace the callback with a declared value.
The precondition is what defines this advisory, and it is unusually important to get right. Drupal states plainly that core on its own is not directly exploitable. Core’s own use of the vulnerable table sits behind the administrative Manage Display form, which rejects unauthenticated requests. Reaching the callback requires a contributed module or custom code that lets request-influenced data land in that render array key. Drupal says at least one known exploit path requires no authentication, and names no module.
Independent technical analysis published after the advisory reached the same conclusion from the other direction. Researchers demonstrated the full chain end to end, but did so using a bridge module they wrote for the lab, and reported finding no genuine public contributed module using the pattern. Drupal’s own exploit maturity rating of theoretical is consistent with that picture.
None of this makes the advisory soft. It means the risk is conditional on code a site owner may not have written and may not have audited. The affected population is effectively every supported Drupal install, the dependency is invisible from outside, and Drupal’s security team warned administrators to reserve time for the update because exploits could follow within hours or days. No exploitation has been reported at publication.
What should not happen is a site concluding it is safe because it runs stock core. The question is not whether core exposes the sink. It is whether anything else installed on the site does.
What assets are affected by CVE-2026-108097?
The affected range is broad: Drupal core from 8.9.0 up to 10.6.19, from 11.0.0 up to 11.3.19, from 11.4.0 up to 11.4.10, and the Drupal 12 pre-releases from 12.0.0-alpha1 up to 12.0.0-beta2. In practice that is every supported branch.
Fixed releases are 10.6.19, 11.3.19, and 11.4.10, applied according to the branch a site runs.
Two groups sit outside that list for different reasons. Drupal versions before 10.6.x, and Drupal 11 before 11.3.x, are end of life and unsupported, so they receive no fix here. Drupal 7 predates the 8.9.0 floor entirely and is therefore not in scope for this CVE, which is cold comfort: a Drupal 7 site is running a branch that stopped receiving security fixes long ago and carries a backlog of its own.
Scoping the real exposure requires an inventory most organizations do not keep. The version answers whether the site needs the patch. It does not answer whether the site is exploitable, because that depends on the contributed and custom modules installed, and specifically on whether any of them routes request data into a Field UI render row.
In practice an affected asset is a public Drupal site. Drupal’s typical deployments are corporate sites, brand and campaign microsites, public sector portals, and intranet-adjacent properties, all built to be reachable. Reachability is not the variable here. Module inventory is.
Externally, the module list is invisible, and the precise core version usually is too.
What does our data show about exposure patterns?
Exposure in this set is led by Consumer Staples at 30.53% of observed assets, with Industrials at 27.39% and Consumer Discretionary at 8.37%. The remaining sectors together account for 33.72%.
Those shares describe estate shapes more than industry risk. Drupal’s strength is running many sites from one platform team, so a single consumer goods group or public sector body can account for a large number of brand, country, and campaign sites. The sector ordering follows whoever in this data runs the largest multi-site estates.
Concentration bears that out. The largest single estate accounts for close to three in ten of the observed assets on its own, and adding the next largest estates takes it past half. Under that shape the chart is a statement about the largest publishers of multi-site platforms in the data, not about which industries are most at risk.
Almost every observed asset is a named web application rather than a bare address, which is what a content management footprint looks like from outside. These hostnames are public, indexed, and in many cases deliberately promoted.
Version evidence here is the best we have seen in this series, and it is still only half the picture. Around half of the observed assets carry no version indicator at all, and most of those that do record only the major line rather than a patch level. Given that the affected range spans entire branches rather than a narrow window, a major line is more useful here than it usually is: knowing a site is on 10 or 11 at least places it inside the affected range, since every supported branch is affected.
A small share of the observed assets sit on Drupal 7. Those are outside this CVE’s range, and that fact is worth almost nothing to the organizations running them, because they are on an unsupported branch that will not receive this fix or any other. Any inventory produced for this advisory should flag them separately rather than marking them not applicable.
A meaningful minority of the observed assets already carry platform findings, most commonly an exposed Drupal login panel, with smaller groups showing directory listings or reachable installer pages. Those are not this vulnerability, but they say something about maintenance posture, and a site with a reachable installer is not a site whose module inventory anyone has audited recently.
Roughly one in sixteen of the named sites carries a staging, test, or demo marker in its hostname. On a multi-site platform those environments usually share the codebase and the module set with production while sitting outside the release calendar, which makes them the likeliest place for an unpatched core and an experimental contributed module to coexist.
Geographically the set concentrates in the United States, the Netherlands, and Germany, which together account for the large majority. Given the European composition of the largest estates, the United States share is better read as hosting and content delivery placement than as market footprint.
Are fixes available?
Yes. Drupal released fixed core versions on 14 October 2026: 10.6.19, 11.3.19, and 11.4.10. Sites on Drupal 12 pre-releases should move to 12.0.0-beta2 or later.
Unusually for an advisory of this severity, there is also a real workaround. Drupal states that uninstalling the core Field UI module protects a site while the update is scheduled. Field UI is an administrative convenience for editing content types and display settings, not a runtime dependency for serving pages, so a site with a settled content model can uninstall it with limited operational cost. That is a genuine option for estates where a coordinated core upgrade across a large site portfolio will take longer than the patch window should.
Drupal also notes that sites using its Drupal Steward service have partial protection, and is explicit that this does not cover every possible exploit path and is not a substitute for upgrading.
The sequencing advice for large estates is to patch or uninstall Field UI first on anything internet-facing, then work through the module audit afterwards, rather than the other way round. Determining which contributed modules could expose the callback is a slower exercise than applying the release, and the release closes the issue regardless of the answer.
Are there any other recommended actions to take?
Until patching is confirmed, defenders should:
- Inventory every internet-facing Drupal site with its exact core version and branch
- Apply 10.6.19, 11.3.19, or 11.4.10 according to branch, and move Drupal 12 pre-releases to beta2 or later
- Where an immediate upgrade is not possible, uninstall the core Field UI module as the published workaround
- Include staging, test, and demo sites in the same change, since they usually share the codebase with production
- Flag end-of-life installs, including Drupal 7 and unsupported 10.x and 11.x branches, as migration work rather than patch work
- Review contributed and custom modules for any code that routes request data into Field UI render rows
- Close unrelated findings that signal neglect on the same hosts, such as reachable installer pages and directory listings
- Watch application logs for unexpected PHP callable execution and for administrative form requests from unauthenticated sources
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-108097 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
