Drupal's critical Field UI flaw has no fix for 28.5% of reporting sites; its team said exploits may take hours or days

28.5% of reporting sites have no fix, against a warning that exploits might take hours or days

In the week starting 4 October 2026, 151,442 of the 531,499 sites that reported a core version to drupal.org were on a branch that the Drupal Security Team's advisory SA-CORE-2026-014 lists as affected and for which it offers no update. That is 28.5 per cent, about one site in 3.5 (derived). The figure is The Hacker News's; this briefing reproduced it exactly from the usage page by adding four rows: 22,067 sites on 8.9.x, 51,011 on Drupal 9, 59,531 on 10.0.x to 10.5.x and 18,833 on 11.0.x to 11.2.x. The advisory, dated 14 October 2026, rates the flaw "Critical", 19 out of 25, and classes it as remote code execution in the Field UI module of Drupal core. Two days earlier the Security Team's pre-announcement had told site owners to reserve time because "exploits might be developed within hours or days".

What that does not establish is most of what a site owner wants to know. The usage page counts sites, not exposure. Nobody has published which contributed modules open a path to the flaw, how many sites run one, or whether any attack has been seen. The advisory says the flaw "is not directly exploitable with core alone", so a site on an unfixed branch is affected in the advisory's sense and is not shown to be reachable. The reverse also holds: the 67.3 per cent of sites on a branch that does have a fix (derived) are not safe until they have updated, and the usage page cannot say how many have, because its latest week ended before the fixes were published.

This briefing reads the Drupal Security Team's own pages, not the press coverage. It read SA-CORE-2026-014, the pre-announcement, the four release notes, the Drupal Steward pages, the usage statistics, the core release schedule, the risk-scoring page, the May 2026 advisory for a core SQL injection flaw, the CISA Known Exploited Vulnerabilities catalogue, and the CVE.org and NVD records, between about 13:45 and 14:30 BST on Thursday 15 October 2026. The Hacker News of the same day was read in full as the pointer. Where it says something the Security Team's pages do not, the text says so. Every figure marked derived was computed from those pages.

No exploit detail is given here and none is needed. The advisory classes the flaw as remote code execution and gives no mechanism. The Hacker News describes the code change as an administration-screen component acting on data it did not check; that is secondary reporting, and this briefing adds nothing to it.

Stated and not stated: the advisory, line by line

The table sets what SA-CORE-2026-014, the pre-announcement and the release notes say against what they do not. "Not stated" means not found in those pages or the Steward pages, read in full. It does not mean the information does not exist.

What the Drupal Security Team's advisory SA-CORE-2026-014 (14 October 2026) and related pages state, and what they do not. Quotations are the pages' own words.

The question	Stated	Not stated
Which modules open a path?	"not directly exploitable with core alone, but multiple serious exploit paths exist with contributed modules".	A module name, a count of modules, or how many sites run one.
Is a login needed?	"At least one known exploit path does not require authentication."	Which path that is, and whether the others need one.
Can custom code expose it?	"Custom code may also expose the vulnerable functionality."	How, or how often.
Has it been attacked?	Scored with the exploit metric at "Theoretical": no public exploit code or documentation. No update note on the advisory page as read at 13:44 BST on 15 October.	Any detection data. A missing note is not a finding of no attack.
What does Steward cover?	Sites on Steward "are already protected from some known attack vectors" but protection "will not cover all possible exploits".	Which vectors, how many sites route through Steward, or which hosts' customers are covered for this flaw.
Does the workaround work?	Uninstalling the core Field UI module "will provide protection while sites are updated".	Whether it closes every path, or whether a given site breaks without it. The Hacker News says the field management screens are unavailable meanwhile.
Which versions are affected?	From 8.9.0 up to the fixed release on each branch, and 12.0.0-alpha1 up to 12.0.0-beta2.	Anything on 8.0 to 8.8, or on Drupal 7. The May pre-announcement said "Drupal 7 is not affected"; the October pages are silent.
What about end-of-life branches?	11.2.x and below, 10.5.x and below, Drupal 9 and Drupal 8 "do not receive security coverage".	Any best-effort patch. In May the team provided fixes for end-of-life branches "as a best effort"; the October advisory does not.
Is there a CVE record and a CVSS score?	The CVE ID CVE-2026-108097 and the Drupal score 19/25.	A CVSS score. At 12:43 UTC on 15 October the CVE.org record API answered that the record does not exist, and the NVD API returned no result.
Who found it, and when?	Reported by a member of the Drupal Security Team and a second reporter not listed as a member; fixed by members of the team.	When it was found, how long it was known, or whether anyone else knew.

