The advisory five federal agencies published on August 19 does not contain a CVE. That is not an oversight. AA26-231A describes a change in what attackers can cheaply build, not a flaw you can install a fix for: threat actors using AI to generate Siemens S7 exploitation scripts out of a public Python library, then dressing the result up as OT monitoring software. There is nothing to score, patch and close. What moved is the price of attacking your plant floor, and most enterprise risk registers have no field for that.
Five Agencies Signed It. Nothing Shipped a Patch.
AA26-231A is a threat advisory, not a vulnerability disclosure, and that distinction determines whether it survives contact with your intake process. The NSA, CISA, FBI, Department of Energy and Environmental Protection Agency released it jointly on August 19, 2026, warning of active targeting of Siemens S7 controllers that are internet-exposed or insufficiently segmented from the internet.
The scope is every generation Siemens ships. The S7-200, S7-300, S7-400, S7-1200 and S7-1500 series are named, including the F-series safety controllers — the ones whose job is to stop the process before somebody gets hurt. The sectors called out are Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities, with the Defense Industrial Base named as additional exposure.
No CVE was assigned. The advisory points at existing critical and high-severity known vulnerabilities and at Siemens ProductCERT for model-specific guidance, but the finding itself is a capability shift rather than a new vulnerability. Worse for anyone hoping to patch their way out: many of these accesses need no exploitation at all, because the exposed device had default or minimally configured authentication and simply answered the question it was asked.
If your vulnerability management program cannot open a ticket without a CVE number, this advisory dies in an inbox. That is the same structural gap that showed up when the federal government tried to industrialise CVE coordination across 66,000 vulnerabilities: the pipeline is built to consume identifiers, and a capability assertion has none.
The Exploitation Library Is a Free Download
The tooling is not bespoke ICS malware. It is snap7, an open-source industrial automation library that any automation engineer already has a reason to install. The advisory names snap7.dll and python-snap7 specifically, paired with AI-assisted scripting to produce tools that mimic legitimate OT monitoring software.
python-snap7 supports S7-200 through S7-1500 and exposes exactly what you would expect a maintenance tool to expose: reads and writes to memory areas and data blocks, multi-variable reads, block upload and download, device discovery. The Windows path is downloading snap7.dll and dropping it in System32. That is the whole supply chain.
The skill that used to gate this work was knowing the S7comm wire format. That knowledge is now inside a library, and the glue code around it is inside a model. Anthropic's own threat data points the same direction: reviewing 832 accounts banned for malicious cyber activity between March 2025 and March 2026, it found the share of actors rated medium-risk or higher rose from 33% in the first half of that window to 56% in the second, and concluded that post-compromise techniques once restricted to actors with the technical knowledge to execute them are no longer restricted that way.
Steel-man the other side, because it is not stupid: writing a snap7 read loop was never hard for a competent automation engineer, and a model does not hand anybody your process knowledge. Knowing that DB47 word 12 is the setpoint on the chlorine dosing pump is still the expensive part. That is precisely why the campaign reads as reconnaissance. The advisory describes read operations against data blocks alongside write access to memory, configuration data and ladder logic, and the agencies assess the activity as persistent reconnaissance to develop capabilities and prepare for potential operational effects. Reads are how you buy the process knowledge you do not have. Public reporting does not cleanly establish which write operations were actually observed versus documented as tool capability, and at least one analysis notes the advisory stops short of confirming that — treat the writes as capability, and the reads as the thing that already happened.
Nobody Scanned You. They Queried Censys.
Target selection happened on somebody else's infrastructure, which means your perimeter logs contain no evidence of it. The advisory names Censys and ZoomEye as the services used to locate exposed controllers. The practical consequence, as the 1898 & Co. analysis puts it, is that there is no reconnaissance traffic from the adversary to observe during the target-selection phase. The index did the scanning, months ago, and it is still doing it.
Censys published its own honeypot numbers, and they are worth reading before anyone argues that exposure is a theoretical concern. Across a nine-day deployment from November 23 to December 1, 2025, 764 events arrived from 188 distinct IPs, and S7comm accounted for 395 of them — 51.7%, the most-probed ICS protocol in the set, ahead of Modbus TCP at 25.0%. Moving the service off its well-known port did not take it off the map: a follow-up run from December 17 to January 13 still logged 366 S7comm events on port 103 — a lower daily rate across a window three times as long, but Censys's own read is that S7 is routinely fingerprinted by payload even when ports are shifted.
Only about 2.7% of those S7comm sessions progressed past connection setup into actual protocol exchange. That is not reassuring, it is the mechanism. Most of what hits an exposed PLC is enumeration feeding an index, and the index is what the operator buys a query against later.
"We Would See It" Died With Your Segmentation
For most industrial networks the monitoring-tool disguise is irrelevant, because there is no detection to evade. Dragos published its 2026 OT Cybersecurity Year in Review on February 17, 2026, and the assessment findings are unambiguous: 81% of assessments identified poor IT/OT segmentation, only 46% had adequate OT network monitoring deployed, and 73% of incident response cases involved compromised VPN or jumphost credentials. A further 82% lacked clear criteria for when an operational anomaly should trigger a cyber investigation.
Read those together, remembering these are organisations that hired Dragos rather than a random sample of industry. Among them, four in five cannot keep IT traffic out of the control network, more than half have no OT-aware sensor to begin with, and four in five have no rule for escalating a weird reading. Sophisticated mimicry is a luxury problem for that population.
For the 46% that do monitor, the mimicry is the problem, and it is a real one. snap7 is legitimate software used by legitimate integrators, so the packets it emits are well-formed S7comm indistinguishable from ordinary engineering activity. There is no malformed field to signature. And because the controller had no password, there were no authentication failures to alert on either — the absence of alerts in your historian's log is not evidence of anything. That is the same trap as an AI infrastructure component shipping with token authentication disabled by default: a control that was never enabled generates no failures when it is bypassed.
The Protocol Version Is the Tell, Not the Port
Here is the part the wire coverage skipped: on a modern controller, snap7 traffic is structurally distinguishable from TIA Portal traffic, and you can alert on the difference this quarter.
Classic S7comm carries a protocol identifier of 0x32 as its first byte and dates to the 1994 Simatic S7 launch. S7CommPlus — the dialect an S7-1200 or S7-1500 speaks with TIA Portal and modern HMIs — uses protocol ID 0x72 and adds encryption and integrity checks, while classic S7comm sends everything in clear text, including the PLC password. Released snap7 tooling speaks the classic dialect. So a client negotiating 0x32 against an S7-1500 is, by construction, not TIA Portal.
Three more discriminators are available in the same packets. The COTP connection request carries a source TSAP whose role byte declares the client's claimed identity — 0x01 for a programming device, 0x02 for an operator panel, 0x10 for an HMI — and a programming-device TSAP arriving from anything other than the sanctioned engineering workstation is a finding on its own. The function codes worth hard alerts are 0x1A, 0x1B and 0x1C for RequestDownload, DownloadBlock and DownloadEnded, 0x1D through 0x1F for upload, 0x29 for PLCStop, and SetClock, which shows up in anti-forensic clock manipulation. In ATT&CK for ICS terms these map to T0843 Program Download, T0845 Program Upload, T0813 Denial of Control and T0858 Change Operating Mode, which is the language your OT platform vendor's query builder already speaks.
The unit of allowlisting is the tuple — source host, target CPU, function code, change window — not the port. Suppress by that tuple rather than by protocol, or you suppress the attack along with the historian.
One honest caveat, because it changes where this works. On an S7-300 or S7-400 the protocol-version tell does not exist: those controllers only ever spoke classic S7comm, and any device that can reach port 102 can issue a Stop CPU command. On legacy hardware you are back to source-host allowlisting and physical segmentation, which is the argument for treating the S7-300/400 population as a separate, higher-priority tranche rather than one line in a fleet-wide inventory.
The Checkbox That Makes This Work on Modern PLCs
On an S7-1200 or S7-1500, released snap7 tooling cannot reach the CPU at all unless somebody explicitly enabled it — and that setting is off by default. Classic S7comm access on those controllers is gated by "Permit access with PUT/GET communication" under CPU Properties → Protection & Security → Connection mechanisms in TIA Portal, and snap7 documentation and integration guides treat enabling it as a mandatory setup step precisely because the PLC refuses the connection otherwise.
That gate has a shelf life worth knowing about: python-snap7's maintainers list a native S7CommPlus client — the protocol path that needs no PUT/GET on an S7-1200 or S7-1500 — as the headline feature of the still-unreleased 4.0, so the checkbox is a control that holds today rather than a permanent one.
That reframes the advisory into something a plant engineer can finish. The advisory does not itself draw this line — it attributes the access to default or minimally configured authentication, and points separately at known unpatched vulnerabilities. But for every S7-1200 and S7-1500 in your fleet, the released-snap7 path it describes needs that box ticked — usually ticked years ago, to make a legacy HMI, a historian connector or a third-party datalogger work, and never revisited because unticking it would have broken the thing it was ticked for.
So the question for the walkdown is not "are we vulnerable." It is: on which controllers is PUT/GET enabled, which system needed it, and does that system still exist. In most fleets the honest answer to the third question, for at least a few controllers, is no.
What to Do Before the Next Maintenance Window
This Week:
- Query the indices against your own space, and your integrators'. Run
port:102across Shodan, Censys and Netlas. Require two independent ownership signals — PTR, ASN, certificate CN, WHOIS — before you claim a hit, and record the index timestamp with every one. Integrator-owned address space is where this most often lives, and nobody in your org is watching it. - Pull 90 days of port-102 flow records and answer one question: which source hosts talked to which CPUs. If you cannot answer it from existing data, that inability is the finding. Write it down in that form and take it to the steering meeting, because "we lack the telemetry" funds differently than "we might have a problem."
- Make the log review retrospective, not forward-looking. There were no authentication failures to generate, so a clean alert queue proves nothing. You are looking for reads you cannot attribute to a work order.
This Month:
- Audit the PUT/GET checkbox on every S7-1200 and S7-1500. Produce a list of controllers where it is enabled, the system that required it, and whether that system is still in service. Turn it off wherever the answer is no. This is the single highest-yield hour in the whole exercise.
- Enable the controls that shipped with the hardware and were never switched on: CPU password, protection level set to read-only or full protection, know-how protection and complete restart protection in the programming tool, a cap on simultaneous S7comm connection resources, and the PLC web server disabled where it is not used.
- Build the tuple allowlist and make your OT vendor show you the query. In the 1898 & Co. hunt plan, Claroty filters by OT activity alert category and surfaces the ATT&CK for ICS mappings; Dragos filters notifications on Execution and Impair Process Control; Nozomi pattern-matches 0x1A and 0x1B downloads. If nobody can produce a working query inside a one-hour meeting, you do not have the detection you are paying for.
Before Renewal:
- Name port 102 in your integrator contracts. Prohibit perimeter exposure explicitly, specify the sanctioned remote access method, and require notification before any change to controller protection settings. With 73% of Dragos incident response cases starting at a compromised VPN or jumphost credential, the third-party access path is the control that matters most and the one you renegotiate least often.
- Sequence firmware with Siemens ProductCERT before you schedule anything. In OT a firmware update can break a third-party integration and cannot simply be rolled back, so model-specific compatibility confirmation belongs in the change record before the outage window is booked, not during it.
The Bottom Line
For twenty years the honest reason IT/OT segmentation kept sliding to next year's budget was not that anyone believed the network was safe. It was that the population of people who could do something useful with an S7comm session was small, expensive and mostly employed. That was never a control you owned. It was a labour market, and you were free-riding on it.
What AA26-231A documents is the labour market clearing. The protocol knowledge is in a library anyone can download, the scripting is in a model, and the target list is a paid query against an index somebody else maintains. Meanwhile the fix for the modern half of the fleet has been sitting in a properties dialog, unticked by default, since the S7-1200 V4 firmware — and got ticked anyway, one integration at a time.
None of this needed AI to be dangerous. AI just removed the last reason to assume nobody would bother.
Obscurity was never a security control. It was somebody else's hiring problem, and it just got automated away.
Continue Reading
- CISA Gave 3 Days to Patch Ray. Auth Is Still Off by Default.
- $4.2B for 3 Companies: Why Accenture Just Rewrote OT Security
- Schneider's $3.1B Cognite Deal: Industrial AI's Data War
- 1 in 4 Breaches Are Now AI-Enabled. Each One Costs $6 Million.
- 66,000 CVEs, 3-Day Patches: The White House's AI Cyber War Room
- OpenAI's AI Escaped and Hacked Hugging Face. Yours Will Too.
- Hospitals Test Vendor AI. Fewer Than Half Have a Sandbox.