CISA’s ICSA-26-246-07 advisory highlights a critical vulnerability in Pyramid Solutions’ NetStaX EtherNet/IP Stack that deserves particular attention because the weakness exists in a reusable industrial communications stack rather than in one isolated device. The vulnerability, tracked as CVE-2026-78012, is a stack-based buffer overflow affecting NetStaX EtherNet/IP components prior to version 5.6.1. CISA rates it Critical, with a CVSS v3.1 score of 9.8 and a CVSS v4 score of 9.3. The vulnerability can be triggered remotely over the network, does not require authentication or user interaction, and CISA’s assessment indicates that exploitation is automatable and could have a total technical impact on the vulnerable system. 

The underlying problem occurs when a NetStaX implementation processes an unusually large CIP Class 3 explicit-message request. According to the published vulnerability description, the request can exceed the application-side receive buffer without generating the CIP error or warning that would normally indicate the message could not be processed. The oversized payload can therefore reach memory beyond the intended buffer boundary, potentially resulting in memory corruption, a device crash or a remote attack vector. The particularly uncomfortable part is that the originating device may not receive any CIP error indicating that something abnormal occurred, meaning the malformed request can fail silently at the protocol level while still corrupting memory inside the target.

This is important in industrial environments because CIP explicit messaging is legitimate functionality within EtherNet/IP. Explicit messages are used for configuration, diagnostics, parameter access and other non-cyclic communications between industrial devices. An attacker therefore does not necessarily need to introduce an exotic protocol or unusual transport into the OT network. They can potentially abuse a normal industrial protocol operation and manipulate the size of the request until the receiving stack behaves incorrectly. From a monitoring perspective, that means merely allowing EtherNet/IP because it is operationally required is not sufficient. Security controls need to understand whether the messages themselves are structurally valid and reasonable for the device receiving them.

The vulnerability affects several NetStaX variants, including the EtherNet/IP Adapter DLL Kit, Adapter Development Kit, Scanner DLL Kit and Scanner Development Kit, as well as variants that incorporate CIP Security. This is significant because NetStaX is an embedded software component that equipment manufacturers can integrate into their own industrial products. The affected implementation may therefore exist inside devices carrying another manufacturer’s name, and an asset owner may never see “Pyramid Solutions” anywhere on the equipment itself. CISA identifies deployments across critical manufacturing, energy, water and wastewater, and chemical sectors, with worldwide usage.

That supply-chain characteristic changes the vulnerability-management problem considerably. When a vulnerability affects an end-user application, administrators can usually search their software inventory for a product and version. With an embedded industrial protocol stack, the vulnerable component may be several layers below the visible product. The device vendor may have licensed NetStaX years earlier, integrated it into firmware and shipped thousands of products without exposing the underlying stack version to customers. Asset owners therefore cannot safely conclude that they are unaffected simply because they do not knowingly operate a Pyramid Solutions product. Equipment manufacturers and integrators need to determine whether their firmware incorporates affected NetStaX components and communicate that information downstream to customers.

The presence of the vulnerability in CIP Security-enabled variants is also worth noting. CIP Security adds authentication, integrity and confidentiality mechanisms to EtherNet/IP communications, but the presence of a secure protocol layer does not automatically eliminate implementation vulnerabilities inside the protocol stack. Security protocols can protect who is communicating and whether traffic has been altered, while a memory-safety flaw can still exist in the code processing a legitimate message after it has been accepted. This illustrates an important distinction in industrial cybersecurity: secure communications do not compensate for unsafe protocol parsing.

The operational impact can range from denial of service to potentially much more serious compromise. At the minimum, corrupting memory could crash the affected industrial device or application and require a restart. In an ordinary IT environment, a service restart may be irritating. In an industrial environment, loss of a communications component can interrupt monitoring, control or coordination with other equipment. If the affected implementation operates inside a device supporting an active production process, even a temporary crash can create consequences extending beyond the vulnerable computer itself. CISA’s advisory specifically warns of memory corruption and device crashes, while the CVSS assessment reflects potential high impact to confidentiality, integrity and availability.

The potential remote-code-execution dimension is even more concerning. Memory corruption vulnerabilities can sometimes be developed beyond denial of service into controlled execution, depending on the target architecture, compiler protections, memory layout and surrounding implementation. CISA describes the vulnerability as creating a potential remote attack vector rather than stating that arbitrary code execution has been conclusively demonstrated across every affected implementation. That distinction is important. Not every device using the vulnerable stack will necessarily be equally exploitable, but defenders should not assume that a crash is the worst possible outcome simply because reliable code execution has not yet been publicly demonstrated for their specific product.

Pyramid Solutions addressed the problem in NetStaX version 5.6.1 by introducing multiple defensive measures, including a compile-time assertion, runtime payload-size validation and clearer documentation describing the relationship between packet and buffer-size constants. That remediation approach is useful because it addresses both the immediate vulnerability and the development assumptions that allowed it to exist. Runtime validation prevents oversized messages from reaching the vulnerable memory operation, while compile-time checks can make incorrect buffer configurations harder to introduce during future integrations.

For industrial asset owners, however, “upgrade to NetStaX 5.6.1” may not be directly actionable. In most cases, the stack is embedded inside firmware supplied by the device manufacturer. Operators should therefore identify vendors and equipment that implement EtherNet/IP, contact those suppliers to determine whether affected NetStaX components are present, and obtain vendor-approved firmware updates where necessary. Directly replacing a protocol library inside production equipment would rarely be appropriate unless the organization itself develops the affected product.

