CISA AA26-231A, AI-generated S7 exploitation

On 18 August 2026, the National Security Agency, the Cybersecurity and Infrastructure Security Agency, the Federal Bureau of Investigation, the Department of Energy, and the Environmental Protection Agency published a joint advisory — AA26-231A, Defending Against an Active Threat to Siemens S7 Series PLCs — warning that threat actors are conducting reconnaissance and capability development against United States Siemens PLC installations using AI-generated exploitation scripts disguised as legitimate monitoring tools.

The advisory is real, it is serious, and it is being reported badly.

We assess with high confidence that the activity described is genuine and that the underlying exposure it addresses is substantial. We assess with moderate confidence that the framing dominating coverage of this advisory — that artificial intelligence fundamentally transforms the operational technology threat landscape — is overstated as applied to OT specifically. The defensible claim is narrower and, in some ways, more uncomfortable: AI compresses the time required to weaponize already-known vulnerabilities against already-exposed devices, and widens the pool of actors capable of doing so. It does not appear to be manufacturing new categories of OT capability.

The barrier to attacking a Siemens S7 controller was never primarily the difficulty of writing the exploit. It was knowing which controller, reaching it, and understanding what the process on the other end actually does. AI erodes the first and third of those. The second — reachability — remains a configuration decision that asset owners control, and it is the one that matters most.

1. AA26-231A documents pre-attack activity, not attack effects. The advisory describes reconnaissance, capability development, and staging. It does not document a successful disruptive incident against a Siemens PLC. Analysts should resist reading it as an incident report.

2. The advisory names no threat actor and does not mention Iran. This is a deliberate and notable contrast with its sibling advisory AA26-097A, which explicitly attributes PLC targeting to IRGC-affiliated CyberAv3ngers. Any link between the two bodies of activity is inference, not fact, and should be labelled as such.

3. The advisory ships no indicators of compromise. Unlike AA26-097A, which distributes structured indicator sets, AA26-231A provides no addresses, hashes, or file artifacts. Its immediate hunting value is behavioral only.

4. No Siemens CVE referenced in this reporting appears on the CISA Known Exploited Vulnerabilities catalog. The only closely related catalog entry is a Rockwell flaw. This materially affects how the risk should be communicated to a risk committee.

5. The most actionable finding in the advisory is unglamorous and predates AI entirely: internet-reachable controllers speaking an unauthenticated protocol on a well-known port. We assess with high confidence that perimeter exposure remains the dominant risk driver, independent of how the exploit script was authored.

AA26-231A carries the seals of five agencies, with NSA in the lead position and hosting the authoritative document. It is marked TLP:CLEAR and covers the S7-200, S7-300, S7-400, S7-1200, and S7-1500 families.

The core assertion is that actors are using AI to generate Python exploitation scripts built on publicly available industrial communication libraries, and that these scripts are being used primarily to read from targeted controllers — extracting configuration, process data, and program structure — in a manner intended to blend with routine SCADA polling.

The advisory’s own language on the AI dimension is measured. It states that using AI to generate exploitation scripts represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools. Elsewhere it notes that AI enables adversaries to rapidly leverage additional attack vectors and adapt to defensive measures.

Note what those sentences claim and what they do not. They claim compression of effort and faster iteration. They do not claim autonomous exploitation, novel vulnerability discovery, or AI-directed process manipulation. Several published summaries have upgraded the advisory’s careful phrasing into something closer to machine-driven attack. That upgrade is not supported by the source text.

The most operationally significant statement in the advisory concerns intent rather than technique: actors are leveraging read access to understand target environments, enabling preparation and positioning for future write operations to cause disruption or other operational impacts. The advisory’s conclusion is equally direct — the combination of known vulnerabilities, accessible exploitation libraries, and AI-assisted development creates a high-probability attack scenario against inadequately protected PLC installations.

That is a statement about inadequately protected installations. It is a conditional, and the condition is one defenders own.

The advisory maps to MITRE ATT&CK for ICS version 19 and Enterprise version 19, blending both matrices. Reconstructed at the analytic level:

Two observations a practitioner should take from this table.