The arithmetic: 151,442, 357,777 and 22,280

The usage page says that for each week beginning on the given date, the figures show the number of sites that reported they are using a given version. The latest row is the week starting 4 October 2026. Its total, 531,499, equals the sum of the 32 branch columns on the page (derived). Sorting the branches by what the 14 October advisory and release notes say about each gives three groups and a remainder.

Sites reporting a core version to drupal.org, week starting 4 October 2026 (drupal.org/project/usage/drupal), grouped by the advisory's affected range and fixed versions. Shares are derived and rounded.

Branch	Sites reporting	Share of 531,499
8.9.x (no fix)	22,067	4.2%
9.0 to 9.5 (no fix)	51,011	9.6%
10.0.x to 10.5.x (no fix)	59,531	11.2%
11.0.x to 11.2.x (no fix)	18,833	3.5%
Subtotal: affected, no fix	151,442	28.5%
10.6.x (fix 10.6.19)	170,190	32.0%
11.4.x (fix 11.4.10)	135,899	25.6%
11.3.x (fix 11.3.19)	51,688	9.7%
Subtotal: fix released 14 October	357,777	67.3%
8.0.x to 8.8.x (below the stated range)	19,485	3.7%
11.5.x and 11.x development branches	2,039	0.4%
12.0.x beta (fix 12.0.0-beta2)	756	0.1%
Total reporting	531,499	100.0%

Four things the headline figure hides, each from the same page.

The week predates the fix. The fixed releases were published on 14 October. The week starting 4 October ended on 10 October (derived). No site could have been on 11.4.10, 11.3.19 or 10.6.19, so all 357,777 sites on those branches (67.3 per cent) were on an earlier release, and the page cannot say how many have updated since.

The base leaves out Drupal 7. The total of 531,499 sums branches 8.x to 12.0.x only. The per-release table on the same page also lists older major versions: 168,734 sites on Drupal 7 rows, 6,962 on Drupal 6 and 154 on Drupal 5 (derived). With them the base is 707,349 and the same 151,442 sites are 21.4 per cent (derived). Whether Drupal 7 is affected is not stated, and the advisory's range starts at 8.9.0.

The edge is a choice. Sites on 8.0.x to 8.8.x (19,485) sit below the advisory's stated start at 8.9.0. Counted as unfixed they would lift the share to 32.2 per cent (derived). The Hacker News's 28.5 per cent follows the advisory's range; the advisory does not say whether those older branches are affected or only untested.

It is a count of sites that reported. The page says "sites that reported" and does not say what share of all Drupal sites that is.

One more sum puts the December date next to the fix. The 11.3.x and 10.6.x branches, which both have a fix, lose security support in the week of 7 December, according to the core release schedule. They hold 221,878 sites, 41.7 per cent (derived). Add the 28.5 per cent with no fix and 70.2 per cent of reporting sites (derived) are on a branch with no fix now or with no security cover after the week of 7 December. Only 11.4.x, 25.6 per cent (derived), has cover beyond it: the 11.4.10 release notes say until June 2027.

The clock: the warning, the release, and what happened in May

The pre-announcement and the release are two days apart. All times below are UTC unless marked, and every interval is derived from the timestamps on drupal.org's own feeds and release pages.

This release, from the Drupal security and release feeds and the core release schedule.

Event	When	Interval (derived)
PSA-2026-10-12: release announced, "exploits might be developed within hours or days"	Mon 12 Oct, 16:10	Start
SA-CORE-2026-014 published	Wed 14 Oct, 16:10 (17:10 BST)	48 hours after the PSA
11.4.10, 10.6.19 and 11.3.19 published	16:16, 16:42 and 17:10	6, 32 and 60 minutes after the advisory
12.0.0-beta2 published	21:57	5 h 47 min after the advisory
This briefing first reads the advisory page	Thu 15 Oct, 12:44 (13:44 BST)	20 h 34 min after the advisory
Scheduled third-Wednesday core security window	Wed 21 Oct	7 days after the actual release

