Drupal Patches a Critical Code-Execution Flaw That Core Alone Cannot Reach, and Unsupported Branches Get No Fix

Drupal shipped security releases on Wednesday, October 14 for a critical remote code execution flaw in the Field UI module of its core: 11.4.10, 11.3.19 and 10.6.19, plus 12.0.0-beta2 for the pre-release branch. The advisory, SA-CORE-2026-014, tracks it as CVE-2026-108097 and scores it 19 out of 25 on the Drupal Security Team’s own scale. Drupal says core alone is not directly exploitable, but that several exploit paths exist through contributed modules, that at least one known path needs no login, and that custom code can expose the vulnerable function too. A second critical advisory, SA-CONTRIB-2026-218 (CVE-2026-108099), covers the contributed Entity List module, fixed in 3.0.10.

As of Sunday, October 18 we found no report of attacks and no public exploit, and neither CVE is in CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.16 when we checked on Sunday morning). That is not the same as safe. The Security Team pre-announced the release on October 12 and warned that “exploits might be developed within hours or days,” and in May a different core flaw came under attack less than two days after its fix. The advisories do not name the contributed modules that provide the exploit paths, so a site owner cannot clear their own site from the advisory text alone.

Below: what the fix changed in the code, why the score is 19 and what would raise it, how many sites sit on branches that get no patch, how fast attackers have moved on Drupal before, and the shortest safe response.

The five advisories at a glance

The Security Team published five advisories on October 14: two critical code-execution flaws and three cross-site scripting (XSS) flaws. The Droptimes lists all five, and Pantheon’s release note and The Hacker News confirm the critical core flaw and its fixed versions.

None of the three XSS flaws is a drive-by. The Hacker News says the two core ones need at least a logged-in user, and The Droptimes says the Navigation and Gin ones need a role that can enter HTML with certain data attributes or the administer menu permission. The same core releases fix the Link and Navigation flaws, and Entity List and Gin need their own updates because updating core does not update contributed code.

The fix replaces a single call

Drupal’s core releases are mirrored on GitHub as drupal/core, a split of the project’s core directory, so we compared the tags for 11.4.9 and 11.4.10. The release is four commits that touch five files, with 23 lines added and 7 removed. The first commit, titled “fix: SA-CORE-2026-014,” is the Field UI fix. It replaces one line with four in core/modules/field_ui/src/Element/FieldUiTable.php (the mirror’s paths leave off the leading core/), the code that builds the Manage fields and Manage display tables:

-          $region_name = call_user_func_array($row['#region_callback'], [&$row]);
+          $region_name = $row['region']['#value'] ?? '';
+          if (!isset($regions[$region_name])) {
+            $region_name = isset($regions['hidden']) ? 'hidden' : array_key_first($regions);
+          }

Before the fix, each row of that table could carry a PHP callable in a property named #region_callback, and Field UI ran it to decide which region of the table the row belonged in. After the fix, the region comes from the row’s own value, and a value that is not a known region falls back to the hidden region or, if there is none, the first region. In core the property is set only by the display forms themselves, each time to one of their own methods: we searched the extracted 11.4.9 source and found two places in EntityDisplayFormBase.php and one in a test module. Our reading is that for the property to hold anything else, some other code has to put attacker-influenced data into a Field UI table row, which fits Drupal’s statement that core alone is not enough. The advisories do not say how the known paths work, and we did not try to find them.

This is the same shape as WordPress 7.1.2 in September, whose core file-inclusion bug reached code execution only when the server also held a suitable PHP file and setting. In both cases a severity label describes the core code, while the real exposure depends on what else is installed.

The Hacker News explains why an older safeguard did not catch this: Drupal’s renderer has refused to run untrusted render callbacks since version 8.8, but it trusts the table element’s own pre-render method, so the check never reached the callable that method then ran. We did not trace the renderer ourselves. What we could confirm is the surrounding history: the trusted-callback trait appears in the 8.8.0 tree and not in 8.7.0, the replaced line is present in every tag we checked from 8.5.0 through 12.0.0-beta1 (it is not in 8.0.0), and it is gone from 10.6.19, 11.3.19, 11.4.10 and 12.0.0-beta2.

Two practical points follow from the diff. The update is small: the PSA asked sites to move to the latest patch release before October 14, and for a site already on 11.4.9 the security release is the five-file change above. And the property is still described in the file’s own comments, but Field UI no longer calls it, so custom code that set #region_callback on a Field UI table row will stop being run. The Hacker News says Pantheon advises testing the Manage fields and Manage display pages after updating.

The Link fix is smaller still. It adds attribute names that start with hx or data-hx to the list the Link module’s attribute filter skips. Those are the prefixes HTMX uses, so that looks like the issue, but The Droptimes describes the flaw only as insufficient sanitisation of certain markup, and the reading is ours.

Why the score is 19, and what would raise it

Drupal’s score is a sum of six factors defined on its risk-levels page. The advisory’s vector is AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:Default. With the point values on that page, access complexity Basic is worth 2, authentication None 4, confidentiality impact All 5, integrity impact All 5, exploit Theoretical 1 and target distribution Default 2. That makes 19, the top of the Critical band, which runs from 15 to 19.