First, the technique inventory contains nothing exotic. Every entry has appeared in ICS threat reporting for years. The novelty claimed by the advisory sits entirely in T1588.007 — the acquisition of AI capability — which is a resource development technique. It describes how the adversary built their tooling, not what the tooling does.

Second, the collection and pre-positioning phases are mapped to distinct techniques for a reason. Read activity and write activity carry very different implications, and the advisory is careful to say that what has been observed is predominantly read, with write activity assessed as the intent. Preserve that distinction in your own reporting. It is the difference between an adversary studying your plant and an adversary altering it.

The advisory names a specific open-source industrial communication library as the foundation of the AI-generated scripts. It is worth being precise about what that means, because the naming has been misread.

The library in question is legitimate, permissively licensed, actively maintained, and in wide daily use by systems integrators, automation engineers, and researchers worldwide. It exists because engineers need programmatic access to Siemens controllers, and it does exactly what it says on the tin. Its appearance in a joint advisory reflects dual-use reality, not any deficiency in the software or wrongdoing by its maintainers. As of publication we have identified no maintainer or community statement responding to the advisory.

Why does the choice matter to an adversary? Three reasons, none of which require enumerating the library’s interface:

It removes the protocol engineering problem. Historically, the hard part of attacking an S7 controller was implementing the proprietary communication protocol correctly. A mature library eliminates that work entirely. This is not an AI effect — it has been true for over a decade.

It makes the traffic ordinary. Sessions generated by standard tooling on the standard port resemble the engineering and monitoring traffic that OT networks carry all day. There is no anomalous protocol implementation to fingerprint. Detection has to come from behavioral context — which host, at what hour, performing which class of operation — rather than from protocol signatures.

It makes the target legible to a language model. Well-documented Python with a large public corpus of example code is close to the ideal input for AI-assisted code generation. The uplift the advisory describes is substantially a function of the library’s maturity and documentation quality, not of any special model capability.

That third point is the one worth internalizing. The AI is not solving industrial control problems. It is writing Python against a well-documented interface, which is among the things current models do most reliably.

The advisory itself enumerates no vulnerabilities, deferring generically to known flaws and to Siemens ProductCERT. The relevant issues in the surrounding literature, verified against primary sources:

Affects the S7-1200 and S7-1500 families, discovered by Claroty Team82. Siemens and CISA score it CVSS version 3 at 8.1; National Vulnerability Database enrichment reflects 9.8, and both figures circulate. A remote unauthenticated attacker with network access to the controller service port could write to protected memory regions. Firmware fixes are available. This is the flaw that converts network reach into code-level influence over the controller.

Affects S7-1200 CPUs below firmware V4.5.0 and S7-1500 CPUs below V2.9.2. Claroty reached it by chaining the prior flaw. Siemens scores it 9.3. Its significance is persistence: key recovery undermines the trust model rather than a single session.

CVSS version 3.1 at 4.7 and version 4.0 at 5.1, requiring victim interaction with a crafted link. This is a low-to-medium severity issue and should not be characterized as critical. We flag this explicitly because it has been inflated in secondary reporting.

This advisory has been widely mischaracterized, including in draft material circulating among analysts. It concerns vulnerabilities in the additional GNU/Linux subsystem of the S7-1500 CPU 1518(F)-4 PN/DP MFP, carries a CVSS version 3.1 base score of 9.8, and enumerates over two hundred vulnerabilities that are overwhelmingly upstream Linux kernel and OpenSSH issues. It does not describe an authentication bypass scored 10.0, does not concern a product called Opencenter X, and does not contain a TIA Portal remote code execution flaw. Analysts repeating those claims should retract them.

None of CVE-2020-15782, CVE-2022-38465, or CVE-2024-46886 appears on the CISA Known Exploited Vulnerabilities catalog. The related Rockwell authentication bypass CVE-2021-22681 was added on 5 March 2026 with a 26 March remediation deadline under Binding Operational Directive 22-01, following confirmed exploitation by Iranian-affiliated actors.