The release came a week before the scheduled window. The core release schedule puts security windows on the third Wednesday of the month, which in October is the 21st, and says a security release outside a window is preceded by a public service announcement. That is what happened. A team that planned its patching for 21 October had, on the record, a week less than it expected (derived). The pre-announcement also asked sites to move to the latest patch release before 14 October, so that they could deal with other upgrade issues first.

The May precedent is the one the Security Team's own pages record. SA-CORE-2026-004 was a SQL injection flaw in core that, the advisory says, "can be exploited by anonymous users" and "only affects sites using PostgreSQL". It is in the CISA catalogue as CVE-2026-9082.

SA-CORE-2026-004, CVE-2026-9082: the Security Team's pre-announcement and advisory, the CVE.org record and the CISA catalogue entry (read as JSON on 15 October).

Event	When	Interval (derived)
PSA-2026-05-18 scores it 20/25 with the exploit metric at "Theoretical"	Mon 18 May, 18:29	Start
Advisory published	Wed 20 May, 18:08	47 h 39 min after the PSA
Advisory updated: score now 23/25, "exploit attempts are now being detected in the wild"	Fri 22 May, 04:30	34 h 22 min after the advisory
Added to the CISA catalogue; due date 27 May	22 May (date only)	2 calendar days after the advisory; 5 days to the due date

Three cautions on reading that table across. First, 20 to 23 is arithmetic. On the Security Team's scoring page the exploit metric is worth 1 point when "Theoretical" and 4 when an exploit exists. Applied to SA-CORE-2026-014 the same change takes 19 to 22 (derived), which is the "Highly critical" band, 20 to 25. Second, the May flaw was reachable by anonymous users through a core code path; the October flaw, in the advisory's own words, needs something more. The May interval is a precedent and not a forecast (inference). Third, the update note does not say who detected the attempts, how they were detected or at what scale.

The year's other advisories give the pattern. There have been 16 core advisories in 2026, SA-CORE-2026-001 to 016 with none missing, published on six days (derived from the Security Team's feed). Four carry the label Critical or Highly critical (derived). Only one of the 16 has an exploitation note, and only one of the advisories' CVE IDs is in the CISA catalogue.

The four 2026 core advisories labelled Critical or higher, from the Drupal security feed and the CISA catalogue (version 2026.10.14).

Advisory	Label and score	Exploitation record as read
001, cross-site scripting, 15 Apr	Critical, 15/25	No update note; not in the catalogue
004, SQL injection, 20 May	Highly critical, 20 then 23/25	Update note 22 May; catalogue 22 May
005, PHP object injection, 17 Jun	Critical, 18/25	No update note; not in the catalogue
014, remote code execution, 14 Oct	Critical, 19/25	No update note; not in the catalogue, as read on 15 Oct

So "critical" has not meant "exploited" on this year's record: one of four, one of 16 (derived). It has not meant "safe to wait" either, because the one that was exploited was exploited within 34 hours (derived). "No update note" and "not in the catalogue" describe one page and one file on one afternoon. They are not detection results, and the catalogue's own listing follows exploitation by definition.

Eight friendly names, and what each hides

A label can do the work of a control. Eight in this story do.

Labels used in the advisory, its release notes and the coverage, read against the Security Team's own definitions and pages.

The label	What it suggests	What it hides
"Critical"	The top tier: act now.	A band on Drupal's own scale, 15 to 19. "Highly critical" starts at 20, one point away, and an exploit would take this flaw there (derived). Cyber Essentials treats the vendor's word as a 14-day trigger, so the label sets a deadline.
"19 out of 25"	A measurement.	Arithmetic on six inputs. Impact scores 10 of the 19 points, no login needed 4, and an assumed absence of any exploit 1. The pre-announcement and the advisory score different inputs and both reach 19 (derived).
"Not directly exploitable with core alone"; "contributed modules"	Core is safe; the risk is elsewhere.	The risk is in your module list, which the advisory does not give. A second critical advisory the same day, for one contributed module, carries the same conditions (The Hacker News reports it; the advisory was read), and updating core does not update the module.
"Does not require authentication", "unauthenticated"	A property of the flaw.	A property of one known path through an unnamed module. Other paths may need a login. The Hacker News headline compresses it to "Unauthenticated RCE Path via Contributed Modules". For your site it is true only if your module set contains such a path.
"Protected by Drupal Steward"	Covered.	A firewall rule blocking "some known attack vectors". It reaches only sites whose traffic runs through the service: customers of four named hosts, or sites routed through it from $15 a month. Steward's page says it "isn't a substitute for patching". No count of protected sites is given.
"End of life"	Old, but patched if it is serious.	No update. In May the team released fixes for end-of-life branches as a best effort. In October it did not, and the pre-announcement tells those sites to update "as soon as possible". 28.5% of reporting sites are here (derived).
"Supported branch"	Safe to stay.	Supported until a date. 11.3.x and 10.6.x lose security support in the week of 7 December, 54 days after the fix (derived). Supported also does not mean updated.
"Standard" install profile	A sensible default.	Its own description reads "Install with commonly used features pre-configured". The profile files for 10.6.x, 11.4.x and the 11.x branch list the Field UI module. A flaw in a default administration module reaches every site built from the profile unless someone removed it.

