Russia Tried to Take Down a Swedish Heating Plant — And Your OT Network Is Next

Sweden's Civil Defense Minister dropped a bombshell last week: a pro-Russian hacking group with direct ties to Russian intelligence tried to destroy the operations of a heating plant in western Sweden in 2025. Not probe it. Not scan it. Destroy it.

This was Sweden's first public acknowledgment of the attack, and the language used was deliberate. Minister Carl-Oskar Bohlin didn't call it a "cyber incident" or a "disruption attempt." He specifically noted that attackers are shifting from traditional denial-of-service attacks against IT systems to targeting operational technology (OT) — the control systems that run physical infrastructure.

The details:

The attack failed — Sweden's security services identified the threat actor and the plant's existing defenses held. But it wasn't an isolated event. Bohlin connected it to a broader wave of OT-targeted attacks across Europe:

• Poland (December 2025): Coordinated cyberattacks hit combined heat-and-power plants serving nearly 500,000 customers, along with wind and solar farms. Polish officials said evidence pointed directly to Russian intelligence services.
• Norway (2025): Pro-Russian hackers remotely opened a valve in a dam, spilling millions of gallons of water before operators could regain control.
• Denmark (2024): Russian cyberattacks on a water utility left homes without running water.
• Ukraine (2024): A municipal energy company in Lviv was hit hard enough that hundreds of apartments lost heating for two days during freezing temperatures.

These incidents are part of more than 150 sabotage and malign activity events across Europe that Western officials have linked to Russia since 2022.

Why this matters for manufacturing:

Here's the thing that should keep every plant engineer up at night: the Sweden attack wasn't aimed at email servers or employee credentials. It targeted the systems that control physical functions — the SCADA, the PLCs, the control loops that keep turbines spinning and valves in the right position.

As Pontus Johnson, a professor at KTH Royal Institute of Technology, explained: DDoS attacks are relatively simple — you just flood a target with traffic. Attacking OT systems requires a much higher level of sophistication. They have to hunt for vulnerabilities to get inside the control systems so they can affect them.

And here's the uncomfortable truth: most manufacturing OT networks aren't meaningfully different from a heating plant's. Same SCADA architectures. Same remote access patterns. Same assumption that the air gap will save you (spoiler: it won't, because the air gap probably doesn't exist anymore).

What you should be doing right now:

• Audit your remote access paths into SCADA/ICS environments. If your VPN concentrator is the only thing between the internet and your historians, that's a problem.
• Enforce MFA on every engineering and vendor account. Not just IT accounts — every account that can touch a PLC or HMI.
• Segment your OT and IT networks. The Stryker attack referenced in the Dragos report started with compromised endpoint management software (an IT-level tool) and still managed to shut down manufacturing operations.
• Hunt for the TTPs tied to Sandworm and related GRU-linked groups. These are the clusters dominating European ICS intrusions. Your threat intel feeds should be tuned to them.
• Assume you're a target. Manufacturing has been the most breached industry globally for four consecutive years. The question isn't if — it's whether you'll see it coming.

The bottom line: Nation-state attackers aren't just going after power grids and pipelines anymore. They're targeting heating plants, dams, water utilities — and the same SCADA architectures that run your production lines. The shift from IT disruption to OT destruction is here, and the 150+ incidents across Europe aren't theoretical. They're a preview.

Read the full story →

The Protocol Connecting Your AI Agents Has a Built-In Security Hole — And Nobody's Fixing It

If you've been paying attention to the AI agent space (and if you're reading this newsletter, you probably have), you've heard of the Model Context Protocol (MCP). It's the open standard — originally created by Anthropic — that lets AI agents talk to external tools: databases, APIs, file systems, code editors, cloud services, you name it. Think of it as the USB port for AI. Plug an agent into your infrastructure and let it do things.

Cool concept. One problem: researchers just found that the USB port has no lock on it.

The details:

OX Security published a devastating disclosure last week identifying a fundamental architectural flaw in MCP's STDIO transport layer — the default method the protocol uses to launch and communicate with local tool servers. The vulnerability isn't a bug that slipped through code review. It's baked into the design of Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust.

Here's how it works in plain English: when an MCP client connects to a local server, it passes command-line arguments to spawn a process. The protocol doesn't sanitize or restrict what those commands can be. An attacker who can influence the MCP configuration — through a malicious file, a poisoned repository, or even a carefully crafted prompt — can inject arbitrary commands that execute with whatever privileges the MCP process has.

