A Core Cisco Switch Just Got a Root-Access Bug With No Patch Yet, and Researchers Spent $535 and Eight Hours Getting an AI to Port a PLC Exploit — Then Watched It Brick the Device

Start with the vulnerability sitting in the core of a lot of enterprise and carrier networks right now, wide open with no fixed-release table published yet: CVE-2026-20212, a maximum-severity flaw in Cisco Nexus 9000 Series switches built on Cisco's own Silicon One networking processors. The root cause is almost embarrassingly simple for a company at Cisco's scale — TCP ports 43210 and 43211 are reachable by default within the switch's Layer 3 virtual routing and forwarding instance, meaning any attacker who can reach a switch's address can connect directly to a service that was never meant to be exposed. Crafted input sent to that service executes as code with root privileges. An unsuccessful attempt can still crash the switch's S1HAL process and force a reload, so even a failed exploitation attempt is a real availability risk on its own. Cisco's Technical Assistance Center discovered the flaw while investigating an ordinary customer support case — not a targeted hunt for the bug, just routine troubleshooting that happened to surface a root-access hole in one of the company's flagship switch lines.

Ten Silicon One-based Nexus 9000 models are affected, and as of this writing, Cisco hasn't published a fixed-release table at all — customers are being directed to Cisco's Software Checker tool and, in the meantime, to two stopgaps: an infrastructure access control list blocking the two exposed ports, and something Cisco calls a "Live Protect shield," a temporary mitigation while a real patch is prepared. Cisco says it isn't aware of any public disclosure or malicious exploitation as of the September 2 advisory, which is genuinely good news, but "no fixed release yet" on a maximum-severity, unauthenticated, root-access bug in core switching infrastructure is exactly the kind of gap that shouldn't sit open longer than necessary. If Nexus 9000 switches are anywhere in your network, apply the iACL mitigation today rather than waiting for the permanent fix — this is a rare case where the vendor's own stopgap is the more urgent action, not the eventual patch.

The same disclosure batch bundled seven additional critical vulnerabilities into a single IOS XR hardening release, and this one deserves its own scrutiny for a different reason: it affects every IOS XR release regardless of device configuration, and Cisco has published no workaround for any of them. Two of the seven — CVE-2026-20274 and CVE-2026-20279 — carry the same 9.8 ceiling as the Nexus flaw; the remaining five range from 8.2 to 8.8. CVE-2026-20274 covers a cluster of memory-safety and resource-lifetime bugs — buffer issues, out-of-bounds writes, resources initialized with insecure defaults. CVE-2026-20279 is an access-control failure covering missing authentication for critical functions, missing authorization, and improper certificate validation, all bundled into one advisory. Cisco's own language attributes the discovery to "a comprehensive internal security review" — the kind of proactive audit that's genuinely good practice, even though finding seven critical bugs at once in carrier-grade software isn't a great look on the surface. Platforms on the XR7 (LNT) branch — including the Cisco 8000 Series, NCS 1010, NCS 540L, and NCS 5700 Series — get a dedicated software maintenance update covering all releases; other IOS XR customers need to upgrade to a release that includes the relevant SMUs, then apply them, since there's no lighter-weight mitigation available while that happens.

The second story of the day is a genuinely useful, honestly-reported look at where AI-assisted exploit development actually stands right now, not where headlines might suggest it stands. Forescout's Vedere Labs published a detailed writeup of an experiment: taking a working remote code execution exploit the team had previously built for a WAGO 750-852 programmable logic controller, and using Anthropic's Claude to port that exploit to a related but distinct model, the WAGO 750-831, running firmware V01.04.16. The underlying flaw, CVE-2021-31886, is a pre-authentication buffer overflow in the Nucleus FTP server's handling of the USER command — a specially crafted, oversized username overwrites memory and can redirect program execution, all without valid credentials, over TCP port 21. CERT@VDE has no update available for the affected WAGO controllers and recommends disabling or blocking FTP entirely and adding network segmentation as the practical mitigation, since there's no patch to apply.

The honest, detailed shape of what actually happened is the part worth reading past the headline for. Claude, working through Claude Code with access to a terminal, the reverse-engineering tool Ghidra, and a physical target PLC, initially struggled — normal FTP command processing on the 750-831 zeroed out 256 bytes of the attacker-controlled buffer immediately after the USER command completed, erasing the injected shellcode before it could execute, and early attempts using Claude Sonnet 4.6 failed to correctly trace the vulnerable function, producing invalid exploit attempts. The researchers switched to Claude Opus 4.6, which correctly diagnosed the buffer-clearing behavior and found a fix: replacing the original USER-then-QUIT command sequence with USER-then-CWD and omitting the CRLF terminator, preventing the normal completion path that was wiping the payload. Once that specific obstacle was solved, Claude generated two distinct working payloads within twelve minutes — one causing the PLC to send ICMP echo requests to an attacker-controlled system, another transmitting a UDP packet containing the text "PWNED." Getting to that point took an 8-hour, 32-minute session spread across multiple days and $535.74 in API usage, consuming roughly 1.3 million output tokens against the task.

The part of this report that matters most for anyone trying to gauge real risk, rather than react to a scary headline, is what happened next and how plainly Forescout reported it. In a follow-up session aimed at building a fuller command-and-control implant on top of the working RCE, Claude tested increasingly complex payloads during memory-layout probing — and one of them wrote to a region mapped to the PLC's flash memory, permanently bricking the physical device. Forescout's own assessment doesn't oversell the milestone: "One could argue that the same researcher could have achieved the initial RCE port without AI in less time and at lower cost while also keeping the PLC alive." Daniel dos Santos, VP of research at Vedere Labs, described the AI's actual contribution accurately to Cybersecurity Dive — it helped confirm the vulnerability existed on the second PLC model and helped construct an exploit for it, with sustained, hands-on researcher steering at every stage, not autonomous operation. The more realistic near-term risk this points to isn't an AI agent independently deciding to attack a controller on its own initiative — it's an already-motivated human attacker using AI as a genuine force multiplier on exactly the kind of tedious, specialized reverse-engineering work that used to require scarce expertise, compressing effort on tasks a skilled human could already do, rather than creating an entirely new category of threat actor.

Two stories, one honest throughline: neither one is a story about a system doing something it wasn't designed to do. Cisco's Nexus flaw exists because two ports were reachable that were never supposed to be. The IOS XR bugs exist because seven distinct weaknesses sat in software running exactly as configured, on every release, until an internal audit went looking. Forescout's PLC experiment shows real capability and real friction in the same report — an AI that can meaningfully compress specialized exploit-development work, and one that still needs hours of expert human steering and can just as easily brick the very device it's working on. None of it needed a genuinely novel category of vulnerability or attacker. It needed defenders and researchers both being honest about exactly how far current capability actually reaches, in either direction.