CVE-2026-55995: open-isns DoS Fix, Not Windows iSCSI

Microsoft’s Security Update Guide has an entry for CVE-2026-55995 describing a double-free in an iSNS attribute decoder and labels it as affecting “open-iscsi.” The primary upstream record is more precise: on July 28, 2026, open-isns maintainer Lee Duncan merged commit

, incorporating a patch titled “Fix issue in error path causing double-free.” The underlying change is commit

.

There is also a timing problem in the Microsoft metadata supplied with the entry. It says the record was published at August 8, 2026, 01:41:38 -07:00, which converts to 08:41:38 UTC. At the time of this report, Saturday, August 8, 2026 at 04:06 UTC, that timestamp was still more than four and a half hours in the future. That does not invalidate the upstream fix, but it means administrators should not treat the Microsoft page’s publication field as a reliable disclosure timeline until Microsoft corrects or updates it.

The flaw is in open-isns, not the Windows iSCSI stack​

The wording around this CVE matters because “open-iscsi” can describe both an iSCSI deployment and a particular Linux project. Open-iSCSI’s own project documentation describes it as a Linux implementation with a kernel-side data path and a user-space control plane consisting of

and

. The vulnerable parser is located in the separately maintained open-isns repository, which provides the iSNS client and server components and the

library.

That distinction changes who needs to respond. Native Windows systems using Microsoft’s built-in iSCSI Initiator do not use Open-iSCSI or open-isns, so this CVE does not create a Windows Update or Microsoft patch requirement. Windows administrators should look instead at Linux systems that sit beside Windows infrastructure: WSL instances, Hyper-V or VMware Linux guests, Kubernetes worker nodes, storage gateways, backup appliances, and Linux-based SAN management hosts.

The Open-iSCSI project can consume open-isns for Internet Storage Name Service discovery, an older but still deployed storage-discovery protocol standardized in RFC 4171. iSNS lets storage nodes, targets, portals, and discovery domains exchange registration and query information. In a typical environment, that makes the iSNS service a trusted piece of storage control-plane infrastructure. CVE-2026-55995 is relevant only where that feature and its parser are actually present and reachable.

The practical implication is that an

package inventory alone may be insufficient. Administrators need to identify whether

,

, or a statically bundled copy of the same code is installed. A host can have the Open-iSCSI initiator installed without actively using iSNS, while an iSNS server, discovery appliance, or management process may parse the affected message attributes directly.

A failed buffer read leaves a freed pointer behind​

The upstream patch identifies two affected decoding routines in

:

and

. Both allocate memory for an incoming iSNS attribute value, call

to copy bytes from the message buffer, and free the new allocation if that buffer read fails.

Before the patch, the pointer retained its now-invalid address after that first

call. The decoder then returns failure. Subsequent error cleanup can encounter the same non-null pointer and free it again, producing the double-free condition.

The repair is deliberately small:

• The string decoding path now sets value->iv_string to NULL after freeing it following a failed buffer read.
• The opaque-data decoding path now sets value->iv_opaque.ptr to NULL after its equivalent failed buffer read.

This is a conventional ownership-cleanup error, but it exists in a network-message parser. The faulty path requires a failure after allocation while decoding an iSNS attribute, such as a message whose declared attribute length does not match the bytes actually available to the decoder. The patch author explicitly says the double-free “could lead to a DoS attack.” No upstream advisory, Microsoft entry, or independent report located for this CVE establishes remote code execution, privilege escalation, data exposure, an in-the-wild exploit, or a CVSS score.

That is an important limit on the claim. The confirmed impact is a process-level crash or availability failure in a component parsing a malformed iSNS attribute. It should be treated as a security maintenance issue for exposed iSNS services and clients, but the available record does not support calling it an RCE or a compromise of storage data.

The patch landed after the latest open-isns release​

The release gap is the operational issue. GitHub’s open-isns release page still lists version 0.103 as the latest tagged release. That release predates the July 28 fix; the repository’s commit history shows

and the merge commit

arriving well after the 0.103 release lineage.

In other words, “open-isns 0.103” is not enough evidence that a host is fixed. A vendor may have backported the patch into its package without changing the upstream-style version number, or it may still ship an unpatched 0.103-based build. Conversely, building from the current upstream

