Authored by: Paul Merchant, Tim Hayes – NetStaX Principal Engineers
NetStaX v5.6.1 is the latest release of Pyramid Solutions’ EtherNet/IP Stack, introducing enhanced protections for explicit messaging, improved buffer-size validation, clearer API terminology, and expanded testing to help developers build more secure and reliable industrial devices.
Modern industrial networks carry a wide variety of EtherNet/IP traffic — from high-speed I/O updates to on-demand explicit messages that read object attributes, trigger diagnostics, or configure devices at runtime. The EtherNet/IP specification allows unconnected explicit messages (UCMM) to carry payloads up to 504 bytes; connected Class 3 sessions can carry significantly more, bounded by the encapsulation packet size limit of 65,535 bytes.
For a stack implementer, those two limits must stay consistent: the network layer must only admit payloads that the application layer is prepared to hold. When that invariant breaks down — even temporarily — the consequences range from a stack corruption crash to a potential security vulnerability exploitable by a remote device on the same network segment.
Prior to v5.6.1, a latent issue in the NetStaX EtherNet/IP Stack 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—all without the originating device receiving a CIP error indicating that the request could not be processed.
NetStaX v5.6.1 addresses this issue with multiple layers of protection, including a compile-time assertion, a runtime payload-size check, and clearer documentation of the relationships between packet and buffer-size constants. The release also includes a project-wide API terminology update that replaces Object with Explicit for unconnected explicit messaging, creating a clearer and more consistent developer experience.
Security Advisory: Forthcoming CVE-2026-78012
The latent vulnerability addressed in NetStaX v5.6.1 was reported on August 21, 2026, for assignment of CVE-2026-78012. The CVE record has not yet been publicly published and is expected to be available within 45 days of the report.
NetStaX v5.6.1 addresses the underlying buffer-overflow condition and is the recommended release for customers using earlier versions of the NetStaX EtherNet/IP Stack.
Additional CVE details, including the official vulnerability description and any associated severity information, will be available once the CVE record is publicly published.
Understanding the Buffer Size Problem
The issue centered on a mismatch between the amount of data the network layer could accept and the amount of data the application layer had allocated to receive.
The stack’s socket layer (eipsckt.h) admitted any explicit-message payload up to MAX_DATA_FIELD_SIZE without checking whether the application-side buffer (requestData[MAX_REQUEST_DATA_SIZE]) was large enough to hold it. Because the two constants were defined in different header files with different formulas and no enforced relationship, the application buffer could silently be smaller than the admitted payload.
The function routerParseObjectRequest() (now routerParseExplicitRequest()) would copy the admitted data into the application structure’s requestData[] array without a bounds check — a classic stack/heap buffer-overflow path that is triggered whenever a peer sends a payload larger than the application buffer but within the network-layer admission window.
A secondary problem was “naming”: internal symbols used the word Object (e.g., NM_CLIENT_OBJECT_REQUEST_RECEIVED, cfg.objectCfg, EtIPObjectRequest) when the EtherNet/IP specification uses Explicit for unconnected messaging. This combination made the API confusing for integrators and obscured the scope of any single change touching that pathway.
Why This Matters for EtherNet/IP Device Developers
For developers building EtherNet/IP devices and applications, this type of issue can be particularly difficult to diagnose because it may not present as an obvious communication failure.
A large explicit request could result in:
- Memory corruption: A large explicit request admitted by the network layer but beyond MAX_REQUEST_DATA_SIZE overwrites memory adjacent to the requestData[] buffer — undefined behavior in C with consequences ranging from silent data corruption to a crash.
- No error to the sender: Because the stack did not check the payload size before copying, the originating node received no CIP error response; it believed its request was queued successfully.
- Maintenance burden: The poorly documented size constants (MAX_REQUEST_DATA_SIZE, MAX_DATA_FIELD_SIZE, MAX_CPF_PAYLOAD_SIZE) and inconsistent naming made the codebase difficult to audit and extend safely.
For engineering teams, the challenge was therefore more than simply preventing a large packet. The underlying size relationships needed to be made explicit and enforceable so that future platform configurations could not inadvertently recreate the same condition.
A Three-Layer Approach to Preventing Buffer Overflows
NetStaX v5.6.1 addresses the issue through three complementary safeguards: preventing invalid configurations at build time, rejecting large requests at runtime, and clearly documenting the size relationships that govern the implementation.
1. Compile-time assertion
An EIP_STATIC_ASSERT was added to eipsckt.h that fires a descriptive compile error if ETIP_EXPLICIT_BUF_SIZE < MAX_CPF_PAYLOAD_SIZE. Any future configuration that recreates a mismatch becomes a build failure, not a runtime surprise.
2. Runtime admission guard
A size check was inserted into routerParseExplicitRequest() immediately before the buffer copy. If the incoming data payload exceeds MAX_REQUEST_DATA_SIZE, the router sets ROUTER_ERROR_NO_RESOURCE and returns — the sender receives a well-formed CIP error response and no memory is touched outside the buffer.
3. Clearer and more consistent size definitions
The chain of size macros was untangled and re-documented with explicit derivations showing the byte-by-byte packet layout. ENCAPH_SIZE was moved to eipucmm.h with a comment explaining why sizeof(ENCAPH) cannot be used directly (alignment). A new IO_PACKET_OVERHEAD composite constant replaced several “magic numbers” in packet-size expressions. MAX_UCMM_SIZE (504 bytes) was properly defined in eipsckt.h and documented with a Doxygen comment. MAX_REQUEST_DATA_SIZE was unified with MAX_CPF_ITEM_PAYLOAD_SIZE / ETIP_EXPLICIT_BUF_SIZE so that the application buffer is always sized to the admitted payload.
Aligning the API With EtherNet/IP Terminology
Our v5.6.1 work also addressed a separate source of confusion in the NetStaX API: terminology.
The EtherNet/IP specification uses Explicit to describe this type of messaging, while several NetStaX symbols historically used Object. For example, identifiers such as EtIPObjectRequest and NM_CLIENT_OBJECT_REQUEST_RECEIVED referred to unconnected explicit messaging.
As part of the update, these identifiers were renamed to use Explicit instead. The change was applied across more than 85 files, including the core C library, C# and VB.NET components, C++ applications, Linux demonstrations, CIP Safety components, and the Modbus bridge.
Examples include:
EtIPObjectRequest → EtIPExplicitRequest
cfg.objectCfg → cfg.explicitCfg
NM_CLIENT_OBJECT_REQUEST_RECEIVED → NM_CLIENT_EXPLICIT_REQUEST_RECEIVED
Although an API rename introduces migration work for existing users, applying the terminology consistently across language bindings and examples provides a clearer, more spec-aligned interface for developers moving forward.
Putting the Fix into Practice
A customer running a large Class 3 scanner against an EtherNet/IP adapter built with NetStaX EtherNet/IP Adapter Developers Kit (EADK) reported intermittent, non-reproducible crashes in the adapter application after deploying a firmware update to the scanner that changed the maximum request size. No CIP error was observed on the network, and the adapter’s watchdog restart obscured the true cause.
Diagnosis: Reviewing the scanner’s new firmware revealed it was now sending explicit-message payloads larger than the adapter’s MAX_REQUEST_DATA_SIZE but within the spec-legal encapsulation limit. The adapter’s router admitted the packet (no size guard), attempted to copy the full payload into requestData[], and overwrote adjacent stack variables — behavior that only manifested as a crash under a specific sequence of object service calls.
Resolution: Updating to NetStaX EIP v5.6.1 causes the adapter to correctly return ROUTER_ERROR_NO_RESOURCE to the scanner for any large payload, the scanner logs a CIP error and does not retry, and the adapter continues operating. The compile-time assertion also immediately flags any future platform configuration where the buffer relationship would be violated.
Engineering for Reliability Beyond a Single Fix
The changes in v5.6.1 reflect a broader engineering approach to maintaining a production-grade EtherNet/IP stack.
Rather than addressing only the immediate buffer-overflow condition, our team addressed the underlying configuration relationships, added protections at multiple stages of the software lifecycle, clarified the public API, and expanded testing around boundary conditions.
New Adapter and Scanner unit tests provide a repeatable framework for validating these boundaries and helping prevent regressions.
For developers and engineering managers, this approach provides an important benefit: protection against the specific issue is combined with improvements designed to make similar issues easier to identify in the future.
What NetStaX v6.5.1 Means for Existing Users
If you’re using an earlier version of the NetStaX EtherNet/IP Stack, v5.6.1 provides an opportunity to address the explicit-message buffer-overflow condition while also adopting the updated API terminology.
Key changes include:
- Protection against large explicit-message payloads that could previously exceed the application receive buffer
- A compile-time assertion to identify invalid buffer configurations
- A runtime admission guard that rejects large requests before the buffer is accessed
- Documented relationships between the relevant packet and buffer-size constants
- The Object → Explicit API rename across supported language bindings and examples
- Expanded boundary-value testing to help prevent regressions
Existing applications should account for the renamed identifiers when migrating to v5.6.1.
Build a More Secure, Reliable EtherNet/IP Device
Ready to upgrade your EtherNet/IP implementation?
- If your access is current, click here to download v5.6.1. and updated NetStaX EtherNet/IP header files. Review the renamed constants.
- If you’d like to reinstate your access, please reach out to our team.
- Learn more about EtherNet/IP cybersecurity best practices on our website.