Translation: If your AI agent is running with access to your database, and someone slips a bad MCP server config into the mix, that attacker now has access to your database too. No exploit chain needed. No zero-day required. The front door is open by design.

The numbers are sobering:

• 10 CVEs issued so far across the ecosystem
• 30+ vulnerabilities reported across hundreds of open-source projects
• Tools affected include Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI
• One IDE — Windsurf — was exploitable with zero user interaction (CVE-2026-30615)
• The Flowise AI platform had a CVSS 10.0 (maximum severity) RCE vulnerability being actively exploited in the wild

And Anthropic's response? They confirmed the behavior is by design and said that input sanitization is the developer's responsibility. They're not changing the protocol.

Why this matters for manufacturing:

Here's where this gets real for our audience. MCP is rapidly becoming the connective tissue between AI tools and enterprise systems. Every vendor at Hannover Messe this week showing off an "AI-powered" anything is building on integration layers — and MCP is emerging as the standard for how those layers connect.

Now think about what's sitting on the other end of those connections in your plant:

• Historians full of years of production data
• MQTT brokers carrying real-time sensor telemetry
• Databases with recipes, batch records, and quality data
• APIs connecting to your MES, ERP, or CMMS

If your team is experimenting with AI agents — even just a pilot where someone's connecting an LLM to a time-series database to ask questions about Line 3's throughput — the trust model around that connection matters enormously. And right now, MCP's default trust model is "trust everything."

What you should be doing:

• Treat any MCP server configuration like executable code. Because that's what it is. Don't pull configs from untrusted sources, and review them line by line before deploying.
• Never run MCP processes with elevated privileges. If your AI agent only needs to read the historian, it shouldn't have write access to anything. Principle of least privilege applies here just like it does to service accounts.
• Isolate AI agent workloads. Run them in containers or VMs that are segmented from production OT networks. The same network segmentation principles you'd apply to a vendor laptop should apply to an AI agent.
• Watch the CVE list. The OX Security advisory at vulnerablemcp.info maintains a running database of MCP-related vulnerabilities. Bookmark it.
• Don't assume "official" means "secure." This flaw is in Anthropic's own SDK. The lesson isn't that MCP is bad — it's a useful protocol — it's that new standards shipping fast don't always ship safe.

The bottom line: MCP is becoming the plumbing for AI-integrated workflows, and that plumbing has a hole in it that the manufacturer of the pipe says is a feature, not a flaw. If you're connecting AI agents to anything in your industrial environment, you need to understand what MCP trusts by default — and why you shouldn't.

Read the OX Security advisory →

Rust 1.95.0 Just Dropped — And Here's Why Manufacturing Should Care About a Programming Language

Okay, I know what you're thinking. "A programming language update? In my manufacturing newsletter?" Stay with me — this one matters more than you think.

Rust 1.95.0 was released last week, and while the changelog reads like alphabet soup to most plant managers, the trajectory of this language has direct implications for anyone running industrial software, embedded systems, or edge computing on the factory floor.

First, what is Rust and why does it keep coming up?

Rust is a programming language designed from the ground up to prevent the kinds of memory bugs that cause roughly 70% of all serious software vulnerabilities. That's not a made-up number — it comes from Microsoft's own analysis of their CVE history, and Google has reported similar findings for Android and Chrome.

You know those headlines about hackers exploiting "buffer overflows" or "use-after-free" vulnerabilities to take over systems? Those are memory safety bugs. Languages like C and C++ — which power the vast majority of PLC firmware, embedded controllers, SCADA software, and industrial protocol stacks — make it very easy to write code that has these bugs. Rust makes it structurally very hard to write them in the first place. The compiler catches the mistakes before the code ever runs.

That's not a small thing when you're talking about software that controls physical processes.

What's new in 1.95.0:

Two features stand out for our audience:

cfg_select! macro — This new standard library macro lets developers write platform-specific code branches directly, without pulling in external dependencies. Think of it like a compile-time switch statement: "If this code is running on Linux, do this. If it's running on a 32-bit embedded target, do that instead." For industrial environments where the same software might need to run on a full server, an edge gateway, and a resource-constrained embedded device, this is genuinely useful. Fewer external dependencies also means a smaller attack surface — which, after that MCP article, should be music to your ears.

if let guards in match expressions — This one's more technical, but the short version: Rust just got better at letting developers handle complex conditional logic safely inside pattern matching. In practice, this means cleaner, more readable code when you're handling things like "if this sensor value exists AND it parses successfully, do X." Cleaner code means fewer bugs. Fewer bugs in industrial software means fewer 2 AM phone calls.

