NI LabVIEW EUVD-2026-65594

Exploitation has one hard prerequisite: the victim must open a specially crafted VI file in an affected version of NI LabVIEW (26.3.0 or earlier). This user interaction (UI:P) is a firm limiting factor - purely remote, automated exploitation is not possible. The local attack vector (AV:L) means the malicious file must be present on or accessible from the victim's local system, so the attacker must first succeed in delivering and socially engineering the target into opening the file. No elevated privileges are required of the attacker (PR:N), and there is no indication that a non-default configuration is required - the vulnerability appears to exist in standard VI file parsing. Exploitation risk is highest in environments where VI files are routinely shared across teams without integrity verification, such as collaborative research or distributed industrial test automation groups.

The CVSS 4.0 score of 8.5 (High) reflects high impact across confidentiality, integrity, and availability on the vulnerable system, tempered by a local attack vector (AV:L) and mandatory user interaction (UI:P). The local vector means the malicious VI file must reach the victim's filesystem, and the user must actively open it - ruling out purely remote, unauthenticated mass exploitation. No EPSS data is present in the provided intelligence, so exploitation probability cannot be quantified from that signal. There is no CISA KEV listing and no known proof-of-concept, which materially reduces urgency compared to actively exploited network-vector flaws. However, the delivery model - malicious project files sent to engineers - is well-established and operationally plausible: LabVIEW users in industrial control, research, and test automation settings routinely exchange VI files via email and shared drives, normalizing the behavior an attacker would exploit. The scope is limited to the vulnerable system (SC:N/SI:N/SA:N), so lateral movement is not a direct consequence of initial exploitation. Overall this is a genuine patching priority for LabVIEW-dependent environments, but the absence of KEV listing and the required user interaction argue against treating it as an emergency ahead of network-vector, unauthenticated CVEs.

An attacker crafts a malicious VI file embedding a payload that triggers the out-of-bounds write during parsing, then delivers it to a target engineer or researcher via email, a shared project repository, or a collaboration platform common in industrial or scientific workflows. The victim opens the file in a vulnerable version of LabVIEW, triggering the memory corruption, which the attacker leverages to execute arbitrary code in the victim's user context or extract sensitive in-process data. No public proof-of-concept has been identified at time of analysis.