branch after commit

includes the correction, but many production systems deliberately avoid tracking an untagged branch.

This is why the Microsoft Security Update Guide’s abbreviated “open-iscsi” product label is potentially misleading. The actionable artifact is not a Windows KB, a Linux kernel update, or an Open-iSCSI user-space release. It is a particular open-isns source revision that corrects two cleanup paths in

.

For Linux distribution maintainers, the remediation path is straightforward: backport upstream commit

, or ship a release that includes it. The change is narrow enough that it should be low-risk to carry as a distribution patch, although every vendor must validate it against its own build flags, memory allocators, and integration patches.

What Windows and storage administrators should check now​

The right first step is scope reduction rather than indiscriminate patching. Most Windows desktops and servers will have nothing to do here. The priority systems are Linux hosts that use iSNS discovery or run iSNS services, especially where storage discovery traffic crosses network segments or depends on an external appliance.

Administrators should verify all of the following:

• Confirm whether open-isns, libisns, isnsd, or isnsadm is installed on Linux hosts that provide or consume iSCSI discovery.
• Check whether Open-iSCSI has been configured to use an iSNS server rather than static discovery, SendTargets discovery, or firmware discovery.
• Ask the Linux vendor whether its shipped open-isns package includes the July 28, 2026 upstream fix for CVE-2026-55995.
• If no vendor update exists, assess a backport of commit 56718d4 rather than assuming an Open-iSCSI package update addresses the issue.
• Limit iSNS connectivity to intended storage nodes and management networks while remediation is pending, because the vulnerable routines process incoming iSNS attribute data.

The final item is mitigation, not a substitute for the patch. Restricting which systems can send iSNS traffic reduces exposure, but it does not repair a parser that mishandles a failed read. It also does not help when the source of malformed messages is a trusted but compromised discovery server.

The disclosure record still lacks the facts operators need​

Microsoft’s entry supplies the CVE identifier and basic flaw description, but the record as supplied does not state affected open-isns versions, fixed package builds, severity, exploitability assessment, known exploitation status, or whether Microsoft has any product-specific exposure. The JavaScript-rendered Microsoft page also does not expose those details in its publicly retrievable text at present.

The upstream commit provides a stronger technical anchor than the disclosure metadata: it identifies the exact file, the two decoder routines, the failure condition, the remediation, and the anticipated denial-of-service consequence. But even upstream has not published a dedicated security release or a broader advisory explaining which historical versions are affected.

For now, the reliable dividing line is source history. Builds that include commit

, merged as

on July 28, 2026, contain the fix. Builds based on the prior open-isns 0.103 release need vendor confirmation or source-level verification.

References​

1. Primary source: MSRC
   Published: August 8, 2026 at 8:41 AM UTC
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
2. Related coverage: msrc.microsoft.com
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: nvd.nist.gov
   
   https://nvd.nist.gov/vuln/detail/CVE-2025-21993
4. Related coverage: github.com
   
   

   linux/fs/open.c at master · torvalds/linux · GitHub

   Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

   github.com
5. Related coverage: raw.github.com
   
   

   oec paper

   PDF document

   raw.github.com
6. Related coverage: git.powerel.org
   
   https://git.powerel.org/powerel7/base/src/commit/4116216f3e94b2043aa122860ef164eac012cedc/SOURCES/keep-open-isns.patch
7. Related coverage: open-iscsi.com
   
   Open-iSCSI by open-iscsi
8. Related coverage: manpages.debian.org
   
   isnsadm(8) — open-isns-utils — Debian testing — Debian Manpages
9. Related coverage: archlinux.org
   
   

   Arch Linux - open-isns 0.103-1 (x86_64)

   archlinux.org
10. Related coverage: groups.google.com
    
    

    [PATCH 0/3] open-isns: prepare for external use by open-iscsi

    groups.google.com
11. Related coverage: gitverse.ru
    
    

    githubmirror/open-isns | Gitverse

    githubmirror/open-isns. Current files and descriptions. Branches and discussions on the GitVerse developer platform.

    gitverse.ru
12. Related coverage: packages.debian.org
    
    I Challenge Thee
13. Related coverage: openmamba.org
    
    open-iscsi (Source RPM) | openmamba | Linux distribution