That asymmetry is analytically important. Federal civilian agencies are under binding remediation obligation for the Rockwell flaw and are not for the Siemens flaws. If you are briefing a risk committee that treats catalog listing as the severity threshold, say so plainly rather than letting the advisory’s urgency imply a mandate that does not exist.

The reason a communication library plus network reach is sufficient to matter comes down to protocol design decisions made decades ago.

The legacy Siemens communication protocol — still in use on older controller families, and reachable on newer ones when a specific compatibility setting is enabled — provides no encryption, no authentication in the base protocol, no replay protection, and no integrity checking. Establishing a session requires knowing the controller rack and slot addressing, which is not a secret. This is not a vulnerability in the conventional sense. It is the specification working as designed, for an era when the network boundary was the security control.

Newer controllers introduced a proprietary successor protocol with encryption and anti-replay. Research has repeatedly found that this hardening is incomplete. The research lineage is worth stating correctly, because it is frequently garbled:

• Dillon Beresford, NSS Labs, Black Hat USA 2011, demonstrated replay attacks, authentication bypass, denial of service, and remote memory access against multiple S7 families. CISA issued alerts in response. Specific affected firmware version strings circulating in secondary sources could not be verified against primary documents and should not be repeated.

• Cheng Lei, DEF CON 25 in 2017, with an accompanying Black Hat Europe 2017 whitepaper, published the foundational work on breaking the successor protocol’s protections. This work is frequently and incorrectly cited as a Black Hat 2024 paper. It is not.

• Nadav Adir and Alon Dankner, Technion, Black Hat USA 2024, demonstrated six attacks against the controller TLS implementation, including remote private key theft, machine-in-the-middle enabling malicious program injection, and interception of legitimate key provisioning. This builds on the earlier Rogue7 work presented at Black Hat USA 2019.

The through-line across fifteen years of research: the controller does not reliably verify who is talking to it. Every mitigation that matters flows from accepting that premise and constraining reachability accordingly.

Internet scanning data published on 30 July 2026 counted approximately 4,117 internet-exposed hosts fingerprinting as Siemens SIMATIC S7-1200 globally. For scale, the same snapshot counted roughly 4,148 Rockwell and Allen-Bradley EtherNet/IP hosts and 2,072 Schneider Electric hosts.

Two corrections are required here, because both errors are circulating widely.

First, the geography. Siemens S7-1200 exposure concentrates in southern and central Europe — Greece, Spain, Italy, and Austria together account for approximately 86 percent of the total, each dominated by that country’s leading mobile carrier. A widely repeated claim that United States cellular carriers account for 59 percent of exposed hosts applies to Rockwell devices, not Siemens. The Rockwell population is roughly 71 percent United States-based; the Siemens population is not. Analysts building United States sector risk narratives on the Siemens exposure figure are building on the wrong number.

Second, the provenance. This scanning data was published in response to AA26-097A and a late-July water sector alert. It predates AA26-231A and was not produced to characterize it. The publishing organization is explicit that the work is exposure characterization only and does not confirm that any specific host is a victim.

The consistent signal across both vendor populations is that exposure correlates with cellular connectivity — remote monitoring deployments where a controller was connected to a cellular modem for operational convenience, frequently by an integrator, frequently without the asset owner’s security team knowing the device existed. We assess with moderate-to-high confidence that this deployment pattern, rather than any deficiency in the controllers themselves, is the primary determinant of internet exposure in both populations.

This is where the advisory has been most distorted, so it deserves an honest treatment of the evidence in both directions.

Recent vendor threat reporting establishes that AI-assisted offensive operations are real and measurable. Anthropic’s analysis of 832 accounts banned between March 2025 and March 2026 documented 13,873 actions spanning 482 techniques across all fourteen ATT&CK tactics, with malware generation representing roughly two-thirds of cases and the proportion of medium-to-high-risk actors using AI rising from 33 percent to 56 percent over the period. The same vendor disclosed a Chinese state espionage campaign in which AI autonomously executed an estimated 80 to 90 percent of tactical operations.

