CVE-2026-55995
CVE-2026-55995 is a double free in open-iscsi's initiator code, specifically in how it handles connection establishment and reconnection. The CVSS 8.7 reflects genuine severity — memory corruption reachable without authentication. But the EPSS of 0.00252 doesn't mean this isn't dangerous; it means the exploitation path requires MITM positioning on your storage network, which is a specific constraint rather than an insurmountable barrier. The critical question isn't whether to patch — you should — but whether your network topology already gives someone the positioning to trigger this. Storage networks are typically less monitored and less segmented than other infrastructure, and they're architected around implicit trust. If any actor (internal or external partner) can sit between your initiators and targets, they can trigger this. The double free lives in protocol state machine error paths that receive minimal testing — session negotiation and recovery logic are historical mutation hotspots in iSCSI implementations precisely because they're asynchronous, complex, and rarely exercised in normal operations. The 'from ?' version range is a signal. When maintainers can't trace a bug's origin, it typically means the code predates meaningful version control history or has been dormant in forgotten error paths for years. Finding one double free in this attack surface suggests others may exist nearby — the state machine architecture that produced this bug tends to express similar vulnerabilities as a lineage, not isolated mutations. Your priority: verify whether any entity in your environment can achieve MITM on iSCSI traffic paths. If your storage network is genuinely air-gapped from all actors, the exploitability drops significantly. But if there's any shared infrastructure, compromised hypervisor, or partner access that could provide that positioning, treat this as a network segmentation issue first and a patching issue second. The fix at the commit cited addresses this instance; whether the broader session handling code has been audited for sibling vulnerabilities is a separate question your maintenance process should answer.
Reviewed through automated stages and approved by a human before publication.