On June 16, 2026, CISA republished Rockwell Automation advisory SD1775 warning that two vulnerabilities in FLEX I/O EtherNet/IP adapters 1794-AENTR and 1794-AENTRXT firmware version 2.012 could enable unauthorized access, account takeover, and loss of availability in industrial environments. The headline number is CVSS 9.4, but the more important detail is where these devices sit: close enough to production equipment that “IT incident” and “plant disruption” can become the same event. This is not another desktop patch Tuesday nuisance. It is a reminder that industrial Ethernet has inherited the exposure patterns of enterprise networking without always inheriting its patching velocity.
The affected products are not glamorous pieces of factory infrastructure. FLEX I/O EtherNet/IP adapters are the kind of hardware that disappears into cabinets, remote racks, and long-lived automation cells, translating network traffic into the mundane but mission-critical business of inputs and outputs. That invisibility is exactly why the advisory matters.
CISA lists two affected models: 1794-AENTR and 1794-AENTRXT, both at firmware version 2.012. The vulnerabilities are tracked as CVE-2026-0646 and CVE-2026-0647, with weaknesses described as missing release of memory after effective lifetime and missing authentication for a critical function. In plainer English, one flaw points toward reliability and resource-handling failure; the other points toward a trust boundary that should have existed but apparently did not.
The combination is ugly because industrial control environments prize predictability above almost everything else. A loss-of-availability condition in a conventional IT network may mean a service desk ticket, a failed login storm, or a temporary outage. In an operational technology network, availability can mean whether a process line continues to run safely, whether a remote panel remains visible to operators, or whether maintenance staff are suddenly forced into manual recovery procedures.
CISA says it has not received reports of known public exploitation specifically targeting these vulnerabilities. That matters, but it should not be mistaken for comfort. Industrial advisories often arrive before broad exploitation because the equipment is specialized, the networks are segmented, and proof-of-concept code may not circulate in the same way it does for Windows, Linux, or cloud services. The absence of public exploitation is not the same thing as the absence of risk.
That assumption is the old bargain of industrial networking: the device may be simple, but the network around it is supposed to be controlled. For decades, that bargain was often good enough. Plants were physically isolated, vendor laptops were escorted, remote access was rare, and Ethernet was a convenience layered onto operational practices that still assumed proximity and trust.
That world is gone. Remote support, converged IT/OT monitoring, cloud-connected analytics, managed service providers, VPN concentrators, and flat “temporary” engineering networks have eroded the old perimeter. A control device that once lived behind locked doors may now be reachable through three layers of routing, a forgotten firewall rule, or a vendor access path nobody has audited since commissioning.
The dangerous part is not that every FLEX I/O adapter is suddenly exposed to the internet. Most are not. The dangerous part is that many organizations cannot say with confidence which ones are reachable, which firmware they run, and which remote access paths can touch them. In industrial security, uncertainty is not an administrative inconvenience; it is an attack surface.
Security teams trained on enterprise environments sometimes treat confidentiality and privilege escalation as the crown jewels. In OT, availability and integrity often sit higher in the hierarchy. If a device drops communication, becomes unstable, or requires a restart during production, the cost may be measured in scrap, downtime, safety procedures, and missed delivery windows.
That is why a CVSS score only tells part of the story. A 9.4 rating is severe on paper, but the practical severity depends on placement. An affected adapter in a lab cell is a maintenance item. The same adapter in a remote skid, harsh environment, or continuously running process becomes a scheduling problem, a safety review, and potentially a business risk.
This is the recurring tension in industrial cybersecurity. The fix is rarely as simple as “patch now.” Firmware updates may require downtime, validation, vendor coordination, and rollback planning. But “we cannot patch during production” is not a mitigation strategy by itself. It is a reason to build compensating controls before the advisory becomes an incident.
The uncomfortable truth is that many industrial incidents do not require cinematic malware. They require reachable equipment, weak segmentation, stale credentials, exposed services, or a trusted pathway that no longer deserves trust. The attacker does not need to “break into the factory” if the factory was quietly routed into the enterprise network years ago.
CISA also reminds organizations that VPNs are not magic shields. That caveat is important. A VPN extends trust; it does not cleanse the devices behind it. If the laptop, account, vendor identity, or access policy on one side is compromised, the tunnel can become a well-lit road into the control environment.
For WindowsForum readers, this is where the story intersects with familiar enterprise security. The same identity sprawl, remote access debt, patch deferral, and asset inventory problems that haunt Windows estates also haunt OT networks. The difference is that industrial hardware often has longer lifecycles, narrower maintenance windows, and a far lower tolerance for surprise reboots.
That is why advisories like this become detective work. The affected firmware version is precise: 2.012. But the practical question for operators is whether their asset inventory is precise enough to find it. If firmware version data lives in a spreadsheet last updated during commissioning, the first challenge is not mitigation. It is discovery.
The XT model adds another wrinkle. Hardware designed for extended temperature or harsher environments may be deployed in places that are physically inconvenient to reach. Patching or replacement can require site access, spares, environmental planning, and coordination with production staff. The farther a device is from the IT team’s normal patching process, the easier it is for advisory-driven work to become “next outage window” work.
That delay is understandable, but it changes the risk equation. Once a critical advisory is public, defenders are not the only ones reading it. Even without public exploitation, vulnerability metadata gives attackers and researchers a map of what to investigate. Industrial gear with long patch cycles needs immediate network-level risk reduction, not just a firmware project plan.
In many plants, the most realistic route to an OT device starts with a conventional IT compromise. A phishing email lands on a corporate user. Credentials are harvested. A VPN account is abused. A poorly segmented jump server is reached. From there, the attacker does not need to understand the whole plant; they only need to find reachable industrial services and vendor-specific equipment.
That is why OT advisories should not be filed only with controls engineers. They belong in the same risk conversation as endpoint detection, Active Directory hardening, privileged access management, and network segmentation. A vulnerable adapter is an OT issue; the path to it may be pure IT.
For Windows-heavy shops, the immediate question is whether the systems that can route to these adapters are governed like privileged infrastructure. If engineering workstations have broad plant access, local admin sprawl, weak application control, and casual USB practices, then the adapter vulnerability is only one piece of a larger trust problem.
Vendor advisories can be gated, scattered, or missed by teams that do not live inside a particular supplier’s support ecosystem. CISA advisories create a public, indexed, cross-vendor signal that vulnerability management programs can ingest. For smaller manufacturers without mature OT security staff, that signal may be the first time an issue reaches the right inbox.
The Common Security Advisory Framework angle is also worth noting. CISA’s page points to CSAF summary data, and Rockwell has been moving advisories toward machine-readable formats. That sounds bureaucratic, but it is one of the few scalable answers to industrial vulnerability overload. Humans cannot manually track every controller, adapter, firmware image, and vendor bulletin forever.
The catch is that automation only helps if the asset data is real. A CSAF feed can say version 2.012 is affected. It cannot tell a plant that its north line has three adapters behind an unmanaged switch unless that plant already knows. Machine-readable advisories are a force multiplier for mature inventories, not a substitute for them.
Good segmentation is not merely a firewall drawn between IT and OT. It is a set of enforced, documented, monitored pathways that reflect actual operational need. Engineering stations should not have blanket reachability to every adapter. Vendor support should not be permanently open. Remote access should be time-bound, identity-aware, logged, and reviewed.
The most important work after an advisory like this is often mundane packet-path verification. Can anything outside the control cell reach the adapter? Can the enterprise network initiate connections? Can remote VPN users touch it? Are there legacy routes, dual-homed machines, unmanaged switches, or “temporary” exceptions that became permanent?
This is where many organizations discover that the network diagram is aspirational. The plant changed. A vendor installed a modem. A maintenance project added a bridge. A monitoring tool required access “just for testing.” The vulnerability is new; the exposure is usually old.
The right response starts with triage. Identify affected adapters, confirm firmware versions, map network reachability, determine process criticality, and check vendor mitigation guidance. Then separate devices that can be updated quickly from devices that need outage planning and compensating controls.
Compensating controls should not be vague. They should be testable. Firewall rules should block unnecessary paths. Remote access should be restricted to named users and named systems. Monitoring should alert on unexpected connections to affected adapters. Engineering workstations with access should be hardened as privileged assets, not treated like ordinary desktops with specialized software.
Firmware updates, when available and appropriate, still matter. But in OT, the patch is part of a control package rather than a single heroic act. The goal is to reduce reachable risk now, then remove the vulnerable condition when operationally safe.
Industrial devices often have simple account models compared with modern enterprise platforms. Shared credentials, vendor defaults, role limitations, and weak audit trails remain common in legacy environments. Even when individual accounts exist, they may not be integrated into the organization’s central identity governance in the way Windows administrators expect.
That creates a visibility gap. If an attacker abuses a device-level account or function, will the security operations center see it? Will logs be collected? Will anyone know which workstation initiated the action? Can the team distinguish authorized engineering work from hostile interaction?
These questions matter more than the brand name on the device. The advisory is about Rockwell hardware, but the identity lesson applies broadly across OT. Industrial access must be treated as privileged access, and privileged access must be observable.
The industrial threat landscape has shifted from theoretical concern to repeated real-world probing, opportunistic exposure hunting, and targeted activity against critical infrastructure. Attackers do not need every vulnerability to be weaponized on day one. They can collect advisories, scan for exposed products, and wait for the inevitable lag between disclosure and remediation.
That lag is especially attractive in OT. Enterprise systems may patch on weekly or monthly rhythms. Industrial systems may patch on quarterly, annual, or “when the line is down anyway” rhythms. Public vulnerability knowledge ages differently when the affected asset is expected to run for a decade.
The defender’s advantage is that exploitation usually still requires reachability. If affected adapters are not exposed beyond tightly controlled control networks, the risk becomes harder to realize. If they are reachable from broad IT networks or remote access pools, the advisory deserves urgent attention.
The first pass should be an inventory exercise, but not a passive one. Asset management databases, controller projects, switch MAC tables, network scans approved for OT use, engineering documentation, and maintenance records may all hold part of the answer. No single system should be assumed complete.
The second pass is exposure reduction. If a device does not need to be reachable from outside its control cell, block it. If it needs engineering access, make that path explicit and narrow. If remote support is required, put it behind hardened jump infrastructure rather than broad VPN reachability.
The third pass is operational remediation. Work with Rockwell guidance, test firmware procedures where possible, stage backups, confirm rollback options, and schedule updates according to process risk. The worst patch plan is the one that breaks production; the second-worst is the one that never happens because production might be broken.
A Small Adapter Carries a Large Blast Radius
The affected products are not glamorous pieces of factory infrastructure. FLEX I/O EtherNet/IP adapters are the kind of hardware that disappears into cabinets, remote racks, and long-lived automation cells, translating network traffic into the mundane but mission-critical business of inputs and outputs. That invisibility is exactly why the advisory matters.CISA lists two affected models: 1794-AENTR and 1794-AENTRXT, both at firmware version 2.012. The vulnerabilities are tracked as CVE-2026-0646 and CVE-2026-0647, with weaknesses described as missing release of memory after effective lifetime and missing authentication for a critical function. In plainer English, one flaw points toward reliability and resource-handling failure; the other points toward a trust boundary that should have existed but apparently did not.
The combination is ugly because industrial control environments prize predictability above almost everything else. A loss-of-availability condition in a conventional IT network may mean a service desk ticket, a failed login storm, or a temporary outage. In an operational technology network, availability can mean whether a process line continues to run safely, whether a remote panel remains visible to operators, or whether maintenance staff are suddenly forced into manual recovery procedures.
CISA says it has not received reports of known public exploitation specifically targeting these vulnerabilities. That matters, but it should not be mistaken for comfort. Industrial advisories often arrive before broad exploitation because the equipment is specialized, the networks are segmented, and proof-of-concept code may not circulate in the same way it does for Windows, Linux, or cloud services. The absence of public exploitation is not the same thing as the absence of risk.
The Authentication Flaw Is the Real Alarm Bell
Of the two weakness categories, “missing authentication for critical function” is the one that should make asset owners sit up. Authentication failures in industrial devices are rarely just about who can log into a web page. They can involve who can trigger device functions, change state, reset components, or interact with services assumed to live only inside a trusted plant network.That assumption is the old bargain of industrial networking: the device may be simple, but the network around it is supposed to be controlled. For decades, that bargain was often good enough. Plants were physically isolated, vendor laptops were escorted, remote access was rare, and Ethernet was a convenience layered onto operational practices that still assumed proximity and trust.
That world is gone. Remote support, converged IT/OT monitoring, cloud-connected analytics, managed service providers, VPN concentrators, and flat “temporary” engineering networks have eroded the old perimeter. A control device that once lived behind locked doors may now be reachable through three layers of routing, a forgotten firewall rule, or a vendor access path nobody has audited since commissioning.
The dangerous part is not that every FLEX I/O adapter is suddenly exposed to the internet. Most are not. The dangerous part is that many organizations cannot say with confidence which ones are reachable, which firmware they run, and which remote access paths can touch them. In industrial security, uncertainty is not an administrative inconvenience; it is an attack surface.
Availability Is a Security Property in the Plant
The memory-management issue, described by CISA as missing release of memory after effective lifetime, sounds less dramatic than account takeover. It should not be waved away. Resource leaks and memory exhaustion conditions can become denial-of-service triggers, and denial of service against an I/O adapter is not a theoretical nuisance when that adapter is part of a production cell.Security teams trained on enterprise environments sometimes treat confidentiality and privilege escalation as the crown jewels. In OT, availability and integrity often sit higher in the hierarchy. If a device drops communication, becomes unstable, or requires a restart during production, the cost may be measured in scrap, downtime, safety procedures, and missed delivery windows.
That is why a CVSS score only tells part of the story. A 9.4 rating is severe on paper, but the practical severity depends on placement. An affected adapter in a lab cell is a maintenance item. The same adapter in a remote skid, harsh environment, or continuously running process becomes a scheduling problem, a safety review, and potentially a business risk.
This is the recurring tension in industrial cybersecurity. The fix is rarely as simple as “patch now.” Firmware updates may require downtime, validation, vendor coordination, and rollback planning. But “we cannot patch during production” is not a mitigation strategy by itself. It is a reason to build compensating controls before the advisory becomes an incident.
CISA’s Boilerplate Advice Is Boring Because It Is Still Right
CISA’s recommendations are familiar: minimize network exposure, keep control systems off the public internet, place control networks and remote devices behind firewalls, isolate them from business networks, and use secure remote access such as updated VPNs when remote access is required. The wording is standard because the failure pattern is standard.The uncomfortable truth is that many industrial incidents do not require cinematic malware. They require reachable equipment, weak segmentation, stale credentials, exposed services, or a trusted pathway that no longer deserves trust. The attacker does not need to “break into the factory” if the factory was quietly routed into the enterprise network years ago.
CISA also reminds organizations that VPNs are not magic shields. That caveat is important. A VPN extends trust; it does not cleanse the devices behind it. If the laptop, account, vendor identity, or access policy on one side is compromised, the tunnel can become a well-lit road into the control environment.
For WindowsForum readers, this is where the story intersects with familiar enterprise security. The same identity sprawl, remote access debt, patch deferral, and asset inventory problems that haunt Windows estates also haunt OT networks. The difference is that industrial hardware often has longer lifecycles, narrower maintenance windows, and a far lower tolerance for surprise reboots.
The Installed Base Is the Hard Part
Rockwell Automation’s FLEX I/O family has been around long enough to appear in environments built across multiple eras of networking practice. Some installations were designed when plant-floor Ethernet was treated as an engineering convenience rather than an adversarial medium. Others have been extended, bridged, NATed, monitored, and remotely supported until their original trust assumptions no longer resemble reality.That is why advisories like this become detective work. The affected firmware version is precise: 2.012. But the practical question for operators is whether their asset inventory is precise enough to find it. If firmware version data lives in a spreadsheet last updated during commissioning, the first challenge is not mitigation. It is discovery.
The XT model adds another wrinkle. Hardware designed for extended temperature or harsher environments may be deployed in places that are physically inconvenient to reach. Patching or replacement can require site access, spares, environmental planning, and coordination with production staff. The farther a device is from the IT team’s normal patching process, the easier it is for advisory-driven work to become “next outage window” work.
That delay is understandable, but it changes the risk equation. Once a critical advisory is public, defenders are not the only ones reading it. Even without public exploitation, vulnerability metadata gives attackers and researchers a map of what to investigate. Industrial gear with long patch cycles needs immediate network-level risk reduction, not just a firmware project plan.
The Windows Angle Is Not Windows Itself
This advisory is not about Windows clients, Windows Server, or Microsoft’s monthly update machinery. Still, Windows administrators should care because Windows systems often sit adjacent to the affected terrain. Engineering workstations, historian servers, HMI boxes, jump hosts, domain controllers, patch management tools, and remote access gateways frequently form the bridge between business IT and control networks.In many plants, the most realistic route to an OT device starts with a conventional IT compromise. A phishing email lands on a corporate user. Credentials are harvested. A VPN account is abused. A poorly segmented jump server is reached. From there, the attacker does not need to understand the whole plant; they only need to find reachable industrial services and vendor-specific equipment.
That is why OT advisories should not be filed only with controls engineers. They belong in the same risk conversation as endpoint detection, Active Directory hardening, privileged access management, and network segmentation. A vulnerable adapter is an OT issue; the path to it may be pure IT.
For Windows-heavy shops, the immediate question is whether the systems that can route to these adapters are governed like privileged infrastructure. If engineering workstations have broad plant access, local admin sprawl, weak application control, and casual USB practices, then the adapter vulnerability is only one piece of a larger trust problem.
Vendor Republished Advisories Are Still Actionable Events
CISA describes this as an initial republication of Rockwell Automation Security Advisory SD1775. That phrasing can make the item feel secondary, as if the government agency is merely mirroring vendor content. In practice, CISA republication is often what moves an issue from vendor portal awareness into the wider operational security queue.Vendor advisories can be gated, scattered, or missed by teams that do not live inside a particular supplier’s support ecosystem. CISA advisories create a public, indexed, cross-vendor signal that vulnerability management programs can ingest. For smaller manufacturers without mature OT security staff, that signal may be the first time an issue reaches the right inbox.
The Common Security Advisory Framework angle is also worth noting. CISA’s page points to CSAF summary data, and Rockwell has been moving advisories toward machine-readable formats. That sounds bureaucratic, but it is one of the few scalable answers to industrial vulnerability overload. Humans cannot manually track every controller, adapter, firmware image, and vendor bulletin forever.
The catch is that automation only helps if the asset data is real. A CSAF feed can say version 2.012 is affected. It cannot tell a plant that its north line has three adapters behind an unmanaged switch unless that plant already knows. Machine-readable advisories are a force multiplier for mature inventories, not a substitute for them.
Segmentation Is No Longer a Compliance Diagram
Every ICS advisory eventually says some version of “isolate control systems from business networks.” The phrase is so familiar that it risks becoming wallpaper. But segmentation is the difference between a vulnerability being reachable only by someone already inside a constrained plant cell and being reachable by anyone who compromises a corporate account.Good segmentation is not merely a firewall drawn between IT and OT. It is a set of enforced, documented, monitored pathways that reflect actual operational need. Engineering stations should not have blanket reachability to every adapter. Vendor support should not be permanently open. Remote access should be time-bound, identity-aware, logged, and reviewed.
The most important work after an advisory like this is often mundane packet-path verification. Can anything outside the control cell reach the adapter? Can the enterprise network initiate connections? Can remote VPN users touch it? Are there legacy routes, dual-homed machines, unmanaged switches, or “temporary” exceptions that became permanent?
This is where many organizations discover that the network diagram is aspirational. The plant changed. A vendor installed a modem. A maintenance project added a bridge. A monitoring tool required access “just for testing.” The vulnerability is new; the exposure is usually old.
Patch Planning Has to Respect the Plant Without Surrendering to It
There is a bad way to respond to industrial advisories: demand immediate firmware updates without understanding production impact. There is another bad way: declare patching impossible and do nothing until the next annual shutdown. Mature OT security lives between those extremes.The right response starts with triage. Identify affected adapters, confirm firmware versions, map network reachability, determine process criticality, and check vendor mitigation guidance. Then separate devices that can be updated quickly from devices that need outage planning and compensating controls.
Compensating controls should not be vague. They should be testable. Firewall rules should block unnecessary paths. Remote access should be restricted to named users and named systems. Monitoring should alert on unexpected connections to affected adapters. Engineering workstations with access should be hardened as privileged assets, not treated like ordinary desktops with specialized software.
Firmware updates, when available and appropriate, still matter. But in OT, the patch is part of a control package rather than a single heroic act. The goal is to reduce reachable risk now, then remove the vulnerable condition when operationally safe.
Account Takeover Changes the Conversation
CISA’s summary says successful exploitation could allow unauthorized access, account takeover, and loss of availability. “Account takeover” is the phrase that moves this from device stability into identity risk. If a vulnerability permits an attacker to assume or abuse an account context, the damage may extend beyond a single crash or reset.Industrial devices often have simple account models compared with modern enterprise platforms. Shared credentials, vendor defaults, role limitations, and weak audit trails remain common in legacy environments. Even when individual accounts exist, they may not be integrated into the organization’s central identity governance in the way Windows administrators expect.
That creates a visibility gap. If an attacker abuses a device-level account or function, will the security operations center see it? Will logs be collected? Will anyone know which workstation initiated the action? Can the team distinguish authorized engineering work from hostile interaction?
These questions matter more than the brand name on the device. The advisory is about Rockwell hardware, but the identity lesson applies broadly across OT. Industrial access must be treated as privileged access, and privileged access must be observable.
No Known Exploitation Is a Window, Not a Verdict
CISA’s “no known public exploitation” language should be read as a window of opportunity. It gives defenders a chance to act before incident response pressure distorts decision-making. It does not mean the issue can wait indefinitely.The industrial threat landscape has shifted from theoretical concern to repeated real-world probing, opportunistic exposure hunting, and targeted activity against critical infrastructure. Attackers do not need every vulnerability to be weaponized on day one. They can collect advisories, scan for exposed products, and wait for the inevitable lag between disclosure and remediation.
That lag is especially attractive in OT. Enterprise systems may patch on weekly or monthly rhythms. Industrial systems may patch on quarterly, annual, or “when the line is down anyway” rhythms. Public vulnerability knowledge ages differently when the affected asset is expected to run for a decade.
The defender’s advantage is that exploitation usually still requires reachability. If affected adapters are not exposed beyond tightly controlled control networks, the risk becomes harder to realize. If they are reachable from broad IT networks or remote access pools, the advisory deserves urgent attention.
The Useful Response Is Specific, Not Dramatic
The practical response to this advisory is not panic. It is specificity. Organizations need to know whether they run 1794-AENTR or 1794-AENTRXT adapters, whether any are on firmware version 2.012, and whether network paths exist from enterprise, remote, vendor, or internet-adjacent environments to those devices.The first pass should be an inventory exercise, but not a passive one. Asset management databases, controller projects, switch MAC tables, network scans approved for OT use, engineering documentation, and maintenance records may all hold part of the answer. No single system should be assumed complete.
The second pass is exposure reduction. If a device does not need to be reachable from outside its control cell, block it. If it needs engineering access, make that path explicit and narrow. If remote support is required, put it behind hardened jump infrastructure rather than broad VPN reachability.
The third pass is operational remediation. Work with Rockwell guidance, test firmware procedures where possible, stage backups, confirm rollback options, and schedule updates according to process risk. The worst patch plan is the one that breaks production; the second-worst is the one that never happens because production might be broken.
The Advisory’s Lessons Fit in One Cabinet Door
This is a small advisory by headcount: two CVEs, two named models, one affected firmware version, and no public exploitation reported to CISA. Its significance is that it compresses the modern OT security problem into a manageable case study. The following points are the ones worth taping to the inside of the metaphorical cabinet door.- Organizations should immediately determine whether 1794-AENTR or 1794-AENTRXT adapters running firmware version 2.012 exist anywhere in their environments.
- Network reachability should be treated as the first mitigation, because an unreachable vulnerable device is far harder to exploit than one exposed through broad IT or remote-access paths.
- Engineering workstations, jump servers, and VPN accounts that can reach affected adapters should be handled as privileged infrastructure.
- Firmware remediation should be planned with production impact analysis, tested procedures, backups, and rollback options rather than improvised during an outage.
- The lack of known public exploitation should be used as time to act, not as evidence that action is optional.
References
- Primary source: CISA
Published: 2026-06-16T12:00:00+00:00
- Related coverage: app.opencve.io
Flex I\/o Ethernet\/ip Firmware CVEs and Security Vulnerabilities - OpenCVE
Explore the latest vulnerabilities and security issues of Flex I\/o Ethernet\/ip Firmware in the CVE databaseapp.opencve.io - Related coverage: techjacksolutions.com
Rockwell Automation Vulnerability Rollup (2026-04-13) — Security Intelligence
Iranian state-affiliated threat actors are actively targeting Rockwell Automation and Allen-Bradley PLCs exposed directly to the internet in US critical infrastructure, including power grid and water/wastewater systems, as documented in CISA advisory AA26-097A. No specific CVEs have been...techjacksolutions.com - Related coverage: rockwellautomation.com.cn
Security Advisories | Rockwell Automation
www.rockwellautomation.com.cn
- Related coverage: rockwellautomation.com
SD007 | Security Advisory | Rockwell Automation | CA
www.rockwellautomation.com
- Related coverage: isssource.com