Network segmentation should provide an important compensating control while remediation is being assessed. EtherNet/IP traffic should generally be restricted to systems that genuinely require it. Engineering workstations, PLCs, HMIs and other industrial assets should not automatically accept CIP communications from corporate user networks, guest networks or the public internet. Firewalls between IT and OT environments should explicitly control EtherNet/IP communication rather than allowing broad connectivity simply because TCP/UDP port 44818 is required somewhere in the environment. Where possible, policies should be defined according to the specific source, destination and operational role of each communicating system.

Protocol-aware industrial firewalls and intrusion-prevention systems can potentially provide additional protection because this vulnerability depends on malformed or abnormally large CIP explicit messages. A security device capable of parsing EtherNet/IP and CIP may be able to identify oversized Class 3 explicit-message requests or other deviations from expected protocol behaviour before they reach vulnerable equipment. Generic port-based filtering cannot make this distinction because both legitimate and malicious traffic may use the same EtherNet/IP service. This is precisely where deeper industrial protocol inspection becomes useful.

Operators should also consider baselining normal CIP communications. Industrial networks are often relatively deterministic compared with conventional enterprise networks. A particular engineering station may communicate with a defined group of controllers using predictable services and message sizes. Sudden large explicit-message requests, new CIP sources or unusual increases in explicit messaging may therefore provide meaningful security signals. Monitoring such deviations can help identify both exploitation attempts and reconnaissance activity.

It is equally important not to expose EtherNet/IP services directly to the internet. CISA routinely recommends minimizing network exposure for industrial control systems, placing control-system networks and devices behind firewalls and isolating them from business networks. Remote access, where required, should use controlled VPN or secure access infrastructure rather than direct connectivity to industrial protocol services. Even a vulnerability that is technically remotely exploitable becomes substantially harder to abuse when an attacker first has to cross properly segmented security boundaries.

Organizations should also distinguish vulnerability severity from evidence of exploitation. At the time of publication, CISA’s enrichment data indicated no known exploitation, and CVE-2026-78012 was not listed in CISA’s Known Exploited Vulnerabilities Catalog. That does not make the issue insignificant. The combination of network accessibility, no authentication requirement, low attack complexity and a widely reusable industrial stack makes it the kind of vulnerability that warrants proactive remediation before public exploit development changes the risk calculation.

Perhaps the most important lesson from CVE-2026-78012 is the hidden dependency problem in operational technology. Industrial equipment is rarely built entirely by the vendor whose logo appears on the enclosure. Controllers, gateways, drives, sensors and other devices can incorporate networking stacks, web servers, operating systems and protocol libraries supplied by third parties. A vulnerability discovered in one underlying component can therefore propagate across many products and vendors without being immediately obvious to the organizations operating them.

For manufacturers, this reinforces the importance of maintaining a software bill of materials for embedded products. If a vulnerability such as CVE-2026-78012 is disclosed, a manufacturer should be able to quickly determine which product versions contain the vulnerable NetStaX library and issue targeted customer guidance. Without that component visibility, every new third-party vulnerability becomes a forensic exercise through years of firmware history.

For operators, the equivalent requirement is supplier visibility. An OT asset inventory should contain more than IP addresses, model numbers and firmware releases. Where possible, organizations should understand important embedded software dependencies and maintain a process for receiving security notifications from equipment suppliers. That becomes increasingly important as industrial devices remain deployed for ten, fifteen or even twenty years while the software components inside them continue accumulating vulnerabilities.

CVE-2026-78012 ultimately demonstrates why industrial cybersecurity has to extend deeper than the visible device.

The vulnerable object is not necessarily the PLC, gateway or industrial appliance that appears in the asset inventory. It may be a protocol stack buried several layers inside the firmware.

And because that same stack can be reused across many products, a single buffer-overflow mistake can quietly become an ecosystem-wide industrial vulnerability.

That is what makes vulnerabilities in shared OT protocol libraries particularly important: the code may be small, but the deployment footprint can be enormous.

View CSAF Summary Successful exploitation of this vulnerability could result in memory corruption, a device crash, or a potential remote attack vector without the originating device receiving a CIP error indicating that the request could not be processed. The following versions of Pyramid Solutions NetStaX EtherNet/IP Stack are affected: EtherNet/IP Adapter DLL Kit (EIPA) EtherNet/IP Adapter DLL Kit with CIP Security (EIPA-SECURE) EtherNet/IP Adapter Development Kit (EADK) EtherNet/IP Adapter Development Kit with CIP Security (EADK-SECURE) EtherNet/IP Scanner DLL Kit (EIPS) EtherNet/IP Scanner DLL Kit with CIP Security (EIPS-SECURE) EtherNet/IP Scanner Development Kit (ESDK) EtherNet/IP Scanner Development Kit with CIP Security (ESDK-SECURE) CVSS Vendor Equipment Vulnerabilities v3 9.8 Pyramid Solutions Pyramid Solutions NetStaX EtherNet/IP Stack Stack-based Buffer Overflow Background Critical Infrastructure Sectors: Critical Manufacturing, Energy, Water and Wastewater, Chemical Countries/Areas Deployed: Worldwide Company Headquarters Location: United States Vulnerabilities Expand All + CVE-2026-78012 An issue in the NetStaX EtherNet/IP Stack prior to v5.6.1 could allow a large Class 3 explicit-message request to exceed the application-side receive buffer without generating an error or warning. The result could be memory corruption, a device crash, or a potential remote attack vector without the originating device receiving a CIP error indicating that the request could not be

Source: Pyramid Solutions NetStaX EtherNet/IP Stack via CISA Advisories — published 03 Sep 2026.