Loading today’s stories
Security1 distinct publisher2 min readPublished
CISA's advisory lists eight Pyramid Solutions development kits below v5.6.1 rather than any finished device, so the fix reaches plant floors only after each device maker rebuilds and ships firmware.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
security
A low-privilege login reaches code execution on Rockwell's FactoryTalk Historian ME1 distinct publisher
security
CISA's water-sector answer is an inventory: 100-plus exposed systems, most of them PLCs1 distinct publisher
security
Siemens patches a CAE overflow that lands in the sectors that patch workstations last1 distinct publisher
security
CISA revises the Mitsubishi FA advisory a fourth time for one UDP denial-of-service bug1 distinct publisher
The absent CIP error is the part that changes response work. A NetStaX build below v5.6.1 that receives an oversized Class 3 explicit-message request lets it run past the application-side receive buffer without generating an error or warning [2]. Whatever follows, memory corruption, a device crash, or something an attacker builds on top of that, happens without a protocol-level failure travelling back to the originating device [3], and that is what removes the cheap signal: detection moves to the device side, to unexplained restarts and controller faults. CISA files the defect as CWE-121, a stack-based buffer overflow [4].
Eight entries make up the list, all at versions below v5.6.1 [5]. They are four functional kits, adapter and scanner, in DLL and development-kit form, each shipped in a base and a CIP Security edition: 4 x 2 = 8 [12]. So half the affected list is the CIP Security build, and it needs the same update as the plain one [12].
The eight entries are DLL kits and development kits, not finished devices, the components a builder licenses and compiles into firmware, and the advisory names no OEM and no equipment model [13]. The remediation link CISA publishes is the Pyramid Solutions customer account page, alongside a vendor blog post on the release [7]. The update path therefore runs vendor to licensee, then a firmware build, then qualification, then a release note to the licensee's own customers [14].
The fix reads like a constants problem. v5.6.1 adds a compile-time assertion and a runtime payload-size check, and it also documents more clearly how the packet and buffer-size constants relate to each other [6]. Documentation lands inside a security fix when integrators were able to set those values inconsistently.
Pyramid Solutions reported the vulnerability to CISA itself [9]. The advisory as published carries no CVE identifier and no CVSS score [11]. Deployment is worldwide, across critical manufacturing, energy, water and wastewater, and chemical, from a vendor headquartered in the United States [8].
Ranked by verification strength, evidence, and original report placement.
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.
CISA states 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 processed.
The relevant weakness listed in the advisory is CWE-121, stack-based buffer overflow.
CISA published ICS advisory ICSA-26-246-07 covering the Pyramid Solutions NetStaX EtherNet/IP Stack.
Eight Pyramid Solutions products are listed as affected at versions below v5.6.1: EtherNet/IP Adapter DLL Kit (EIPA), EIPA-SECURE, EtherNet/IP Adapter Development Kit (EADK), EADK-SECURE, EtherNet/IP Scanner DLL Kit (EIPS), EIPS-SECURE, EtherNet/IP Scanner Development Kit (ESDK) and ESDK-SECURE.
NetStaX v5.6.1 addresses the 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.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 3, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Precise, first-party, unchecked
The technical account is unusually specific for an ICS advisory — Class 3 explicit messaging, the application-side receive buffer, CWE-121, an exact fix version — and it comes from the agency of record. It also comes from exactly one document, written from what the vendor disclosed about its own code, with an empty Metrics section: no CVE, no score, no independent researcher writeup to test the description against.
Nothing countable
CISA offers 'worldwide' and four sectors, and that is the entirety of the exposure picture. No OEM, no device model, no licensee count, no patch-uptake figure appears — and a stack compiled into someone else's firmware leaves no footprint anyone outside the vendor can tally. Scoring uptake here would mean inventing it.
Understated by omission
Nobody is overselling this. If anything the framing is quieter than the facts warrant: a silently overrunnable buffer reachable through ordinary CIP explicit messaging, in a component deployed worldwide across manufacturing, energy, water and chemical plants, arrives with no severity score, no CVE, and a remediation section that amounts to a login page and a blog link. The absence of reported exploitation is the one thing holding the temperature down.
Vendor-shaped, vendor-disclosed
Pyramid Solutions found the bug, brought it to CISA, and supplies the only detailed explanation of it — in a post CISA links as remediation. Self-reporting cuts genuinely against suppression. What remains is control of depth: the vendor sets how much of the failure is described, and the result is a disclosure with no minted identifier and no named OEM, which is the comfortable shape for a component supplier whose customers are the ones who must rebuild.
Firm on the bug, blind past it
Take the defect and the fix as solid — first-party disclosure through the agency is about as reliable as this genre gets, and v5.6.1 is documented as available. Confidence drops sharply after that. Which device makers carry the vulnerable build is unknown, and our reading that the patch only lands after a licensee rebuilds and requalifies firmware is inference from the kit names and the download path, not something CISA states.