The "Standard" row rests on source files, not on the advisory. The profile file for the 11.4.x branch lists the Field UI module among the modules the profile installs, as do the 10.6.x and 11.x files read the same day. That is a statement about new installs from that profile. Sites built long ago, or built on another profile, may or may not have the module; the Security Team's usage page does not count modules.

The Steward claim is worth reading in full, because it is the label most likely to be taken for a fix. The Steward page describes a web application firewall rule written by the Security Team and says protection is live when the advisory is. Its FAQ says the service is run by the Drupal Association or a platform partner and that site owners route traffic through it. The page says it protects "the highly critical, mass-exploitable class" of flaws that can be blocked at the request layer, "not every issue and not zero-days", and that Steward "isn't a substitute for patching". For this flaw the advisory goes further: sites should "upgrade in the near future in case additional attack vectors are discovered".

The second advisory is worth a sentence. It covers one contributed module, is also scored Critical 19/25, and says there are multiple serious exploit paths with other contributed modules. This briefing does not name the module, because the core advisory names none. Its drupal.org usage page shows 90 sites in the week starting 4 October. That is a figure for one module, and the core advisory says there are several others.

Which fix, for which branch, until when

Fixed versions and security cover from the 11.4.10, 11.3.19, 10.6.19 and 12.0.0-beta2 release notes, the core release schedule and SA-CORE-2026-014.

Branch you run	Fix	Security cover, as stated
11.4.x	11.4.10	Until June 2027, when 11.6.0 is released (release notes).
11.3.x	11.3.19	Until December 2026, when 11.5.0 is released; the schedule says the week of 7 December.
10.6.x	10.6.19	Until Drupal 10 ends on 9 December 2026.
12.0.0-beta1	12.0.0-beta2	A beta, "not intended for production".
11.2.x and below, 10.5.x and below, Drupal 9, Drupal 8	None offered	End of life: they "do not receive security coverage".
Drupal 7	Not in the advisory's range	End of life since 5 January 2025. Pantheon says its Drupal 7 long-term support with Tag1 Consulting has shipped 7.107 with a backport of the fix.

The same releases fix two moderately critical cross-site scripting flaws, SA-CORE-2026-015 and SA-CORE-2026-016, scored 13 and 12 out of 25, each with a user-level account in the vector. The 11.3.19 and 10.6.19 notes add that they also update CKEditor to fix a bug introduced in SA-CORE-2026-013, the September advisory. So the update is one package that, on the Cyber Essentials text, contains a critical fix.

On Drupal 7, the record is split. The Security Team's advisory does not mention it and its range starts at 8.9.0. Pantheon's release note says Drupal 7.107, part of its long-term support with Tag1 Consulting, "backports the fix" and tells owners to apply the latest upstream update. A backport suggests the code exists on Drupal 7 (inference). Pantheon sells the hosting that includes the support, which is the vendor's interest here, and the Drupal 7 population on the usage page, 168,734 sites on Drupal 7 rows (derived), is outside the 531,499.

UK: what the rules say, and where each stops

Everything below is read from the primary page on 15 October 2026. Each item says where it stops, because every one of them is silent on the question the advisory leaves open: which of your sites has a path.

Cyber Essentials. The requirements for IT infrastructure, v3.3, April 2026, in the security update management section, say software in scope must be "licensed and supported", must be removed when it becomes unsupported or taken out of scope by a defined sub-set with no internet traffic, and must be updated "within 14 days" of release where the vendor describes the fixes as "critical" or "high risk", where the CVSS v3 base score is 7 or above, or where the vendor gives no level. A caution adds that an update covering any such issue among others must be installed within 14 days. Drupal's label is Critical, so the rule applies to this update and, because it is one package, to the two moderately critical fixes that ride with it. Counting from the 14 October release gives 28 October (derived). The secure configuration section separately requires you to remove or disable "unnecessary software", and names pre-installed unnecessary applications as a weak point.