The exploit factor is the one that moves. It is worth 1 point while no public exploit code or documentation exists, which The Hacker News reads as the advisory’s state at publication, 2 once a proof of concept is documented, and 4 once an exploit is in the wild.

So the advisory sits one point below the top band, and under that scoring a documented proof of concept would put it in that band. The arithmetic is ours, and Drupal has not rescored the advisory. We read the risk-levels page through a fetch tool that summarizes pages, so the check we relied on is that the six point values sum to the advisory’s 19.

Who is left without a fix

Drupal publishes weekly counts of the sites that report which core branch they run. The usage page for the week starting October 4 totals 531,499 sites. Adding the columns for the branches the advisory lists as affected and that get no fix (8.9.x, 9.x, 10.0.x to 10.5.x and 11.0.x to 11.2.x) gives 151,442 sites, the 28.5 percent figure The Hacker News reports, so that number reproduces.

These counts come only from sites that report their version to Drupal, and they predate the fix. Once the 8.0.x to 8.8.x sites are counted as well, 170,927 of them, or 32.2 percent, run a branch with no patch at all. The branches with a fix are not a permanent refuge either. Drupal’s release schedule ends security support for 11.3.x and 10.6.x in the week of December 7, 2026, when 12.0.0 and 11.5.0 are due, and The Hacker News also puts it in December. Those two branches hold 221,878 of the reporting sites (41.7 percent). On the module side, 90 sites reported Entity List that week, 87 of them on 3.0.x.

How quickly attackers might move

In May the pattern was faster. Drupal released a core SQL injection fix, CVE-2026-9082, on Wednesday, May 20, the date in Packagist’s advisory feed. By Friday, May 22 Drupal had updated its advisory to say “exploit attempts are now being detected in the wild,” and CISA had added the flaw to its catalog with a May 27 due date. The Hacker News reported on May 23 that Imperva had observed more than 15,000 attack attempts against almost 6,000 sites in 65 countries. That flaw affected only sites on PostgreSQL, and Imperva called most of the early activity probing.

The two cases differ. The May flaw sat in core’s database layer, while this one needs a second component, which may slow attackers down. Against that, the fix is public, the Field UI change is a single file, and the Security Team says it already knows at least one path that needs no login. Our SonicWall item shows how short the gap can be: attempts against a CVSS 10 SonicWall flaw were seen two to three days after the vendor’s October 6 patch. We cannot say which effect wins here, and four days without a report is not evidence that no one is trying.

What to do now

Update core. Move to 10.6.19, 11.3.19 or 11.4.10, whichever matches your branch. Drupal 12 pre-release sites can use 12.0.0-beta2, which is not meant for production. Sites on 11.2.x and earlier, 10.5.x and earlier, 9 or 8 are end-of-life and get no patch, so the fix for them is a move to a supported branch.

Update Entity List separately. If the module is installed, take it to 3.0.10. Its release note says the fix mirrors the Field UI change, according to The Droptimes, but the advisories do not say the two flaws share a cause.

If you cannot update today, uninstall Field UI. The advisory says this “will provide protection while sites are updated,” as quoted by The Hacker News, and the admin pages for managing fields and their display are unavailable until the module is back. The Hacker News notes that Drupal’s Standard install profile installs Field UI, so a site built from that profile has it unless someone removed it. With Drush 13, whose documentation lists pm:uninstall and uses field_ui in its own --simulate example, preview first, because the command also uninstalls modules that depend on the one you name:

drush pm:uninstall --simulate field_ui
drush pm:uninstall field_ui

If you deploy configuration from version control, the uninstall also has to reach your exported configuration, or a later import may switch the module back on. We did not test that.

Do not rely on a firewall alone. The Hacker News says Drupal Steward, the web application firewall service whose rules the Security Team writes, is run for customers by Acquia, Pantheon, Ironstar and Skpr. The advisory says its protection does not cover every possible exploit, so those sites should still update.

Check custom code. Search your own modules and themes for region_callback. Anything that set it on a Field UI table row stops being called after the update.

Sources and method

Drupal’s own pages (the PSA, the two critical advisories, the risk-levels page and the release schedule) show scripted clients a verification challenge, so we read them through a fetch tool that returns a summary, and we checked each fact we use against raw text from Pantheon, The Droptimes, The Hacker News and BleepingComputer. The exception is the risk point values, which we verified by summing them to the advisory’s 19. The code facts come from the drupal/core mirror on GitHub: the compare of 11.4.9 and 11.4.10, raw files at tags from 8.0.0 to 12.0.0-beta2, and a text search of the extracted 11.4.9 and 11.4.10 source archives. Release dates come from Packagist, the catalog check from CISA’s KEV JSON feed, and the site counts from Drupal’s usage pages for the week starting October 4. Weekdays, shares, sums and the score table are our arithmetic. We did not run Drupal, did not test any exploit, and did not look for the contributed-module paths. Times are UTC.