Pour yourself a dram of something dark and suspicious, because this update is about as thrilling as a vendor webinar titled “Patch Cadence for ICS.” The U.S. Cybersecurity and Infrastructure Security Agency has bolstered its Known Exploited Vulnerabilities (KEV) catalog with CVE-2021-26829, an XSS flaw in OpenPLC ScadaBR that is reportedly under active exploitation. If you’re still running ScadaBR in production, congratulations—you’ve achieved peak operational risk while somehow avoiding a budget review.
What happened
The bug is an XSS in OpenPLC ScadaBR that affects both Windows and Linux builds, with a CVSS around the mid-5s. The big takeaway is not the exact technical nitty-gritty, but the fact that attackers are already taking advantage of it in the wild. In other words, this isn’t a “maybe later this year” headline; it’s a “it’s happening now, and your OT network is probably listening on the same flat network as your ERP system because siloing is so 2010.” Grab a glass of whiskey and nod along as the inventory of exploited devices grows with the cheerful inevitability of a vendor slide deck at 9:00 a.m. on Monday.
Why this should matter
Active exploitation means you are dealing with a real, currently usable threat—not a rumor you dismiss with a shrug and a coffee. The impact in SCADA and OT environments can be more than data loss; think pivoting into control systems, tampering with process logic, or simply turning a plant floor into a gravity-driven security drill. And yet the reality remains painful and familiar: patching these environments is a logistics night mare. Downtime, risk to safety, and the endless cycle of downtime approvals are the grownup version of “we’ll patch it later.” Meanwhile vendors keep selling uptime promises like they are security features, and CISOs pretend that air-gapping and vendor risk ratings are actual protections.
If you want to pretend you are a responsible adult, here is what you should be doing while you nurse a glass of aged rum: verify whether OpenPLC ScadaBR is in use, check for any updates or patches from the vendor, segment IT from OT where possible, and require a formal change control before any patch goes live. Enforce strict access controls on the affected systems, monitor for unusual input, and implement a layered defense that does not rely on the patch alone. If patching is not feasible immediately, isolate the device, reduce exposure, and increase logging so you at least know when someone slaps a payload onto your dashboard.
Yes, it is a boring reality check in a world of flashy dashboards and glossy vendor claims, but it is the one that keeps the lights on and the PLCs from deciding to reboot themselves into a new operating philosophy. Now, go pour that scotch, take a breath, and plan the patch cycle your board actually approves instead of the one your security team dreams about at 2 a.m.
Read more about the KEV update here: Read the original article
