CVE-2025-64467 is an out-of-bounds read vulnerability classified under CWE-125 found in the NI LabVIEW software, specifically within the LVResFile::FindRsrcListEntry() function. This function is responsible for parsing VI (Virtual Instrument) files, which are the core files used by LabVIEW to represent programs and data flows. When a specially crafted, corrupted VI file is opened, the function reads memory outside the intended bounds, which can lead to unintended behavior. This vulnerability can result in either information disclosure, where sensitive data may be leaked, or arbitrary code execution, allowing an attacker to run malicious code within the context of the LabVIEW process. Exploitation requires that an attacker convince a user to open a malicious VI file, implying user interaction is necessary. The vulnerability affects NI LabVIEW versions 25.3 and earlier, including 23.1.0, 24.1.0, and 25.1.0. The CVSS v3.1 score is 7.8, indicating a high severity with attack vector local (requiring local access), low attack complexity, no privileges required, user interaction required, and high impact on confidentiality, integrity, and availability. No public exploits have been reported yet, but the potential for severe damage exists given the ability to execute arbitrary code. LabVIEW is widely used in engineering, manufacturing, and research sectors for automation and control systems, making this vulnerability particularly concerning for environments where LabVIEW is integral to operational technology or intellectual property protection.

For European organizations, the impact of CVE-2025-64467 can be significant, especially in sectors relying heavily on NI LabVIEW for automation, testing, and control systems such as automotive, aerospace, manufacturing, and research institutions. Exploitation could lead to unauthorized disclosure of sensitive design data or intellectual property, disruption of critical industrial processes through arbitrary code execution, and potential compromise of operational technology environments. This could result in financial losses, reputational damage, regulatory penalties under GDPR if personal or sensitive data is exposed, and operational downtime. Given the integration of LabVIEW in critical infrastructure and industrial control systems, successful exploitation could also pose safety risks. The requirement for user interaction somewhat limits remote exploitation but does not eliminate risk, especially in environments where users frequently exchange VI files or receive files from external collaborators or suppliers.

1. Restrict the sources of VI files: Implement strict policies to only allow opening VI files from trusted and verified sources. 2. User training: Educate users about the risks of opening VI files from unknown or untrusted origins and encourage verification before opening. 3. Application whitelisting: Use application control solutions to restrict execution of unauthorized or suspicious VI files. 4. Network segmentation: Isolate systems running LabVIEW from untrusted networks to reduce exposure. 5. Monitor for suspicious activity: Deploy endpoint detection and response (EDR) tools to identify anomalous behavior indicative of exploitation attempts. 6. Patch management: Although no patch links are currently available, monitor NI’s advisories closely and apply updates promptly once released. 7. Use sandboxing or virtual environments to open untrusted VI files safely when necessary. 8. Implement least privilege principles for users running LabVIEW to limit potential damage from exploitation.