On the CODESYS vulnerabilities:
Look, this is serious. CODESYS isn't some niche soft PLC — according to vendor data I found, it's "the world's most widely used SoftPLC platform" with over 500 manufacturers producing over 1,000 device types that incorporate CODESYS runtimes. The GSMaragd research I reviewed found over 2,500 internet-exposed CODESYS protocol systems in their 2025 scans, and that's just the visible surface — most CODESYS deployments are behind corporate firewalls.
The Nozomi disclosure describes a chain of three vulnerabilities — CVE-2025-41658, CVE-2025-41659, CVE-2025-41660 — that lets an authenticated attacker with Service-level credentials replace legitimate control applications with backdoored versions and achieve full device and host OS control.
But here's the thing about "authenticated with Service-level credentials." In my experience, this authentication barrier is operationally porous. These are soft PLCs running on industrial PCs or embedded Linux boxes. The "Service-level" accounts — they're often shared credentials that field engineers use for commissioning, maintenance, and troubleshooting. I've personally seen these written on whiteboards in control rooms, stored in unencrypted text files on engineering laptops, and shared across entire sites.
Purdue model mapping: this lives squarely at Level 1 and Level 2. The CODESYS runtime is executing control logic that directly manipulates field devices. If an attacker replaces that application logic, they have Level 1 access — they can manipulate actuators, pumps, valves, motor drives. Forget data theft. If this succeeds on a safety-critical system, we're talking about physical consequences — equipment damage, process upsets, potential loss of life.
What should OT operators do TODAY:
Immediate inventory: Identify every CODESYS Control Runtime deployment in your environment. Check versions. The affected versions and patch guidance are available in CODESYS Control Runtime v4.21.0.0 and Runtime Toolkit 3.5.22.0 — operators should verify their specific runtime version against the vendor advisories.
Credential audit: Review every Service-level account. Assume they've been shared too widely. Rotate them immediately. Enable account logging if it exists.
Network segmentation verification: These CODESYS runtimes should NOT be reachable from your corporate network. If an engineer's laptop can ping the PLC directly from their desk, you have an architecture problem.
Application integrity monitoring: Since the attack vector is application replacement, you need visibility into when PLC project files change. Most sites have no logging for this.
Maintenance window planning: Patches are available, but you cannot just push this during shift change. Test in your non-production environment first — I've seen CODESYS patches break fieldbus communication timing. Schedule your outage windows. I cannot give you a blanket "anything before X is vulnerable" without knowing your specific device manufacturer's implementation.
On the Itron breach:
This is suppler-to-critical-infrastructure risk, not direct OT grid disruption — at this stage. The SEC 8-K filing disclosed unauthorized access to Itron's internal IT systems on April 13, 2026. Itron confirmed that "no unauthorized activity was detected in the customer-hosted portion of its systems."
But let's be clear about Itron's position in the ecosystem. They manage 112 million endpoints — smart meters for electricity, water, and gas — across 100+ countries and 7,700 utility customers. Their OpenWay platform and meter data management systems are deeply embedded in utility operations.
The downstream risk to utilities comes in several layers:
Software supply chain: If Itron's development or deployment systems were compromised, firmware or software updates pushed to utility customers could be trojanized. Most utilities auto-accept meter firmware from their AMI vendor.
Encryption keys and credentials: Itron manages the cryptographic material for meter-to-headend authentication. If those credential databases were exposed, an attacker could impersonate legitimate meters or inject commands into the AMI network.
Network topology intelligence: Itron has visibility into how their utility customers segment their AMI networks. If that documentation was exfiltrated, it becomes a reconnaissance goldmine.
Could compromised meter management systems affect grid operations? Indirectly, yes. Shutoff-capable meters are normal for AMI. But compromised meters can also be weaponized for coordinated load manipulation — think about 50,000 air conditioners being switched on simultaneously during a peak demand period. That's a destabilizing event that affects generation dispatch, frequency regulation, and potentially triggers protective relay actions. Dragos research shows groups like KAMACITE actively reconnoitering meter infrastructure.
Itron has stated that remediation is complete and no customer systems were affected. But I want to flag something: the investigation is ongoing, and attribution is unknown. No ransomware group has claimed this, which suggests either a stealthy espionage operation, an insider threat, or something that Itron hasn't fully characterized yet.
My guidance for utilities running Itron meters: request a direct technical briefing from your Itron account team on exactly which internal systems were affected and whether any signed artifacts or key material was touched. Don't rely on the SEC filing. Review your AMI network segmentation — your meters should not have routing paths back to your SCADA control center. And audit your firmware update procedures — are you verifying Itron-signed packages cryptographically, or just trusting the vendor push?