Drupal's critical core RCE can't be triggered by core alone — that's the worrying part
The advisory that went out on 14 October has a line in it that's more unsettling than its "Critical, 19/25" score: the bug can't be exploited by Drupal core alone. You need contrib or custom code to complete the path — and at least one known path needs no authentication. That inverts the question you're supposed to ask on a release day, and it's worth sitting with.
What shipped
SA-CORE-2026-014 — "Drupal core - Critical - Remote code execution," dated 2026-10-14, CVE-2026-108097 (copy that number exactly; the sequence is unusually high). The flaw is in the core Field UI module. Affected: >=8.9.0 <10.6.19, >=11.0.0 <11.3.19, >=11.4.0 <11.4.10, and the early 12.0 alphas up to beta2. Fixed in 11.4.10, 11.3.19 and 10.6.19 — and the 11.4.10 release page notes "No other fixes are included," so this is a security-only release. 11.2.x and 10.5.x and earlier are unsupported and get nothing. It came with a two-day heads-up, PSA-2026-10-12, which named no component and warned "exploits might be developed within hours or days."
The advisory's own words: "not directly exploitable with core alone," exploit paths come "via contributed modules," "at least one known exploit path does not require authentication," and custom code can expose it too. The risk vector lists E:Theoretical — meaning no public exploit was known at publication. Two XSS fixes rode along: SA-CORE-2026-015 (Link module, 13/25) and SA-CORE-2026-016 (Navigation, 12/25), both needing some authenticated access.
Why "not exploitable by core alone" is the scary part
Normally you read a core advisory and ask: is my core version vulnerable? Here that's the wrong question. Core is the gadget; something else is the trigger. Which means composer outdated telling you core is patched doesn't fully answer "am I safe," because the exploit lives in the combination of core and whatever reaches it. The honest version of the question is "am I patched and what in my contrib surface could complete this," and the second half isn't something a version check answers.
I want to be careful here, because the advisory is deliberately vague and I'm not going to fill the gaps with guesses. There was also a critical contrib RCE the same day — SA-CONTRIB-2026-218 (Entity List, 19/25, fixed in 3.0.10) — with almost identical "not directly exploitable, other modules provide the path, one needs no auth" wording. It is tempting to connect them. I won't: neither page says they're linked, and I have no evidence Entity List is the unauthenticated path for the core bug. I also haven't read the patch or the issue, so I genuinely don't know the mechanics, and there's no sign it's being exploited in the wild — E:Theoretical is the only official word.
A critical with no detail and a two-day timer is a strange thing to defend against. The Security Team knew what to look for; nobody outside it did. The best you could do before the 14th was update to the latest patch — which is exactly what the PSA told you to do, and exactly why it told you early.
The mitigation is almost a tidiness lecture
The advisory offers a one-command out: drush pm:uninstall field_ui. And here's the thing — Field UI has no business running on a production site. It's a site-building tool for adding and editing fields through the admin UI; on a disciplined site your field changes come from configuration you deploy, not from clicking around prod. So the mitigation for a critical RCE is, for a lot of sites, just "turn off the thing you shouldn't have had enabled." The ops cost is real but small: you lose the ability to edit fields in the live UI, which you shouldn't be doing anyway. (Drupal Steward "is protecting" the vuln too, but the advisory is explicit that it "will not cover all possible exploits" — so treat Steward as a net, not the fix.)
What I actually did
Updated to the patched release first, before reading any further — that's the PSA's whole point. Then checked whether field_ui was even enabled where it shouldn't be. If you build config-in-code, uninstalling it on prod is close to free and closes the cheapest door. I'm not going to tell you my production state as a fact in a blog post, but the check is two minutes: drush pm:list --status=enabled | grep field_ui, and if it's on a public-facing environment, ask yourself why.