View in web for best experience
We hope you had a great long weekend. If yesterday involved a grill, a parade, family in the backyard, or just some well-earned downtime before the short week, we hope it was a good one.
And amid the cookouts and the unofficial kickoff to summer, we hope you got a moment to remember what Memorial Day is really about. It's a day to honor the men and women who gave their lives in service β the ultimate sacrifice β so that the rest of us can fire up the grill, speak freely, and build things in freedom. We're grateful to them, and to the families who carry that loss. Thank you doesn't begin to cover it, but we mean it all the same.
That spirit of building things actually runs right through this newsletter. The work happening on plant floors matters β and so does protecting it. Which brings us to this week's theme: the widening gap between how fast AI is moving and how ready the plant floor really is for it. That gap cuts both ways. Attackers are now using AI to find their way toward your OT faster than ever, while defenders are using it to surface vulnerabilities by the tens of thousands. The real question is who's patching faster.
We've got a critical flaw sitting in 50,000+ collaborative robots, the first documented case of commercial AI being pointed at a water utility's control systems, an Anthropic project that turned up 10,000 vulnerabilities in a single month, and the unglamorous data architecture that decides whether your own AI ambitions go anywhere.
Now that everyone's back at it, here's what caught our attention:
Your Cobots Are Networked Linux Computers β and One Just Got a 9.8
Here's a fact worth sitting with on a Tuesday morning: that collaborative robot bolted to your assembly line is, underneath the friendly safety-rated exterior, a networked Linux computer with motors attached. And as of mid-May, a critical flaw in the software that runs it means an attacker on your network could be the one giving it commands.
The details:
On May 14, CISA and Universal Robots issued advisories for CVE-2026-8153, a critical vulnerability in PolyScope 5 β the operating system and interface that powers UR's cobots. The specifics:
- It's an OS command injection flaw (the textbook CWE-78 class) in the Dashboard Server, a service that listens on TCP port 29999 for remote management commands.
- The server takes user-supplied input and passes it to the underlying operating system without properly sanitizing it. Translation: send it a specially crafted command, and the robot's OS will happily run it for you.
- It carries a CVSS score of 9.8 β about as close to "drop everything" as the scale goes β because it's exploitable over the network, requires no authentication, and needs no user interaction.
- The flaw was found and reported by Vera Mens, a researcher at Claroty's Team82, and is patched in PolyScope 5.25.1.
The good news: there's no evidence of active exploitation in the wild yet, and UR cobots aren't designed to face the open internet. The bad news: with 50,000+ UR cobots deployed worldwide, "not designed to" and "isn't, on your network" are two very different things.
Why this matters for manufacturing:
The instinct is to file cobots under "equipment" rather than "endpoints." That's the trap. A cobot's management interface lives inside the plant network, is reachable by engineering workstations and HMIs, and tends to be far less monitored than a Windows box. It's trusted because it's internal β which is exactly what makes it a soft target.
And compromising the controller isn't just about one robot. Per Claroty, UR cobots have a control box with an Ethernet port that customers often use to speak legacy field protocols like MODBUS and EtherNet/IP to other OT equipment. So an attacker who lands on the cobot can potentially alter its safety configuration, manipulate its physical movements, steal production data, or use it as a pivot point deeper into your operational network.
Real-world scenario:
Picture a contract manufacturer running a dozen UR arms across two shifts. An attacker gets an initial foothold through a phished engineering laptop β nothing exotic. From there, they scan the OT subnet, find port 29999 wide open on every cobot, and inject commands. They don't need to crash anything dramatically. Subtly tweaking a robot's motion parameters mid-run is enough to scrap a production batch, trigger a safety stop, or quietly degrade quality until someone notices the reject rate climbing. Meanwhile, that compromised controller is now a beachhead onto the rest of the line.
What to do about it:
- Patch to PolyScope 5.25.1 or newer β now. This is the whole ballgame. If you run UR cobots, this is the most important item on your short-week to-do list.
- Restrict the Dashboard Server. On the General tab in PolyScope, limit access to specific trusted hosts or subnets rather than leaving port 29999 open to the whole network.
- Segment your OT network. Cobots should not be reachable from general IT or, obviously, the internet. If a phished laptop can route straight to port 29999, that's a segmentation problem worth fixing regardless of this CVE.
- Inventory your cobot fleet. You can't patch what you don't know you have. Confirm which units are on which PolyScope versions β including any you forgot were networked.
- Monitor the management interfaces. Treat cobot controllers like the endpoints they are. Unexpected traffic to port 29999 is a signal worth alerting on.
The bottom line: A cobot is a computer that can move heavy things, and it deserves the same patch discipline as any server in your environment. Treating it like a dumb appliance is how a 9.8 becomes a very bad Tuesday.
An AI Just Went Looking for a Water Utility's Controls β On Its Own
For years, the industrial security community has warned that AI would eventually help attackers target critical infrastructure. That "eventually" now has a date and a place: January 2026, Monterrey, Mexico.
The details:
Industrial cybersecurity firm Dragos published a report on an intrusion at Servicios de Agua y Drenaje de Monterrey (SADM), the water and drainage utility serving Mexico's third-largest metro area. The water hit was one piece of a broader campaign that compromised roughly nine Mexican government organizations between December 2025 and February 2026. Gambit Security uncovered the campaign and brought in Dragos specifically to assess the threat to the utility's control systems.
What made this one different wasn't the tooling β it was the operator. Dragos analyzed 350+ recovered artifacts, the vast majority of them AI-generated scripts, and found the attacker had run the operation using two commercial AI models in a deliberate division of labor:
- Anthropic's Claude was the "primary technical executor" β handling intrusion planning, building and refining offensive tooling, network enumeration, and iterating in real time based on what was and wasn't working.
- OpenAI's GPT handled the analytical grunt work β processing stolen data and generating structured Spanish-language output.
Here's the part that should get your attention. During internal reconnaissance, Claude β without any prompting about industrial systems β came across a server hosting a vNode industrial gateway and correctly recognized it as a gateway to OT-adjacent infrastructure. It then studied the vendor's documentation, pulled previously harvested credentials, generated environment-specific password lists, and launched two rounds of automated password-spraying against the vNode web interface.
Here's the good news, and it matters: both attempts failed. Dragos found no evidence the attacker ever reached the actual control systems or got any visibility into SADM's physical water operations. The OT held.
Why this matters for manufacturing:
Read past the water-utility headline, because the lesson is general. Dragos's central point wasn't that the techniques were advanced β most of them are well-documented online. It was how fast the AI operationalized them. A general-purpose model, with no special ICS training, identified OT-adjacent infrastructure as strategically valuable and chained together a credentialed attack against it in the normal flow of an intrusion.
Translation for the plant floor: the expertise barrier just dropped. The historical comfort blanket in OT security has been obscurity β the assumption that attackers don't understand industrial protocols, gateways, or historians well enough to do real damage once they're inside. An AI that can read vendor documentation and reason about your architecture in seconds erodes that assumption. The attacker no longer needs to be an ICS expert; they need a model that can become one on demand.
Real-world scenario:
Swap "water utility" for "your facility." An attacker phishes their way onto an enterprise laptop β the same unremarkable foothold from our last story. Historically, an IT-focused intruder might rummage for data and move on, not knowing a SCADA gateway from a print server. Now the AI doing the rummaging recognizes your industrial gateway, reads up on it, and starts probing for a path into OT β all before anyone's reviewed the first alert. The intrusion that used to stall at the IT/OT boundary now has a guide that knows exactly what it's looking at.
What to do about it:
- Assume the IT/OT boundary will be probed intelligently. Design segmentation as if the attacker already understands your architecture β because increasingly, their tools do. Flat networks where an IT foothold can reach OT gateways are the core risk.
- Kill default and reused credentials on gateways and OT-adjacent systems. The Monterrey attack failed at the password-spray stage. Strong, unique credentials and MFA on management interfaces are what turned "attempt" into "failure."
- Monitor for the reconnaissance pattern, not just the breach. Automated password-spraying and enumeration against OT-adjacent interfaces leave a signature. Catching the probing phase is your early warning.
- Inventory your OT-adjacent gateways. Know every vNode-style device bridging IT and OT, what it's exposed to, and who can reach it. These edge devices are exactly what an AI reconnaissance pass will surface first.
- Brief your IT security team on OT. The attack crossed the IT/OT line; your defense has to as well. The people watching the enterprise network need to understand what an industrial gateway is and why traffic toward one is worth a second look.
The bottom line: The attacker's controls didn't get popped this time β but the warning is unambiguous. AI just made "the intruder doesn't understand your plant" a dangerous thing to count on.
Read the full Dragos report β
10,000 Vulnerabilities in One Month β and Why Your Patch Window Just Shrank
In our last two stories, AI was the attacker's tool. Here's the same coin, other side: AI is now finding security holes faster than anyone can fix them β and that has direct consequences for how fast you patch.
The details:
On May 22, Anthropic published its first progress report on Project Glasswing, a defensive initiative launched in April that gives about 50 trusted partners early access to Claude Mythos β an unreleased frontier model purpose-built for finding software vulnerabilities. One month in, the numbers are eye-watering:
- Partners have collectively surfaced more than 10,000 high- or critical-severity vulnerabilities in widely used software.
- Most partners reported finding hundreds of serious flaws in their own code, with bug-discovery rates jumping by more than 10x versus prior tooling.
- Cloudflare alone found about 2,000 bugs in its internal systems, 400 of them high or critical. Mozilla fixed 271 vulnerabilities in Firefox β roughly ten times what an earlier Claude model found in the previous version.
- In one case, Mythos found a flaw in WolfSSL β an open-source cryptography library embedded in billions of devices β and built a working exploit that could forge certificates and impersonate legitimate services. (It's been patched: CVE-2026-5194.)
Anthropic is keeping Mythos restricted for now, citing the obvious: a tool this good at finding exploitable bugs is equally good at building exploits β which, as the Monterrey attack showed, is no longer hypothetical. (Worth noting with appropriate skepticism: there's chatter and leaked code suggesting Anthropic is preparing a "Mythos 1" release for its developer and security products. Unconfirmed, but the direction of travel is clear β capabilities like this are heading toward broader availability.)
Why this matters for manufacturing:
You don't run WolfSSL or Firefox on the plant floor β so why care? Because the bottleneck just flipped, and it flipped against you.
For decades, the limiting factor in security was finding vulnerabilities. That was the slow, expert-intensive part. Patching, by comparison, could happen on a comfortable schedule β quarterly, annually, "next maintenance window." Mythos inverts that. Anthropic's own takeaway is that finding bugs is now the easy part; the hard part is verifying, disclosing, and fixing them. Even their partners β well-resourced security teams β average about two weeks to patch a single high- or critical-severity bug.
Here's the uncomfortable logic for OT. If defenders can now find vulnerabilities at 10x speed, so can attackers β and the gap between "flaw discovered" and "flaw exploited" is collapsing. Microsoft has already said its patch releases will keep "trending larger." Oracle has shifted to a monthly patch cadence. Anthropic is flatly telling defenders to shorten their patch testing and deployment timelines.
Now overlay that on a typical OT reality: systems patched once a year if you're lucky, equipment that can't take downtime, vendors slow to issue fixes, and a "if it isn't broken, don't touch it" culture. That cobot CVE from our first story? The window between disclosure and weaponization for the next one is shrinking fast.
Real-world scenario:
A critical flaw drops for a PLC or industrial gateway you run β exactly like CVE-2026-8153. In the old world, you had breathing room; exploit development took skilled adversaries weeks or months, so your annual patch cycle was a survivable bet. In the new world, AI-accelerated tooling compresses that into days. Your maintenance supervisor wants to wait for the scheduled fall shutdown to apply the patch. The threat actor's tooling doesn't care about your shutdown calendar. The math that made "patch later" safe no longer holds.
What to do about it:
- Build a real OT patch-prioritization process. You can't patch everything overnight, and OT can't always patch fast β so triage. Know which assets are internet-adjacent, which are critical to production, and which have the worst exposure. Patch those first, deliberately.
- Shrink your patch-testing cycle where you safely can. If validating and deploying a critical patch takes you months, that's now a risk in itself. Look for the bottlenecks β test environments, change-approval queues β and tighten them.
- Lean on compensating controls for what you can't patch fast. Network segmentation, restricting management-interface access, and monitoring buy you time on systems that genuinely can't take immediate downtime. (Same playbook as Articles 1 and 2 β it keeps showing up because it works.)
- Track vendor advisories actively, not passively. Subscribe to CISA ICS advisories and your specific vendors' security feeds. The faster you learn a flaw exists, the more of the shrinking window you keep.
- Make the case to leadership now. "We patch OT annually" is getting harder to defend. Use these numbers β 10,000 bugs in a month, two-week patch averages even for the pros β to justify investment in patch infrastructure before an incident makes the argument for you.
The bottom line: AI didn't just give attackers a smarter scout β it put vulnerability discovery on a rocket. The plants that treat patching as a quarterly chore instead of a continuous discipline are the ones the math is about to catch up with.
Read Anthropic's Project Glasswing update β
https://www.40solutions.com/dados
Before You Bolt AI Onto Your Plant, Fix the Plumbing
The first three stories were about threats moving faster than defenses. This one's the antidote: the unglamorous data architecture that determines whether your own AI ambitions actually go anywhere β or just generate expensive disappointment.
The details:
At IIoT World's AI Manufacturing Day on May 12, a panel tackled a question every manufacturer is quietly wrestling with: why do so many factory AI projects stall out? The panelists β Aron Semle (CTO of HighByte), Olivia Morales (CESMII), and Matthew Parris (GE Appliances) β landed on a blunt answer: AI can't transform manufacturing until the underlying data is accessible, contextualized, and interoperable. Most plants don't have that. They have data β oceans of it β but it's trapped, disconnected, and meaningless without context.
Their framework rests on two pieces:
- Unified Namespace (UNS) β think of it as a single, real-time "data bus" for the entire operation. Instead of every system (PLCs, SCADA, historians, MES, ERP) talking point-to-point in its own dialect, everything publishes to and subscribes from one central, event-driven hub. It becomes the single source of truth, and it's current β reflecting the real state of the plant right now, not a batch report from last night. (MQTT with Sparkplug is a common way to build the transport layer.)
- i3X β an emerging open standard that adds the semantic layer on top of UNS. If UNS is the data bus, i3X is the dictionary that explains what the data means. It makes the data machine-readable so software β including AI agents β can interpret it without a human hand-coding the meaning of every tag.
The panel's clean summary: UNS provides the real-time data; i3X makes that data understandable to machines.
Why this matters for manufacturing:
Here's the part that connects to everything else in this issue. The industry is barreling toward agentic AI β not chatbots, but software agents that perceive, reason, and act on the plant floor. The panel's projection is that this could mean thousands, even tens of thousands, of AI agents operating across a factory.
Now ask the obvious question: what do those agents run on? If you point an AI agent at raw, disconnected sensor data β a tag named TT_4471_PV with no context about what it measures, what's normal, or how it relates to anything else β the agent is guessing. Garbage in, confident garbage out. A UNS gives the agent contextualized, real-time data to reason about; i3X lets it understand that data without you building a custom integration for every single use case.
Translation: the manufacturers who get AI value aren't the ones who bought the flashiest model. They're the ones who did the boring data-architecture work first. The model is the easy part now β the data foundation is the moat.
And there's a security dimension you can't ignore, given the first three stories. Thousands of agents acting on your data is a thrilling capability and a sprawling new attack surface. The same architecture decisions that make your data AI-ready β central control points, clear data contracts, defined access β are the ones that make it governable and securable. Building the data layer thoughtfully now is also building the control layer you'll need when those agents arrive.
Real-world scenario:
Imagine your maintenance supervisor asking, in plain English, "Which assets on Line 3 are trending toward failure this week, and what's the production impact if we take them down Saturday?" For an AI agent to answer that, it needs live vibration and temperature data (from the historian), the production schedule (from MES), the maintenance history (from the CMMS), and the business context (from ERP) β and it needs to know how all those pieces relate.
Without a UNS and a semantic layer, that's a six-week custom integration project for one question. With them, it's a query the agent can answer because the data is already unified and already labeled with meaning. The difference between "AI pilot that died in committee" and "AI that actually runs your floor" is mostly this plumbing.
What to do about it:
- Audit your data reality honestly. Before any AI initiative, map where your data lives and how systems talk to each other today. If the answer is "dozens of point-to-point integrations and a lot of tribal knowledge," that's your real starting line β not the AI model.
- Start your UNS small and prove it. You don't boil the ocean. Pick one line or one cell, stand up a Unified Namespace for it, and demonstrate that systems can publish and subscribe to one source of truth. Expand from the win.
- Watch i3X β but don't wait on it to start. i3X is an emerging standard, so treat it as a direction, not a finished product. Building a solid UNS now puts you in position to adopt the semantic layer as it matures, without betting the farm on a spec that's still settling.
- Demand contextualized data, not just connectivity. Connecting systems isn't the goal; meaning is. As you build, insist that data carry context β units, asset relationships, what "normal" looks like β so it's usable by humans and machines alike.
- Bake in governance and security from day one. Design your data layer with access control, clear data contracts, and monitoring built in β not bolted on later. The architecture that makes data AI-ready is the same one that keeps a future swarm of agents accountable and secure.
The bottom line: The plants that win with AI won't be the ones with the best model β they'll be the ones whose data was ready for it. UNS and i3X aren't the exciting part of Industry 4.0, but they're the part that makes the exciting parts possible.
Byte-Sized Brilliance
We opened this issue on Memorial Day, so let's close it there too β with a number that still defies belief.
During World War II, roughly half of every B-24 Liberator bomber the United States built came out of a single factory: Ford's Willow Run plant near Ypsilanti, Michigan. More than 18,000 Liberators were produced across three companies and five plants β and Willow Run alone accounted for about 8,600 of them. By 1945, even with two other plants running, Willow Run was turning out 70% of all monthly B-24 production.
Sit with the pace for a second. At its 1944 peak, Willow Run rolled a finished bomber off the line roughly every hour β 453 aircraft in 468 hours one April. And this wasn't a simple machine: the B-24 had 450,000 parts and 360,000 rivets in 550 different sizes. Ford did it by dragging automotive mass-production methods onto an aircraft line over a mile long, inside what was then the largest factory under one roof on Earth. It became the literal embodiment of the "Arsenal of Democracy."
Here's the part that lands today: the throughline of everything we cover β connectivity, data, automation, throughput β runs straight back to that factory floor. The tools have changed (Willow Run had turntables and rivet guns; you've got PLCs and a unified namespace), but the mission hasn't. It's still about building things at a scale and quality that matter.
There's one more detail worth a quiet moment. Edsel Ford, the company president who championed Willow Run and pushed it to succeed, died on May 26, 1943 β the same date this issue lands β and never saw the plant hit its stride. A reminder that the people who build things, and the ones who defend them, don't always get to see what their work makes possible. That's worth remembering, today of all weeks.
Let us know how we're doing! https://forms.gle/zSXrKTK9BNZ3BrpXA
Responses