National Instruments’ flagship engineering tool LabVIEW is the subject of a coordinated security disclosure that identifies nine memory‑corruption vulnerabilities — ranging from out‑of‑bounds reads and writes to a use‑after‑free and a stack‑based buffer overflow — which, if triggered by a specially crafted VI file, may allow information disclosure or arbitrary code execution on affected systems.
Background
LabVIEW (Laboratory Virtual Instrument Engineering Workbench) is a widely deployed graphical programming environment used across engineering, test, measurement, and industrial control systems. The December 2025 coordinated disclosure lists nine CVE identifiers (CVE‑2025‑64461 through CVE‑2025‑64469) and maps each to a specific memory‑safety class and parsing routine inside LabVIEW’s runtime and resource handling components. National Instruments (NI) has published vendor advisories naming the issues and recommending upgrades; the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has also issued an ICS advisory highlighting the operational risk to critical infrastructure sectors. These vulnerabilities are notable for three overlapping reasons:
- They affect engineering workstations and design tools that frequently handle third‑party files (VI files) and thus are natural targets for supply‑chain or social‑engineering vectors.
- The listed weaknesses are classic memory‑corruption classes that can lead to both information leaks and arbitrary code execution when exploited in favourable conditions.
- The attack vector is local/file‑open — a low‑complexity path in environments where files are routinely exchanged among contractors, suppliers, or remote maintenance personnel.
Overview of the vulnerabilities
What was disclosed (short list)
- CVE‑2025‑64461 — Out‑of‑bounds write in mgocre_SH_25_3!RevBL (parsing a corrupted VI) — leads to potential code execution.
- CVE‑2025‑64462 — Out‑of‑bounds read in LVResFile::RGetMemFileHandle — may disclose memory.
- CVE‑2025‑64463 — Out‑of‑bounds read in LVResource:etachResource.
- CVE‑2025‑64464 — Out‑of‑bounds read in lvre!VisaWriteFromFile.
- CVE‑2025‑64465 — Out‑of‑bounds read in lvre!DataSizeTDR.
- CVE‑2025‑64466 — Out‑of‑bounds read in lvre!ExecPostedProcRecPost.
- CVE‑2025‑64467 — Out‑of‑bounds read in LVResFile::FindRsrcListEntry.
- CVE‑2025‑64468 — Use‑after‑free in sentry!sentry_span_set_data.
- CVE‑2025‑64469 — Stack‑based buffer overflow in LVResource:etachResource.
Each of these entries shares the same high‑impact scoring pattern in public trackers: CVSS v3.1 base scores reported around
7.8 (High), with some computed CVSS v4 values in the high‑8 range, reflecting the potential for
confidentiality, integrity, and availability impacts if exploitation succeeds. The attack vector in the canonical scoring is local and requires user interaction — typically a user opening a malicious VI file.
Affected versions (vendor guidance)
NI’s advisory and the mapped remediation guidance identify the following affected lines:
- LabVIEW 2025: versions up to 2025 Q3 (25.3) and earlier are affected; upgrade to LabVIEW 2025 Q3 Patch 3 or later.
- LabVIEW 2024: upgrade to LabVIEW 2024 Q3 Patch 5 or later.
- LabVIEW 2023: upgrade to LabVIEW 2023 Q3 Patch 8 or later.
- LabVIEW 2022: upgrade to LabVIEW 2022 Q3 Patch 7 or later.
- LabVIEW 2021: no longer in mainstream support (NI recommends migrating to supported releases).
CISA’s advisory echoes the vendor mapping and emphasizes that the vulnerabilities impact LabVIEW releases commonly used in engineering and ICS environments.
Technical analysis: how these bugs matter
Memory‑safety failures mapped to real effects
- Out‑of‑bounds reads (CWE‑125): These may leak portions of process memory to an attacker‑controlled parsing path, enabling disclosure of sensitive data (project IP, credentials cached in memory, or other secrets).
- Out‑of‑bounds writes (CWE‑787) and stack overflows (CWE‑121): These can corrupt control data (saved return addresses, stack frames) and — in many cases — be leveraged to hijack execution flow and run attacker code within the context of the LabVIEW process.
- Use‑after‑free (CWE‑416): This typically provides a powerful primitive for attackers to get arbitrary reads/writes by reusing freed objects and can be combined with allocator grooming to increase exploit reliability.
Exploitation of
any of these memory corruption primitives depends heavily on runtime mitigations (ASLR, DEP/NX, Control Flow Guard), the target’s Windows configuration, and the skill of an attacker. However, engineering workstations often run long‑lived images with legacy toolchains, making practical exploitation a real operational risk.
Attack vector and feasibility
- Delivery mechanism: A crafted VI file opened by a user or processed by an automated service (for example, a file repository, preview service, or import pipeline).
- Preconditions: The attacker must convince or trick an operator to open a malicious file (phishing, supply chain, or compromised contractor).
- Privilege scope: Code execution occurs at the privilege of the LabVIEW process; on engineering stations, that is often an interactive user with access to project repositories, instrument drivers, and potentially to OT bridges or PLC configuration tools.
- Scale: Because the vector is local, these flaws are not wormable by default, but targeted campaigns against engineering teams or shared repository servers can achieve broad impact. CISA’s advisory explicitly notes the local+UI requirement while stressing the risks in contractor‑heavy and mixed IT/OT environments.
Immediate remediation and mitigations
Apply vendor patches (first line of defence)
NI’s published remediation is unambiguous: upgrade to the patched Q3 patch levels listed above
as soon as operationally feasible. The vendor published incremental security updates for multiple LabVIEW branches; system owners should obtain patches via the NI Package Manager or official downloads and validate build strings and checksums before deployment.
Operational mitigations when patching cannot be immediate
- Restrict opening of untrusted VI files: Enforce policy that engineering workstations do not open VI files from unknown or unauthenticated sources without scanning and validation.
- Quarantine and sanitize inbound files: Use a quarantined sandbox or dedicated validation VM to open and test third‑party VIs before promoting them to production systems.
- Network segmentation: Isolate engineering and test networks from business networks and from direct internet exposure; limit access to build servers and file shares.
- Least privilege and app allow‑listing: Run LabVIEW under least privilege, enable application allow‑listing (AppLocker/WDAC) for production hosts, and restrict which users can launch engineering tools.
- EDR tuning and logging: Ensure EDR captures process creation, memory exceptions, and unusual child processes spawned by LabVIEW, and configure alerts for suspicious behaviors (e.g., LabVIEW spawning cmd.exe or PowerShell).
- File integrity and provenance checks: Encourage vendors and contractors to sign project artifacts or provide hashes; validate integrity before opening.
Recommended remediation playbook (step‑by‑step)
- Inventory: Identify all hosts running LabVIEW and capture exact version/build strings (automated inventory queries and endpoint scans).
- Prioritize: Rank systems by exposure and business impact — engineering workstations with direct access to OT controllers or build servers are highest priority.
- Test: Apply the vendor patch in a sandbox environment and validate critical workflows, drivers, and custom toolkits.
- Patch: Roll out patched builds according to standard change control windows, starting with high‑risk hosts.
- Compensate: Apply compensating controls (segmentation, disable file previews on servers, restrict file exchange channels) where immediate patching is delayed.
- Monitor: Tune EDR and SIEM for indicators (application crashes, anomalous child processes, unusual network egress).
- Validate: Conduct post‑patch verification and periodic re-audits to ensure no regressions and that patches are in place.
Detection and response guidance
- High‑value signals to monitor:
- Unexpected LabVIEW crashes or repeated exceptions after opening new or external VI files.
- LabVIEW process spawning command interpreters or unexpected child processes.
- New or modified VI files in shared project directories that lack standard signing or provenance.
- Outbound connections from engineering workstations to unknown external hosts after file opens.
- Containment steps on suspected compromise:
- Isolate the affected host from production networks.
- Preserve volatile evidence (memory image, recent files, and process dumps).
- Collect LabVIEW logs, recent VI files, and EDR telemetry for forensic triage.
- Reimage from known good images and rotate credentials that may have been accessed from the workstation.
- Report incidents to vendor CSIRT and national authorities per policy.
Practical considerations for industrial and enterprise teams
Why engineering tooling is a unique problem
Engineering packages like LabVIEW routinely parse complex, proprietary binary formats with nested records, extensions, and large in‑memory datasets. These formats present a perennial source of parsing bugs and memory errors. In industrial contexts, those engineering machines often have privileged channels to controllers and configuration servers. That makes a local file‑parsing vulnerability disproportionately powerful compared to, say, a document viewer on a general user desktop.
Supply‑chain and contractor risk
Project files are frequently exchanged with external contractors and OEMs. Attackers can weaponize that channel by delivering a crafted VI masquerading as a benign project artifact. Tightening file‑exchange policies, enforcing signing, and requiring validation on a sandbox are essential to reduce this risk vector.
Critical analysis: strengths, gaps, and risks
Strengths in the coordinated disclosure
- Vendor patches are available for the affected product lines and NI has provided explicit patch mappings by branch and Q3 patch numbers. That clarity simplifies coordinated patching.
- CISA’s advisory raises awareness across critical infrastructure sectors and provides practical mitigation guidance that aligns with industry best practice for ICS and OT environments.
Practical weaknesses and residual risk
- Local‑vector classification may create complacency. The requirement for user interaction reduces wormability but does not eliminate risk in environments with frequent file sharing or automated processing pipelines; servers that automatically ingest VIs (or preview services) could effectively convert local bugs into server‑side remote attack paths if those services parse files without sandboxing.
- Legacy and unsupported releases (for example, LabVIEW 2021 and earlier) remain an operational challenge. Operators on EOL versions face either migration overhead or prolonged exposure. NI’s advisory explicitly notes LabVIEW 2021 is not in mainstream support, which forces organizations to consider upgrade plans rather than simple patching.
- Exploit reliability varies with host hardening. Modern Windows mitigations impede reliable exploitation; however, industrial images and long‑lived toolchains often lag behind, and attackers can sometimes chain memory primitives to bypass mitigations. Public trackers show high CVSS scores but real‑world exploitability depends on environmental factors.
Unverifiable or time‑sensitive claims (flagged)
- Several public trackers compute CVSS v4 values and may present slightly different scores than the vendor or CISA; treat CVSS numbers as guidance for prioritization rather than absolute risk — verify which score your vulnerability management program uses.
- At the time of the published advisories, CISA reported no known public exploitation, but this status is time‑sensitive. Operators must assume the window of opportunity grows over time and treat the absence of known exploitation as not an assurance of safety. Re-check vendor and national advisories for updates before finalizing risk acceptance.
Longer‑term recommendations and hardening strategy
- Adopt a strict policy for handling third‑party engineering artifacts: only open files in validated sandboxes; require signing or vendor attestation for production project files.
- Implement robust segmentation between engineering workstations and OT controllers; require jump hosts or bastioning for any remote maintenance tasks.
- Integrate LabVIEW version and build verification into your asset management and patch‑management pipelines.
- Periodically re‑test vendor patches in a controlled lab; confirm that patches address the CVEs and that no regressions are introduced into measurement or control workflows.
- Consider compensating runtime mitigations (hardened OS images with CFG/ASLR enforced, WDAC/AppLocker, and EDR policies tuned for engineering tool behaviors).
Conclusion
The disclosure of nine LabVIEW memory‑corruption vulnerabilities is a serious operational security event for organizations that rely on NI’s toolchain. The core risk is straightforward: opening a specially crafted VI can convert routine engineering activity into an attack vector that exposes sensitive IP, credentials, or can result in remote control of systems when attackers can pivot from compromised hosts.
The good news is that vendor patches exist and CISA has amplified the advisory to relevant critical infrastructure sectors. The immediate action for security teams is equally clear and urgent:
- inventory and prioritize LabVIEW hosts,
- test and deploy the NI Q3 patch builds identified by the vendor,
- and apply compensating controls (segmentation, sandboxing of inbound files, least privilege, EDR) where rapid patching is operationally constrained.
This is a classic case where software used every day by engineers deserves the same patch discipline and threat modeling that has long been applied to servers and gateways. The combination of timely vendor fixes, practical operational mitigations, and vigilant detection will materially reduce the risk posed by these CVEs — but organizations must treat the disclosure as a live operational priority and act promptly.
Source: CISA
National Instruments LabView | CISA