Where it stops. No CVSS score exists yet for this CVE in the records read, so only the vendor's label triggers the rule. The scheme text does not say whether a CMS module counts as software in the unnecessary-software sense. A certificate is a statement about the scope and the date it was assessed. And an end-of-life branch cannot meet "licensed and supported" unless it is removed from the scope (inference from the text).

NCSC update guidance. The NCSC's update-by-default guidance (version 2.1, reviewed 1 May 2026) gives 5 days for internet-facing services and software, for all updates regardless of severity: 19 October for this release (derived). It adds that when a vulnerability is fixed, "attackers will often study the vulnerability and attempt to write exploits for it", which is the race the Security Team's pre-announcement describes. Where it stops: it is guidance, it tells business-critical systems to balance the timescales against availability, and it does not tell you which sites have a path.

NCSC on active exploitation. The NCSC's guidance on responding to active exploitation (version 2.1, 1 May 2026) has a table keyed to the CISA catalogue. If a flaw is listed, internet accessible, automatable and gives total control, the update goes in within 24 hours plus an investigation by an assured incident response provider; if it is not automatable the window is 48 hours; if it is not internet accessible, 72. CVE-2026-108097 is not in the catalogue version read, so on the record that table has not been triggered. If exploitation is reported, it applies, and the page tells security teams to look for signs of compromise while IT teams update. The page also notes that the catalogue only lists exploitation that has already happened. No NCSC alert for this flaw was found in the searches made; the NCSC's own search page returned nothing static to read.

That page also says flaws that are mass exploited are often in functionality that is not the product's core purpose but is enabled by default, and that "all unnecessary functionality should be disabled or otherwise blocked". Uninstalling the Field UI module where it is not needed is that advice applied to a CMS (inference). The NCSC's guidance for website owners says that if you use a CMS you "must install security updates when the vendor releases them", including themes and plugins, and its blog on internet-facing services says to disable optional ports and functionality you do not use. For the 28.5 per cent, the NCSC's patch wave blog of 1 May 2026 is the relevant text: patching alone will not always suffice on end-of-life technology, and organisations will need to "replace technologies, or bring them back within support".

ICO and the 72 hours. Article 33 of UK GDPR, as printed on legislation.gov.uk on 15 October, requires a controller to notify a personal data breach "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless it is unlikely to result in a risk to people's rights and freedoms. The printed article names "the Commission", a substitution dated 30 September 2026 in its amendment notes; the ICO's reporting page, last updated 28 May 2025 and flagged as under review, still speaks of the ICO. A vulnerability is not a breach, and the clock starts on awareness of a breach, not of an advisory (inference from the wording). But the advisory scores confidentiality and integrity impact at the highest value, "All". A site that holds accounts, form submissions or case data and was reached would raise the question, and the practical test is whether you could tell.

The UK footprint. The only primary found for UK public-sector use is the LocalGov Drupal project's home page, which counts 77 council sites and 86 microsites and says its CMS is "trusted by over 50 councils". Those are the project's own figures, read on 15 October. Nothing read says how many of those, or of any university or central government site, are on an affected branch, so no UK exposure figure is given.

Clocks that apply, as read on 15 October 2026. Dates are derived from the 14 October release.

Clock	Starts at	For this release
NCSC best practice, internet-facing services: 5 days	Update published	19 October
Cyber Essentials: 14 days for critical or high-risk fixes	Update released	28 October
NCSC active-exploitation table: 24, 48 or 72 hours plus investigation	A catalogue listing, with the other conditions	Not triggered as read: no listing
UK GDPR Article 33: 72 hours, where feasible	Awareness of a personal data breach	Not started by the advisory
Security support ends, 11.3.x and 10.6.x	Core release schedule	The week of 7 December, day 54

What to do, in order, for three kinds of owner

The order matters more than the length. Each list starts with finding out what you run, because the advisory cannot tell you.

The question that exposes the gap

Which record of yours says, site by site, whether a contributed module or custom code gives a stranger a path to this flaw, and who last read it?

The advisory cannot answer it, Steward cannot answer it, and the usage page cannot answer it. Your inventory can, and only if someone built it before 16:10 UTC on 14 October.

Key facts