libsmb2 CVE-2026-115505

Exploitation requires that the client application uses libsmb2 before 6.3 and calls smb2_share_enum_async() (the NetrShareEnum DCE/RPC operation), AND that the SMB connection is unsigned, which lets a malicious server or a machine-in-the-middle inject a crafted reply. The attacker does not hold credentials but must control the server side or the network path, and the client must initiate the connection/enumeration (passive user interaction, UI:P). Limiting factors that reduce real-world risk: enabling/requiring SMB signing defeats the machine-in-the-middle variant; the bug is only reachable when the client performs share enumeration rather than through any default always-on exposure; and the confirmed technical impact (per the diff) is heap out-of-bounds read/write, with code execution not established in the available sources. The only complete fix stated by the evidence is updating to libsmb2 6.3.

The CVSS 4.0 base score of 7.2 (High) is driven by a network vector (AV:N), low complexity (AC:L), no attacker privileges (PR:N), and a high availability impact (VA:H) from heap corruption, tempered by passive user interaction (UI:P) and only low confidentiality/integrity impact (VC:L/VI:L). The critical qualifier is the threat model: the attacker is a malicious SMB server or a machine-in-the-middle on an UNSIGNED connection, not a party that can reach a listening service - so the victim client must first initiate a share enumeration against attacker-controlled or intercepted infrastructure. This meaningfully narrows real-world exploitability compared to a classic remote-service flaw. No EPSS score and no SSVC exploitation/automatable/technical-impact decision values were supplied, so those framework signals cannot be weighed; the vuln.today 'this_week' decision label indicates elevated but non-emergency urgency (not act_now/emergency). This is not in CISA KEV, so there is no confirmed active exploitation, and the PoC is a hackmd writeup reference that is not verified as working exploit code. Net assessment: a genuine memory-corruption bug worth patching this week, but its server-side/MITM-plus-user-action prerequisites make it better suited to targeted attacks (e.g., hostile shares, rogue networks) than to widespread automated exploitation; the dominant realistic outcome is a client-side crash (denial of service) rather than reliable code execution, which the available evidence does not establish.

An attacker operating a malicious SMB server, or positioned as a machine-in-the-middle on an unsigned SMB connection, waits for a libsmb2-based client to enumerate shares; when the client calls smb2_share_enum_async(), the attacker returns a crafted NetrShareEnum reply whose actual_count/max_count values wrap during size computation, corrupting the client's heap. A public PoC reference (a hackmd writeup) exists but is not verified as working exploit code, so demonstrated impact is heap out-of-bounds read/write and likely client crash rather than confirmed code execution.