Most directly relevant: Dragos documented an AI-assisted intrusion against a municipal water and drainage utility serving the Monterrey metropolitan area in Mexico between December 2025 and February 2026, analyzing over 350 artifacts that were predominantly AI-generated malicious scripts. Per Dragos, the AI acted as primary technical executor and independently identified the OT environment’s relevance to critical infrastructure, investigating possible pathways across the IT/OT boundary.

Separately, prior reporting has documented actors linked to the CyberAv3ngers persona using a commercial AI assistant to ask about code obfuscation and about default passwords for industrial routers and building automation controllers.

Counter-evidence is substantial and, in our assessment, under-reported.

Vulnerability research published in late July 2026 found that of 1,061 vulnerabilities attributed to AI-assisted discovery, only 14 — roughly 1.3 percent — have been confirmed exploited in the wild, matching the baseline rate for vulnerabilities generally. The same analysis noted that of more than 23,000 AI-generated findings from one large-scale program, 126 produced published vulnerability identifiers and exactly one has been confirmed exploited.

OT-specific analysis makes the sharper point: AI-generated ICS malware accelerates existing attack methods, but does not lower the expertise barrier or create new categories of OT threat, because functional malware still requires deep engineering knowledge of industrial protocols and the physical process under control.

And the Monterrey case cuts both ways. It is the strongest real-world OT data point available — and the OT breach attempt failed. The credential attack against the SCADA interface did not succeed. AI-generated tooling ran into conventional access control and stopped.

We assess with moderate confidence that the transformative framing is overstated for operational technology. The evidence supports a narrower conclusion:

• AI meaningfully compresses the development timeline for exploitation tooling targeting known vulnerabilities in well-documented systems.

• AI meaningfully broadens the population of actors who can produce such tooling.

• AI does not, on current evidence, supply the process engineering knowledge required to convert controller access into deliberate, predictable physical effect.

• The IT/OT boundary and conventional access control remain effective, as the Monterrey case demonstrates.

The third point is the crux and deserves emphasis. Reading a controller’s memory tells an adversary the values in it. It does not tell them what those values mean in the context of a specific plant — which tank, which pump, which interlock, what happens downstream when a number changes. That mapping is the genuine barrier to consequential OT attack, it is plant-specific, and it is not available in any public corpus for a model to have learned. An adversary can lower that barrier with insider knowledge, stolen engineering documentation, or extended patient observation. Those remain the hard requirements, and they are where defensive attention belongs.

Strip the AI framing away entirely and one element of this reporting still warrants serious concern.

The sibling advisory AA26-097A documents that at a confirmed United States victim, actors modified controller ladder logic to disable safety shutdown and alarm functions, allowing unsafe conditions to develop without alerting operators. The July 2026 update to that advisory added guidance on detecting malicious modifications to reusable code modules within controller programs.

This is qualitatively different from data theft or service disruption. It is the deliberate degradation of the systems that exist to prevent physical harm, executed in a way designed to be invisible to the humans responsible for the process. As one OT security executive framed the underlying capability: an adversary who has mapped your data blocks understands your process, knows what normal looks like, and therefore knows what an operator would fail to notice.

We assess with high confidence that logic and configuration integrity monitoring is the highest-value detection investment available to OT asset owners facing this threat class — above network signature work, and above patching cadence. If your controllers can be modified and you cannot tell that they were, everything else is secondary. The question to put to your OT team this week is not whether you are patched, but this: if someone changed a controller program yesterday, how would we know, and how long would it take?

For a professional audience, the gaps are as informative as the content. AA26-231A omits:

• Any named threat actor. NSA declined to attribute when asked directly by press. Given that the sibling advisory attributes freely, this silence is likely deliberate rather than incidental.

• Any indicators of compromise. No addresses, hashes, or file artifacts. Hunting must be behavioral.

• Any AI model attribution. The advisory says AI-generated without naming a model, vendor, or describing the evidentiary basis for that determination. Analysts cannot evaluate the claim’s strength.

• Any specific vulnerabilities. Vulnerability specificity is deferred to the vendor.

• Any named victims, dates, locations, or sectors beyond a generic critical infrastructure list.

• Observed effects. The advisory’s assessment language points to persistent reconnaissance intent. It is a capability and tradecraft advisory, not an incident report.

