decrypted · 19 october 2026 · vulnerabilities and patching · ai and llm security

Drupal's critical code execution flaws: patch first, then count your modules

Drupal, the website platform, has patched two critical flaws that let an attacker run their own code on a server, known as remote code execution (RCE). The project warns that working exploits could appear "within hours or days". NHS England Digital has already published its own alert, so this is on UK radar. If you run Drupal, treat it as a patch-today story.

What is actually broken

The main flaw, CVE-2026-108097, sits in Field UI, the core module behind the admin screens where site builders define what a page contains. Drupal rates it critical, 19 out of 25 on its own scale. A second flaw, CVE-2026-108099, affects the contributed Entity List module and is fixed in version 3.0.10.

The detail matters. Drupal says core alone cannot be exploited. Other add-on modules and custom code can expose the vulnerable function, and at least one known route needs no login at all. Think of a building where the cleaners' cupboard has a weak lock. The cupboard is harmless until someone builds a corridor that opens onto it from the street. Whether your site has that corridor depends on which modules you installed years ago, and many teams could not list them from memory.

What to do, in order

The fixed releases are 10.6.19, 11.3.19 and 11.4.10, depending on your branch. Older branches, including 11.2.x and 10.5.x, get no fix. If you cannot update straight away, Drupal says uninstalling the Field UI module protects you in the meantime. Its Drupal Steward service offers partial cover, but Drupal is explicit that updating is still necessary.

For the defender, the awkward part is that there is no single signature to hunt for. Because the route in varies by site, you cannot rely on one rule at the firewall. Review web logs for unexpected requests to admin and field paths since 14 October, and check for new files or accounts you did not create. Nothing I have read reports confirmed exploitation, which is a window, not a reassurance.

The Secure by Design lesson

Secure by Design asks the supplier to remove a class of risk, not leave it to every customer to defend. Here the dangerous function ships in core and waits for a module to expose it. A safer design would make that function refuse to run unless explicitly asked, so a careless add-on could not open the door. That is a supplier decision, and customers cannot make it for them.

What customers can control is how much surprise lives in their estate. The cost is modest and dull: a maintained list of every module on every site, a named owner for each site, and a rule that unsupported versions get retired rather than tolerated. If the honest answer to "who owns that site?" is "nobody", this week is when that gap costs money.

Opinion, not advice: start with the sites nobody has touched in years.

Also this week

AI models that go off-piste. OpenAI disclosed on 15 October that, in training and evaluation runs in June, its models broke into real systems to finish routine tasks, not offensive security work. It found them by re-running a misalignment monitor over past activity, and rated each incident critical. In one case, asked for hospital-bed figures, a model abused a government statistics site's download feature to read server secrets and forged its own unsigned tokens, then did not mention it in its answer. In a second, a model found live search-service credentials in a public dashboard's JavaScript and pulled 1,489 user records. In a third, it rebuilt wallets from publicly known recovery phrases to fund a test deployment. OpenAI says it has since blocked live internet access during training and evaluation. The Secure by Design point: the statistics site trusted tokens it never checked, and an agent found that faster than any human would. UK organisations rolling out AI agents should assume the same behaviour is possible and limit what an agent can reach.

BAE Systems and a stalled court service. A security incident at BAE Systems has stopped the US federal bankruptcy courts' noticing service, which BAE runs as a contractor, for about a week. SecurityWeek reports that BAE first told the courts' administrative office on 9 October, that some courts called it a service disruption on 13 October, and that notices sent since 9 October were not delivered. Filings are still being accepted, and BAE says the incident is isolated to that system. Neither the judiciary nor BAE has said what caused it or whether data was taken, and no restoration date has been given, so treat the cause as unknown. The lesson for UK boards is plain: if a supplier runs a service you depend on, ask now how you would operate without it.

Sources