CVE-2026-44944 Affects Linux Open-iSCSI, Not Windows

Microsoft’s entry, published August 8, carries the CVE identifier but does not turn the issue into a Microsoft product vulnerability or provide a Windows KB, affected Windows build, or Windows remediation. The primary technical record is the Open-iSCSI upstream patch, while the National Vulnerability Database identifies SUSE as the CVE source and lists the issue as published on July 29, 2026. That date difference is worth noting: the Microsoft page arrived roughly 10 days after the CVE record was entered, and it should be read as a tracking entry rather than evidence of a new Windows patch.

The immediate priority is to find Linux systems using Open-iSCSI with

enabled, confirm the distributor’s fixed package, and update or backport the upstream correction. Environments that only use Windows Server’s built-in iSCSI Initiator do not need to change configuration because of this CVE.

The bug checks the wrong socket​

Open-iSCSI is a Linux iSCSI initiator implementation. Its user-space components include

, the main control-plane daemon;

, the management tool; and

, a helper used with certain iSCSI-capable network adapters. The upstream project documents

as a helper for particular adapters, rather than a requirement for every software iSCSI deployment.

The defect is unusually small: four changed lines in

. Yet those lines decide whether a connecting local user is accepted as root before being allowed to issue commands to the helper’s control socket.

As documented in the upstream Open-iSCSI pull request, the vulnerable code called its peer-credential validation routine against the daemon’s listening socket file descriptor. The code had already accepted a client connection into a different descriptor,

, but it did not validate the credentials associated with that newly accepted connection. The correction changes the check to use

.

That is the heart of CVE-2026-44944: an authorization decision was made against the wrong endpoint. The patched code validates the actual client connection and continues accepting other requests when an unprivileged caller is rejected. The upstream commit message says the change prevents an unprivileged user from driving the

control socket.

This is a local issue. The disclosed CVSS 4.0 vector assigns a local attack vector, low complexity, no user interaction, and low privileges required. It is not an unauthenticated network attack against TCP port 3260, and it does not mean that exposing an iSCSI target on the network automatically exposes this bug.

The severity score is high, but the deployment conditions limit exposure​

SUSE’s CVE record rates the vulnerability 8.5, High, and assigns high confidentiality, integrity, and availability impact on the vulnerable system. CISA’s SSVC enrichment records exploitation as “none,” automation as “no,” and technical impact as “total.” As of August 11, there is no public indication in those records of observed exploitation in the wild.

The High rating should not be dismissed, but the implementation details put a boundary around the exposure. An attacker must already have a local, low-privilege foothold on the Linux machine, and the machine must be running the affected

component. A Windows admin managing a mixed estate should therefore treat this as a Linux privilege-boundary problem on storage-connected servers, not a reason to patch every Windows endpoint or SAN target.

The relevant systems are more likely to be physical Linux servers using hardware-assisted iSCSI than ordinary desktops. Open-iSCSI’s own documentation describes offload-interface support for hardware from vendors including Broadcom, QLogic, and Chelsio. That does not establish that every driver configuration starts

, but it identifies the class of host where the helper is meaningful and where administrators should begin their inventory.

This also creates a difference between a basic software iSCSI installation and an offload-adapter installation. A host that has

installed solely to mount a software-backed iSCSI LUN may have no running

service at all. A package scanner that reports an affected Open-iSCSI version is useful, but it is not the entire exposure test; service presence and the actual helper binary matter.

Open-iSCSI 2.1.12 contains the upstream fix​

The Open-iSCSI maintainers merged the security work in pull request 535 on July 14, 2026. That pull request contained two separate security fixes: CVE-2026-44944 for

credential verification and CVE-2026-44943 for unsafe handling of malformed iSCSI target names during discovery. They should not be conflated: the former is a local control-socket authorization flaw, while the latter concerns validation of discovered IQN names before they are used in Open-iSCSI’s database paths.

Open-iSCSI 2.1.12, released July 15, includes the pull request and explicitly lists the security fixes in its release notes. For source builds, 2.1.12 is the clean upstream remediation point.

There is, however, an important recordkeeping problem for package managers. The NVD describes affected versions as ranging from an unknown starting point “through” Git commit

, the merge commit for the security pull request. That wording is technically awkward because the actual credential-validation change was introduced earlier in the pull request as commit

, before the merge commit incorporated it into

.

In other words, the NVD entry provides a Git boundary, not a reliable package-version boundary. It does not name a first vulnerable Open-iSCSI release, and it does not enumerate fixed builds from Red Hat, SUSE, Debian, Ubuntu, VMware appliances, or other downstreams. Administrators should not attempt to resolve the CVE solely by comparing package version strings to the merge commit; downstream maintainers may backport the four-line patch without adopting Open-iSCSI 2.1.12.

The NVD itself remains marked “Awaiting Enrichment,” with no NVD-generated base score and no formal product configuration mapping. Its displayed 8.5 score is the SUSE CNA assessment, not an independent NVD calculation. That does not weaken the upstream patch evidence, but it means inventory and remediation guidance are still less complete than they should be for a storage-stack vulnerability.

What Windows and WSL administrators should check​

Native Windows Server and Windows client systems use Microsoft’s own iSCSI Initiator stack, not the Linux Open-iSCSI

program. There is no disclosed affected Windows build, no Microsoft KB associated with this CVE, and no indication that the Windows iSCSI Initiator shares the vulnerable code. Do not disable the Windows iSCSI Initiator or alter CHAP settings as a response to this advisory.

The systems worth examining are Linux VMs, Linux bare-metal hosts, appliances, and clustered infrastructure managed from Windows. That includes Hyper-V guests, Linux-based backup appliances, storage gateways, and virtualization hosts where Open-iSCSI is used to attach shared block storage. Windows Admin Center, Remote Desktop, PowerShell, or System Center may manage those machines, but the vulnerability remains on the Linux guest or host.

A sensible response is:

• Confirm whether iscsiuio is installed and active, rather than treating every open-iscsi package installation as equally exposed.
• Obtain the fixed package from the Linux distribution or move source-based installations to Open-iSCSI 2.1.12 or later.
• Verify package changelogs or distributor advisories for a backport of the credential-validation fix when the distribution retains an older upstream version number.
• Restart the affected service or reboot during the approved maintenance window so the corrected binary replaces an already running iscsiuio process.
• Review which low-privilege accounts can log onto shared Linux storage hosts, especially multi-user systems and appliances with local support accounts.

For WSL, the distinction is similarly practical. A Linux distribution running under WSL can contain Open-iSCSI packages, but that alone does not establish an active vulnerable path. The issue requires the

helper and its local control socket; ordinary WSL installations used for development generally do not use hardware iSCSI offload adapters. Administrators should verify the running services instead of assuming that every WSL distribution is exposed.

The unresolved issue is downstream fix visibility​

The upstream correction has been public since mid-July, but downstream remediation status is not yet fully surfaced in the common CVE records. No public package list in the NVD entry identifies fixed distribution builds, and no other outlet has reported a broader exploitation campaign or a vendor-specific rollout timeline.

That leaves a familiar operational risk: a four-line fix can be easy to apply upstream while remaining hard to verify across long-lived enterprise distributions, appliance images, and custom storage stacks. The right checkpoint is not whether a vulnerability scanner merely recognizes CVE-2026-44944. It is whether each Linux system that actually runs

has a package containing the accepted-client credential check, or has been updated to Open-iSCSI 2.1.12.

For Windows-focused teams, the concrete consequence is straightforward: leave Windows’ native iSCSI stack alone, but use this advisory to chase down the Linux systems behind the storage connection.