We assess with moderate confidence that these omissions reflect source protection and an ongoing investigation rather than analytic weakness. Practitioners should nonetheless calibrate expectations: this advisory tells you a threat class exists. It does not give you anything to search for.

Independent expert commentary has also noted a structural oddity worth flagging — an advisory premised on AI-enabled offense recommends exclusively conventional defensive measures, with no AI-assisted detection or response guidance.

Ordered by expected risk reduction per unit of effort, not by advisory sequence.

1. Inventory every S7 controller, including ones you did not install. Integrator-deployed cellular-connected devices are the dominant exposure vector in the scanning data. They are, by definition, the ones missing from your asset register.

2. Confirm no controller is internet-reachable. Verify externally rather than trusting network diagrams. Cellular modems bypass your corporate perimeter entirely.

3. Block the industrial protocol port at all perimeter boundaries. The advisory recommends this outright.

4. Disable the legacy compatibility communication setting unless a documented, owned business requirement exists. Where it exists, document it, scope it to specific peers, and review it quarterly.

5. Establish or verify an IT/OT demilitarized zone. The Monterrey case failed at this boundary. That is the strongest available evidence for the control’s value.

6. Enable controller password protection and set protection levels to restrict write access appropriately.

7. Restrict engineering software to allowlisted workstations by hardware and network address.

8. Enforce multi-factor authentication on all remote OT access paths, including vendor and integrator access.

9. Disable controller web servers and unused protocols where not operationally required.

10. Patch the memory protection bypass and hardcoded key flaws on any controller you cannot fully isolate. Note the firmware thresholds: S7-1200 to V4.5.0 or later, S7-1500 to V2.9.2 or later, for the key extraction issue.

11. Alert on write operations to controller memory and configuration from any host that is not an authorized engineering workstation. This is the single highest-value detection in this threat model.

12. Baseline and monitor controller program integrity. Detect logic changes not originating from authorized change control.

13. Deploy OT-aware network monitoring. The advisory names Claroty, Dragos, and Nozomi Networks by way of example.

14. Hunt for industrial communication library artifacts on hosts that have no business talking to controllers — particularly general-purpose IT endpoints and servers.

15. Alert on off-hours, geographically anomalous, and sequentially scanning access to the controller network segment.

Structurally, this maps cleanly to ISA/IEC 62443 zone-and-conduit segmentation. If your program is already aligned there, this advisory should not require new architecture — only verification that the architecture is real.

Outstanding questions we cannot currently resolve:

• What evidence underpins the AI-generation determination? Code artifacts, actor communications, or model provider telemetry?

• Is the AA26-231A actor the same as the AA26-097A actor? The advisories are structured to avoid answering this.

• Were any of the reconnaissance targets subsequently subject to write operations?

• Does the absence of indicators reflect source sensitivity or genuine absence of durable artifacts?

Benchmarks that would change this assessment:

• Addition of any Siemens S7 vulnerability to the Known Exploited Vulnerabilities catalog.

• Publication of indicators or AI model attribution in a revision to AA26-231A.

• Formal attribution of AA26-231A activity to a named actor.

• A documented case of AI autonomously executing a successful controller manipulation — as distinct from accelerating script development or failing at the IT/OT boundary as at Monterrey.

That final benchmark is the one to watch. It has not happened yet. When it does, this analysis requires revision.

APPENDIX A

This appendix is written for practitioners who need to build detections, brief engineering teams, or assess their own controller estate. It is oriented toward defense. Where offensive detail would be required to explain a control, that detail is described at the level of operation class rather than implementation.

Siemens S7 communication rides the following layering:

TCP port 102 is the constant. Every consideration in this report — scanning, access, detection, blocking — reduces to activity on that port. It is registered, well known, and trivially identifiable in flow data.

Session establishment on the legacy protocol requires only that the initiator supply the controller rack and slot addressing. These are physical configuration values, not credentials. There is no key exchange, no challenge, no identity assertion. The protocol was specified for a fieldbus era in which physical and network isolation was the access control.

Properties of the legacy protocol relevant to defense:

