decrypted · 29 october 2026 · ransomware and cybercrime · vulnerabilities and patching · ai and llm security

Bristol's schools platform ran four days after the alarm, and the lesson is isolation

Bristol City Council first noticed suspicious activity on Trading with Schools, the platform it runs for local schools, on 21 September. It did not shut the service down until 25 September. This week a ransomware group called Wallstreet listed the council on its leak site. Nothing public ties that listing to the schools incident, so treat it as a claim. The four days are the story.

What is known

The BBC reported on 5 October that Trading with Schools is used for scheduling, budgets, staff details and payroll, and can also hold sensitive files about children, including educational psychology records. Council leader Tony Dyer confirmed malicious software was found. He said analysis had "not identified any evidence that data has been stolen", and that acting quickly limited its spread. The council disconnected affected schools from the internet. The BBC put the number at 87 schools, while a council figure reported elsewhere was about 80. Police are investigating.

The tracking site ransomware.live logged the Wallstreet listing on 27 October. A leak site is where criminals post victims' names to pressure them into paying. This entry shows no ransom demand, data volume or sample files, and the council has not confirmed it. Equally, no evidence of theft is not proof that nothing was accessed.

Why four days is a design problem

Think of a building where one fire door joins every classroom. A smoke alarm is useful only if someone can close that door within minutes. Here, a shared platform joined dozens of separate schools, and closing it meant cutting them all off. That is a hard call to make on a hunch, so it took four days.

Experts told the BBC that four days is a long time for malicious software to sit in a system. Attackers use that window to copy data and delete logs, the equivalent of a burglar closing the front door behind them.

Secure by Design asks different questions before any incident. Can one school be isolated without taking down the other eighty-odd? Can the council contain a single school on its own authority, with the decision agreed in advance? Are logs kept somewhere an intruder cannot reach?

What it costs to apply

Less than the outage, and none of it needs new technology. Pre-agreed isolation rules cost a meeting and a runbook. Separating each school's data costs engineering time at build, but turns a regional shutdown into a local one. Rehearsal costs an afternoon: declare a suspected intrusion on the shared system, and time how long it takes someone with authority to say yes.

Any UK director whose organisation runs or buys a shared platform, whether for schools, clinics or branches, should ask one question: who can switch it off, how fast, and what breaks for everyone else when they do? If the answer is "it depends who is in the office", that is the finding.

Also this week

Exploited kernel and hypervisor flaws. On 28 October CISA added two flaws to its KEV list, the flaws known to be exploited in real attacks: CVE-2026-46300 in the Linux kernel and CVE-2026-41709 in VMware's hypervisor software. CVE numbers are the public reference numbers for known flaws. SecurityOnline reports that CISA says the kernel flaw is being chained with the PHP2Shell bugs covered here last week, so that a web foothold becomes full control of the machine. Fixed kernel releases include 6.1.174, 6.6.141 and 6.12.91. The VMware flaw lets a malicious administrator act without being logged, so it helps an intruder hide rather than get in. The National Cyber Security Centre's patch-wave guidance says to start with internet-facing technology, and this pairing shows why: the exposed layer and the layer beneath it are one attack path, not two tasks. Ask your hosting provider which kernel your servers run, and whether the patch is applied rather than scheduled.

AI workflow tools that run code by design. Endor Labs researcher Peyton Kennedy documented 14 findings across seven AI orchestration platforms, including Flowise, Langflow and Dify. In Flowise 3.1.2, an unauthenticated request could get the model to write Python that slipped past a 38-pattern blocklist and ran commands on the server. Endor says development of Flowise stopped on 29 July and the repository was archived on 10 August, so there will be no further patches. Some Kestra and Dify findings were closed as intended behaviour. The Secure by Design lesson is blunt: a tool whose job is to let a model run code needs its sandbox built in before launch, not a blocklist of forbidden words added afterwards. Treat any abandoned open source project in your stack as an unpatched one, and ask suppliers which orchestration tools sit behind their AI features.

Sources