Eclipse iceoryx2 CVE-2026-92612

Requires an application built on Eclipse iceoryx2 (>v0.8.0) that (1) stores untrusted or potentially non-UTF-8 bytes into a StaticString via its safe mutable-byte APIs and (2) subsequently calls String::as_str(), which does not validate UTF-8, thereby creating an invalid &str and invoking undefined behavior. Exploitation is strongly limited: it is local (AV:L), high-complexity (AC:H) with additional attack requirements (AT:P), needs the application to be coded in the vulnerable pattern, and yields only minor integrity/availability impact with no confidentiality impact. It is not remotely exploitable against a default configuration on its own - it is a soundness hole exposed only through vulnerable consumer code.

This is a genuine-but-very-low-priority Rust soundness (memory-safety) defect, not a remotely weaponizable vulnerability. The vendor CVSS 4.0 base score of 1.0 (AV:L/AC:H/AT:P/PR:H/UI:A) correctly reflects that: local vector, high attack complexity, additional attack requirements, privileges required, active user interaction, and only minor integrity/availability impact (VC:N/VI:L/VA:L). No EPSS score, no CISA KEV listing, and no public exploit are present in the input - status is 'no public exploit identified at time of analysis'. The real risk is a class of undefined behavior (creating an invalid &str) that manifests only when an application actually routes attacker-influenced or malformed bytes into StaticString and then calls String::as_str(); it is a library footgun that requires vulnerable application code to be reachable. One data note: the assigned CWE-749 (exposed dangerous function) fits the safe-API-exposing-unsafe-behavior pattern, but the 'Information Disclosure' tag conflicts with the vendor vector's VC:N (no confidentiality impact) - the true impact is memory-safety/UB, not disclosure. Bottom line: low real-world risk, appropriate to patch during normal maintenance by upgrading to v0.10.0.

A developer builds an application on iceoryx2 that stores externally-supplied bytes in a StaticString and later calls String::as_str() on it; a peer sending non-UTF-8 bytes over the IPC channel causes an invalid &str to be produced, invoking undefined behavior (potential crash or memory corruption) entirely through safe Rust. No public proof-of-concept is provided in the input, and exploitation depends on the application exposing the vulnerable code path.