The modern successor protocol adds encryption and anti-replay. Published research across 2017, 2019, and 2024 has repeatedly demonstrated weaknesses in the implementation — most consequentially, that the controller does not reliably verify the identity of the peer it is negotiating with. Treat the modern protocol as raising cost, not as providing authentication.

Critical configuration note. Modern S7-1200 and S7-1500 controllers expose legacy-protocol behavior when a specific compatibility setting is enabled in the engineering software. Enabling it permits external read and write access without engineering-software authentication. It is frequently enabled by integrators to make third-party monitoring or historian integration work, and is then never reviewed. This setting is the single highest-value configuration audit item in this report.

Detection requires understanding what an adversary is reading from and writing to. The Siemens memory model exposes several distinct areas:

The distinction that matters analytically: the first five are process data; the last is program logic. Reading process data tells an adversary what your plant is doing right now. Reading program logic tells them what it will do under every condition, including fault conditions. Reading program logic is the more serious event, and it is the one most likely to precede a consequential attack.

Enumeration of program blocks and retrieval of controller identity information — model, firmware revision, serial, module configuration — are the two reconnaissance operations that most reliably indicate an actor is characterizing rather than merely polling. Routine monitoring integrations poll a small, stable set of data blocks. They do not enumerate the program.

AA26-231A maps read activity to Data from Local System, technique T0893, and write activity to Modify Controller Tasking, technique T0821. Preserve that split in your own detection taxonomy, because the two carry different severity and different base rates.

Read operations have a high legitimate base rate. Human-machine interfaces, historians, SCADA polling, and monitoring integrations read continuously. Detection must therefore be contextual — which host, at what cadence, against which areas — rather than operation-based. A detection that fires on read operations will drown you.

Write operations have a low legitimate base rate and a well-defined authorized population. In a mature environment, writes to controller memory originate from a small, enumerable set of engineering workstations, during change windows, under change control. A write operation from any host outside that set is high-fidelity by construction. This is the most favorable detection asymmetry available in this threat model and it is underused.

Practical implication: if you build exactly one detection from this report, build the one that alerts on write-class operations to controller memory or program blocks originating from a host that is not on your engineering workstation allowlist.

The new peer relationship detection is the most valuable and least deployed. OT networks are exceptionally static compared to IT networks. A controller’s set of communication partners is effectively fixed for months or years. A first-time peer is anomalous almost by definition, and a baselining period of two to four weeks is generally sufficient to build the allowlist.

Deep packet inspection distinguishing read from write requires an OT-aware sensor. AA26-231A names Claroty, Dragos, and Nozomi Networks by way of example. Without one, you can still detect at the flow layer — any session to the industrial protocol port from an unauthorized source is actionable regardless of what it contained.

The scripts described in the advisory execute on conventional IT or engineering hosts. That places them squarely inside your endpoint detection telemetry, which is the good news buried in this advisory.

Hunt for:

• Industrial communication library artifacts — the native library or its Python bindings — present on any host that is not a sanctioned engineering workstation.

• Package installation events for industrial communication libraries on general-purpose endpoints and servers.

• Interpreter processes establishing outbound connections to the industrial protocol port.

• Script interpreters running from user-writable or temporary paths with subsequent OT-segment network activity.

• Engineering software installation on non-engineering hosts.

A representative hunting query for a Defender XDR or Sentinel estate. Adapt the allowlist to your environment:

A high distinct-controller count from a single source is the scanning signature. A single controller with sustained connections from an unexpected host is the access signature. Both warrant investigation; the former is more urgent.

Pair this with a file-presence hunt across the estate for the communication library binaries, scoped to exclude your sanctioned engineering images. On a CrowdStrike Falcon estate, the equivalent is a module-load or file-write hunt for the same artifacts, joined against your engineering host grouping.

Caveat worth stating to your team: absence of these artifacts is weak evidence. The scripts are small, the library can be bundled, and execution can be transient. Host-layer hunting is a useful net, not a control.

The most authoritative telemetry, and the least commonly collected:

• Controller diagnostic buffer — review for unauthorized session establishment, mode transitions, and configuration changes. Establish a collection cadence; these buffers are circular and overwrite.