The bigger picture for manufacturing:

Rust isn't going to replace the C code running on your Allen-Bradley PLC tomorrow. But the trend line matters:

• Linux (which underpins most modern edge and gateway devices) now has Rust in the kernel itself. Drivers and kernel modules can be written in a memory-safe language for the first time.
• Embedded Rust is maturing rapidly. The embedded-hal ecosystem lets developers write firmware for microcontrollers — the same class of chips found in sensors, actuators, and IoT gateways — in a language that prevents the buffer overflows that plague C-based firmware.
• CISA and the White House have both published guidance calling on software manufacturers to adopt memory-safe languages. That's not a suggestion — it's a signal about where procurement requirements are heading.
• This release specifically stabilized inline assembly for PowerPC and PowerPC64 — architectures still widely used in industrial and aerospace computing.

Remember the Sweden article earlier? One of the reasons OT systems are vulnerable is that the software running on them was written decades ago in languages that make memory bugs trivially easy. Every new piece of industrial software written in Rust is one fewer attack surface for the next nation-state campaign.

Real-world scenario: Your team is building a custom edge gateway that collects data from Modbus devices, translates it to MQTT, and publishes to your UNS. You could write it in C (fast, but one buffer overflow away from a security incident) or Python (safe-ish, but too slow and resource-hungry for a constrained device). Rust gives you C-level performance with built-in memory safety. And with cfg_select!, you can now maintain one codebase that compiles differently for your x86 development machine and your ARM-based production gateway — without bolting on extra crate dependencies.

The bottom line: You don't need to learn Rust tomorrow. But when you're evaluating vendors, choosing edge platforms, or specifying software for new projects, ask the question: "Is this written in a memory-safe language?" Increasingly, the right answer matters — not just for security, but for long-term supportability as the regulatory landscape catches up.

Read the full release notes →

A Word from This Week's Sponsor

Manufacturers don’t need more disconnected tools. They need a better way to unify data, applications, and operations.

Fuuz is an AI-driven Industrial Intelligence Platform that helps manufacturers connect siloed systems, contextualize data, and turn that data into action. With a cloud-native architecture, edge capabilities, and a low-code/no-code environment, Fuuz makes it easier to build and scale industrial applications for MES, WMS, CMMS, and more.

From data modeling and API generation to real-time flows and application design, Fuuz gives manufacturers the tools to reduce complexity, improve visibility, and create more connected, resilient operations.

Design your solution today: fuuz.com/contact-us
Learn more: fuuz.com

Your Codebase Is Organized Wrong — And It's Costing You More Than You Think

This week's best read didn't come from a manufacturing publication or a cybersecurity firm. It came from Dominik Dorfmeister — better known as TkDodo — a frontend engineer at Sentry and maintainer of TanStack Query. His latest post, "The Vertical Codebase," makes an argument that applies far beyond web development. If your team writes any software — HMI applications, internal dashboards, data pipelines, edge services, custom MES integrations — this one's for you.

The problem:

Most codebases are organized horizontally — by what the code is technically. You've probably seen (or created) folder structures like this:

src/
  components/
  hooks/
  types/
  utils/
  constants/

Everything that's a "component" goes in the components folder. Everything that's a "utility function" goes in utils. Types go in types. Sounds logical, right?

It isn't. Here's why: code that changes together doesn't live together.

TkDodo uses the Sentry codebase as a cautionary tale. After 10+ years of product development with a horizontal structure, their top-level components directory had over 200 files — from analyticsArea to workflowEngine. What do those files have in common? They're components. That's it. Functions in utils/analytics are logically coupled to components/analyticsArea. The code for profiling is split across components/profiling, types/profiling, utils/profiling, and views/profiling. Finding anything requires a treasure map.

The fix — go vertical:

Instead of grouping by technical type, group by what the code does. Everything related to widgets goes in src/widgets/. Everything related to dashboards goes in src/dashboards/. Components, hooks, types, utils, constants — all together, organized by domain.

src/
  widgets/
    WidgetCard.tsx
    useWidgetData.ts
    widgetTypes.ts
    widgetUtils.ts
  dashboards/
    DashboardView.tsx
    useDashboardLayout.ts
    dashboardHelpers.ts

Now when you need to change something about widgets, you go to one place. When a new team member asks "where's the dashboard code?" the answer is obvious. When your AI coding assistant needs to understand the context around a change, it doesn't have to spider across six different folders to piece together what belongs together.

Why this matters for manufacturing software:

