Critical 9.8 CVSS Stack Overflow in NetStaX EtherNet/IP SDK Exposes Industrial Supply Chain

As reported by CISA in advisory ICSA-26-246-07, Pyramid Solutions has disclosed a critical stack-based buffer overflow (CVE-2026-78012) in its NetStaX EtherNet/IP Stack, carrying a CVSS v3.1 base score of 9.8. The flaw allows an unauthenticated network attacker to send oversized Class 3 explicit-message requests that exceed application-side receive buffers without triggering any CIP error or warning — meaning the failure is silent, and exploitation may go undetected by standard protocol-level monitoring.

Vulnerability Details

The eight affected kits — spanning Adapter and Scanner variants in both DLL and Development Kit form factors, with and without CIP Security — represent the full breadth of Pyramid's EtherNet/IP product line. This is not a single-device firmware bug; it is a protocol stack defect embedded in OEM products.

Why This Matters More Than a Typical ICS Advisory

The critical detail that elevates this advisory beyond a standard patch-and-go scenario is the supply chain dimension. Pyramid Solutions sells NetStaX as a licensable stack to equipment manufacturers who embed it into their own industrial devices — PLCs, motor drives, I/O modules, human-machine interfaces, and specialized controllers. When a vulnerability lives in a protocol stack SDK rather than in a finished product, the remediation path fragments:

The fundamental challenge: asset owners likely do not know which of their devices contain the NetStaX stack. EtherNet/IP compliance does not require vendors to disclose their underlying stack supplier.

This creates a significant visibility gap. A plant engineer may have hundreds of EtherNet/IP devices on the floor and no practical way to determine which ones are vulnerable without contacting each vendor individually — assuming the vendor itself is aware of which stack version their current firmware embeds.

The Silent Failure Problem

The advisory's description of the vulnerability is particularly concerning from a detection standpoint. The oversized request does not generate a CIP error to the originating device. This means traditional EtherNet/IP traffic analysis tools that rely on CIP response codes to flag anomalous behavior will not see an error condition. The buffer overflow happens, memory is corrupted or the device crashes, and the protocol layer reports nothing unusual. Defenders cannot rely on application-layer error logging alone to detect exploitation attempts.

Who Is at Greatest Risk

Organizations in Critical Manufacturing, Energy, Water/Wastewater, and Chemical sectors with EtherNet/IP-capable devices on flat or poorly segmented networks face the highest exposure. The CVSS vector confirms network adjacency is sufficient — no authentication, no user interaction, and full impact across confidentiality, integrity, and availability. Any device running a pre-v5.6.1 NetStaX stack that is reachable on TCP port 44818 (EtherNet/IP) is vulnerable to a remote, unauthenticated attacker causing device crash or potential code execution depending on platform architecture and memory protections.

Shield53 Recommendations

Immediate Actions

• Inventory EtherNet/IP assets: Identify all devices speaking EtherNet/IP on operational networks. Query vendors directly to determine whether their firmware embeds the Pyramid Solutions NetStaX stack and which version.
• Enforce network segmentation: Ensure all EtherNet/IP devices are isolated behind industrial firewalls or data diodes. No EtherNet/IP traffic should traverse the IT/OT boundary without explicit, documented justification. Port 44818 should never be internet-reachable.
• Deploy deep packet inspection: Since CIP error codes will not flag malicious oversized requests, configure IDS/IPS rules to detect EtherNet/IP Class 3 explicit messages exceeding expected payload sizes. Monitor for abnormal ENIP session establishment patterns.
• Apply vendor patches as available: Once OEMs release firmware incorporating NetStaX v5.6.1, prioritize patching on a risk-based schedule. For devices where patches are unavailable, apply compensating controls.
• Enable CIP Security where supported: Devices using the SECURE variants should ensure CIP Security (which includes device authentication and message integrity) is actively configured, not merely licensed. While this vulnerability exists in the SECURE variants as well, authenticated session requirements may reduce remote exploitability in properly configured deployments.

Longer-Term Actions

• Build a software bill of materials (SBOM) practice for OT: Track not just device firmware versions but embedded third-party components and stack versions. This advisory demonstrates why OT asset management must extend below the device level.
• Establish vendor security disclosure expectations: Include contractual requirements for OEMs to notify you within a defined SLA when third-party stack vulnerabilities affect their products.
• Test EtherNet/IP fuzzing on critical devices: Organizations with mature OT security programs should consider supervised fuzzing of EtherNet/IP interfaces in a non-production environment to identify buffer-handling weaknesses before adversaries do.

This vulnerability is a textbook example of why ICS security is fundamentally a supply chain problem. The patch exists, but the remediation will play out across dozens of OEMs and thousands of deployed devices over an extended timeline. Defenders who treat this as a simple version-update task will underestimate their exposure. Those who use it as a catalyst to improve OT asset intelligence, segmentation, and vendor management will be materially more resilient when the next stack-level vulnerability inevitably surfaces.