• Program integrity baselining — hash or checksum controller program blocks and compare against the authoritative project repository on a schedule. This is the detection that catches the AA26-097A scenario, in which safety and alarm logic was modified in place.

• Operating mode transitions — run-to-stop transitions and program downloads outside approved change windows.

• Protection level configuration drift — periodic verification that write protection remains configured as intended.

• Process value plausibility — deviation of process variables from engineering expectation, particularly setpoints and alarm thresholds that should be static.

The last item deserves emphasis. If an adversary modifies an alarm threshold, the modification is invisible to network monitoring after the fact and invisible to the operator by design. The only reliable detection is comparing live controller configuration against the authoritative engineering project. If you cannot currently perform that comparison, that gap is the most important finding this report can give you.

Structured for a hunt team with a defined time budget:

H1 and H5 are the highest-yield starting points and are achievable in days rather than weeks. H4 is the highest-value and typically requires OT engineering partnership to execute.

Affects S7-1200 and S7-1500 CPU families, drive controllers, and distributed input/output variants. The flaw permits a remote unauthenticated actor with network access to the industrial protocol port to circumvent the controller memory protection boundary, enabling writes to protected memory regions and reads from restricted areas. Scored CVSS version 3 at 8.1 by Siemens and CISA; National Vulnerability Database enrichment reflects 9.8. Firmware remediation is available across affected families.

Significance: this is the flaw that converts network reachability into influence over controller memory that should have been protected. It is the technical foundation on which the pre-positioning concern rests, and it is also the chaining primitive for the key extraction issue below.

Affects S7-1200 CPUs below firmware V4.5.0 and S7-1500 CPUs below V2.9.2, along with simulation and software controller variants. Researchers reached the key material by chaining the memory protection bypass to obtain native execution. Scored CVSS 9.3 by Siemens.

Significance: this is a trust model failure rather than a session-level flaw. Recovery of key material undermines the assurance that the controller is talking to a legitimate engineering station, with implications that persist beyond any single session. Firmware upgrade to or beyond the thresholds above is the remediation.

Affects several S7-1200 and S7-1500 CPUs with the integrated web server enabled. Requires a victim to interact with an attacker-crafted link. CVSS version 3.1 at 4.7 and version 4.0 at 5.1.

Significance: low to medium. Included here because it has been repeatedly inflated to critical in secondary reporting. Its practical relevance is as a phishing aid against engineering staff, not as a controller compromise vector. Disabling the integrated web server where not operationally required removes it entirely and is good practice regardless.

Concerns the additional GNU/Linux subsystem of the S7-1500 CPU 1518(F)-4 PN/DP MFP. CVSS version 3.1 base 9.8 and version 4.0 at 8.7. Enumerates in excess of two hundred vulnerabilities, overwhelmingly upstream Linux kernel and OpenSSH issues inherited from the embedded distribution. Siemens mitigation guidance centers on running only trusted applications and restricting shell access.

Included to correct the record: this advisory does not describe an authentication bypass scored 10.0, does not concern a product named Opencenter X, and does not contain a TIA Portal remote code execution flaw. Those claims are in circulation and are incorrect.

None of the three Siemens vulnerabilities above appears on the CISA Known Exploited Vulnerabilities catalog as of publication. The related Rockwell authentication bypass CVE-2021-22681 was added 5 March 2026 with a 26 March remediation due date under Binding Operational Directive 22-01. Verify against the live catalog before briefing, as listings change.

Note the structure this table reveals: the first three techniques are not detectable by the asset owner. Reconnaissance against public scanning databases, exploit development, and AI acquisition all occur entirely outside your telemetry. Defensive effort has purchase only from Initial Access onward — which is another way of stating this report’s central argument that reachability, not adversary tooling sophistication, is the variable you control.

For the S7-200, S7-300, and S7-400 families, firmware remediation is not a meaningful strategy. These platforms were designed without a security model and in many cases are out of support. Network isolation, protocol blocking, and compensating monitoring are the only viable controls. Where these controllers are running safety-relevant processes and cannot be isolated, that condition should be documented as accepted risk with executive visibility rather than carried silently by the OT team.