TL;DR
- what: NSA, CISA, FBI, the Department of Energy and the EPA jointly warned on August 19, 2026 that threat actors are using AI-generated Python exploitation scripts against internet-exposed Siemens S7 series PLCs.
- impact: The tooling gives read and write access to PLC memory, configuration data and ladder logic programs, enough for data theft, equipment damage, extended downtime or a safety incident.
- fix: Inventory every S7-200, S7-300, S7-400, S7-1200 and S7-1500, pull them off the public internet, apply current Siemens firmware, and enforce strong PLC authentication and write protection.
- who: Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, Commercial Facilities and the Defense Industrial Base.
On August 19, 2026, five US agencies put their names on the same document: NSA, CISA, the FBI, the Department of Energy and the Environmental Protection Agency. The subject is active targeting of Siemens S7 series programmable logic controllers in US critical infrastructure, and the notable detail is the tooling. Attackers are running AI-generated Python exploitation scripts that talk native S7comm to the controller and are packaged to look like legitimate OT monitoring software.
Read the capability description carefully, because it is the whole story: read and write access to PLC memory, configuration data, and ladder logic programs. That is not a denial of service or a nuisance crash. That is control of the process logic, with the ability to change what a controller does and to lie to the operator about it.
Which devices are in scope
The advisory names five product families: S7-200, S7-300, S7-400, S7-1200 and S7-1500. That range spans roughly two decades of Siemens automation hardware. The S7-200 and S7-300 lines are long past their design assumptions about network exposure and were built when the security model was a locked cabinet and an air gap. The S7-1200 and S7-1500 have real access protection features, but they ship in configurations where those features are optional and are frequently deployed with them off.
No CVE identifiers are called out in the advisory, and that is deliberate. Most of this activity is not exploitation of a named memory corruption bug. It is abuse of documented protocol functionality against devices that were never supposed to be reachable from the internet in the first place.
The intrusion chain
The reported sequence is short, which is part of why it works.
- Reconnaissance with commercial internet scanning services, specifically Censys and ZoomEye, to enumerate exposed Siemens PLCs.
- Target selection favoring devices running outdated firmware, devices with known critical or high severity vulnerabilities, and devices with weak or absent authentication.
- Interaction over the S7comm protocol on TCP port 102 using the snap7.dll and python-snap7 libraries.
- Read and write operations against PLC memory, configuration blocks and ladder logic.
- Persistence of access and continued observation of the process, packaged inside binaries presented as OT monitoring utilities.
There is no phishing stage in this chain, no macro, no initial access broker. The exposure is the initial access. If your controller answers on 102/TCP from an arbitrary source address, the attacker has already completed the hard part of most intrusions before writing a line of code.
⚠️ python-snap7 is not the vulnerability — snap7 is a legitimate, widely used open source library for S7 communication, and plenty of vendors and integrators depend on it. Blocking or removing it accomplishes nothing. The defensive control is network reachability and PLC access protection, not library allowlisting. Anyone can rebuild the same functionality in an afternoon.
What the AI part actually changes
Ignore the headline framing for a moment. Large language models do not grant new access to a PLC and do not defeat access protection. What they change is who can write competent OT tooling and how fast. Historically, S7comm exploitation required someone who understood ladder logic, data block layout, Siemens addressing conventions and the protocol quirks between the S7-300 and the S7-1500. That was a small population, mostly nation state teams and a handful of researchers.
An AI assistant that can produce working python-snap7 code compresses that learning curve from months to hours. The result is a wider pool of capable operators, faster iteration against a target, and tooling tailored to a specific site rather than reused off the shelf. For defenders, the practical consequence is that indicator based detection ages faster. Two campaigns against two utilities may share zero file hashes because the scripts were generated per target.
Reconnaissance now, disruption later
The agencies characterize the observed activity as focused on persistent reconnaissance, potentially preparing attackers for disruption. That framing matters for how you triage. The stated risk set includes data theft, equipment damage, extended downtime and safety incidents, but the current behavior is mapping and dwelling, not detonating.
This is consistent with the pattern set elsewhere. Hackers hit Minnesota water utilities in July 2026, and Iranian linked actors targeted Rockwell Automation PLCs in April 2026. Small water and wastewater systems keep surfacing in these reports for the same reason every time: minimal staff, remote access for a contract operator, and controllers reachable from the internet because that was the cheapest way to support them.
Do these five things
- Inventory every S7 controller including the ones behind an integrator's cellular gateway. Devices nobody remembers are the ones that answer on 102/TCP.
- Remove internet exposure. Query Censys and Shodan for your own public ranges and for your integrators' ranges. If a controller must be reached remotely, put it behind an authenticated VPN or a jump host with MFA, never a port forward.
- Apply current Siemens firmware and check the Siemens ProductCERT feed for advisories covering your specific families. The older S7-300 and S7-400 units may have no patch path, which makes segmentation the only control you have.
- Enable PLC access protection. Set write protection and password levels on S7-1200 and S7-1500, and disable unused services. Verify the keyswitch or protection level is not sitting in a permissive state after the last commissioning visit.
- Log and alert on S7comm write functions. Any write to a data block or program block from a source that is not the engineering workstation is worth a page, and stop or run mode changes should be alarmed in the historian, not just the SCADA HMI.
The detection gap most sites have — Most OT networks monitor process values, not protocol semantics. A controller behaving normally after a logic write looks fine on the HMI. Passive network monitoring that decodes S7comm function codes, or at minimum a firewall rule that logs every 102/TCP session with its source, closes the gap for a fraction of the cost of an OT SOC platform.
The limit of this advisory
No threat actor is named, no CVE is listed, no exposure count is published, and no file hashes are provided. Defenders are being handed a behavior pattern and told to go look. That is thin for anyone hoping to run a detection rule and move on, and it makes attribution and prioritization harder for teams juggling limited OT maintenance windows.
What the advisory does give you is a specific protocol, a specific port, five specific product families and seven sectors. That is enough to run an exposure audit this week. If the answer to "how many S7 controllers of ours answer from the public internet" is anything other than zero, and you can prove it, you have found the finding. The AI angle is the part that will get quoted. The port forward is the part that will get you breached.
Originally published on RedEye Threat Intelligence.
