CVE-2026-76987

The EPSS score of 0.00307 for a CVE with a stated public exploit should make you suspicious — not of the EPSS model itself, but of what the 'public exploit' label actually means in this specific context. The disconnect suggests either the exploit circulating is unreliable or untested in real OT environments, or the disclosure moved through coordinated channels that EPSS hasn't captured yet. Treat this as higher-friction intelligence: verify before letting the low EPSS drive prioritization down. The vulnerability lives in CipAttribute::GetAttrData and CipAttribute::SetAttrData — the generic attribute handlers in CIPster's protocol stack. This is not a specialized function; it's the framework code that handles attribute access across the entire CIP object model. Generic attribute logic is where developers defer bounds checking, bake in type assumptions, and treat the attribute layer as a dumb passthrough rather than a security boundary. That's the exact development pattern that produces memory corruption flaws. The classification as memory corruption points toward a type confusion, buffer overflow, or use-after-free in how attribute data gets serialized or deserialized when processing Get/Set requests over the network. The 2026 date on this CVE is not a clerical artifact — it's a maintenance horizon marker. This code path survived multiple fuzzing cycles and security reviews without anyone realizing the attribute access logic was relying on implicit type guarantees that the network layer doesn't provide. The commit hash 1802525be27d33e19a9a83c163e331a1d13b1892 represents code that was effectively forgotten: considered 'done,' untouched, assumed secure by assumption rather than by audit. The patch commit e745d9d4a8ca3a13689066983a1269fe1e567674 is surgically short, which suggests a targeted bounds or type-safety fix rather than a framework rewrite — but that surgical fix is exactly what creates the illusion of closure while similar forgotten patterns persist in sibling code paths. What should you do? First, verify whether CIPster is embedded in your PLCs, safety controllers, or vendor stacks — it often ships as a library inside equipment from multiple vendors, meaning the same vulnerability propagates across product lines without attackers needing to target CIPster specifically. Second, understand that CVSS 7.3 is misleading here: it's pricing severity as a property of the vulnerability, not the system. A memory corruption flaw in generic attribute access reaches everything the CIP object model can address, not one device or one function. Third, recognize that the real risk isn't the CVE itself — it's the lag between patch availability and deployment across OT environments that follow 18-to-36-month patch cadences. Your exposure window started when this disclosure dropped, regardless of when the patch landed in the repository. Assume the vulnerable code is in your environment until your vendor confirms otherwise, and prioritize inventorying whatCIPster-based equipment you're running.

Reviewed through automated stages and approved by a human before publication.