If you're thinking "this is a web developer thing, it doesn't apply to us" — think again. Every custom application your team builds follows some organizational pattern, and most of the ones I've seen in industrial settings are horizontal messes.

Real-world scenario: Your plant has a homegrown system for tracking OEE. Over three years, different developers have added features. The database queries live in one folder, the calculation logic in another, the API endpoints in a third, and the visualization components in a fourth. A new engineer joins the team and needs to add a downtime category. They have to touch files in four different directories, figure out which utility function in a folder of 50 utility functions is the right one, and hope they don't break the shift-report feature that shares some of the same code for reasons nobody remembers.

Now imagine that same system organized vertically: src/downtime/, src/availability/, src/quality/, src/shift-reports/. Each domain contains everything it needs. The new engineer opens src/downtime/ and finds the types, the queries, the calculations, and the UI — all in one place. They make their change, and because the boundaries are clear, they can be confident they haven't accidentally broken shift reports.

Three takeaways you can apply today:

1. Group by domain, not by type. Next time you create a new module or feature, resist the urge to scatter it across models/, services/, controllers/, and views/. Put it all in one folder named after what it does. Your future self (and your future teammates) will thank you.

2. Shared code gets its own vertical. TkDodo's answer to "but what about code used by multiple features?" is straightforward: make it its own domain. A PageFilters component used across multiple views isn't a generic "utility" — it's its own thing. Give it its own folder, its own clear public interface, and its own ownership.

3. Set boundaries with tooling. The real power of vertical organization comes when you enforce it. Tools like eslint-plugin-boundaries can prevent one domain from reaching into the private internals of another. Monorepo setups with package-level exports make dependencies explicit. This sounds fancy, but even a simple rule like "don't import from another feature's internal files" goes a long way.

The AI angle: TkDodo makes a point worth repeating — AI coding agents need the same things humans need to work well: clear boundaries, good structure, and fast feedback loops. Agents are great at greenfield projects but struggle with organically-grown codebases precisely because the structure doesn't tell them where things belong. Organizing vertically doesn't just help your team. It helps every tool your team uses.

The bottom line: Horizontal folder structures are the "flat network" of codebase architecture — easy to set up, impossible to maintain at scale, and a nightmare when something goes wrong. Going vertical takes more thought upfront, but it pays dividends every single time someone needs to find, change, or understand your code.

Read TkDodo's full post →

Learning Lens

Where to Start in Digital Transformation for Manufacturers

One of the biggest takeaways from ProveIt! End users still don’t know where to start.

Not because they’re not capable. Not because they don’t care. Because what they’re being sold and what they actually need… are nowhere close to each other right now.

You’ve probably felt this. Vendors pushing solutions. Consultants talking about AI like it’s the answer to everything. And none of it lines up with what’s actually happening on your plant floor. That’s where the gap is.

That’s why we’re doing this workshop. Watch Walker explain it below—why we’re doing it, and what you should expect. Where to Start in Digital Transformation

This is a 2-day live workshop with Walker Reynolds and Dylan DuFresne.

Day 1 is the process:
Where do you actually start? How do you identify the right problems? What does a real strategy and architecture look like?

Day 2 is the application:
We walk through it step-by-step in a simulated Value Factory. Connect → Collect → Store → Analyze → Visualize → Find Patterns → Report → Solve

Not theory. What this actually looks like when you do it.

May 12–13 | Live Online
9:00am - 1pm CDT

Early Bird — $100 off through April 10

Use code START-EARLYBIRD

Learn more ->

Byte-Sized Brilliance 

Here's a number that should make you uncomfortable: 46% of all ICS security advisories now target manufacturing systems specifically.

Not energy. Not water. Not transportation. Manufacturing. For the fourth consecutive year, it's the most breached industry on the planet, according to the Dragos 2026 OT Cybersecurity Report.

But here's what makes that stat sting a little more. A recent industry survey found that 80% of manufacturers reported a surge in security incidents the moment they connected enterprise IT systems to their plant networks. Eighty percent. That's not a risk — that's a near-certainty. Every time someone bridges the gap between the corporate network and the plant floor without proper segmentation, something goes wrong.

So while Hannover Messe spends this week showcasing the next wave of connected, AI-powered, cloud-integrated manufacturing — and those things genuinely matter — it's worth remembering that connectivity without architecture is just a faster way to get breached. The future of manufacturing isn't just smart. It has to be smart and segmented.

Something to chew on while you audit those firewall rules.

Let us know how we're doing! https://forms.gle/zSXrKTK9BNZ3BrpXA