4 minhigh
Cyber Centre Daily Advisory Digest — 2026-08-28 (1 advisories)
The Canadian Centre for Cyber Security published advisory AV26-856 regarding multiple memory corruption vulnerabilities in National Instruments LabVIEW. The vulnerabilities include an out-of-bounds read via integer conversion and an out-of-bounds write via integer overflow. Affected versions include those prior to 23.0.0, 23.3.10, 24.3.7, 25.3.5, and 26.3.1.
Sens:▲ 24hConf:high
Detection / Hunteropenrouter
What Happened
The Canadian government's cyber agency issued a warning about security flaws in National Instruments LabVIEW, a software used in engineering and industrial settings. The flaws could allow attackers to crash the software or potentially run malicious code by exploiting how the software handles certain types of data. Organizations using LabVIEW should check which version they have installed and update to the latest version provided by National Instruments.
Key Takeaways
- National Instruments LabVIEW is affected by multiple memory corruption vulnerabilities, including an integer overflow leading to an out-of-bounds write and an integer conversion leading to an out-of-bounds read.
- Vulnerable versions include LabVIEW prior to 23.0.0, 23.3.10, 24.3.7, 25.3.5, and 26.3.1.
- The Canadian Centre for Cyber Security advises users and administrators to review the provided advisories and apply security updates as they become available.
Affected Systems
- National Instruments LabVIEW (versions prior to 23.0.0, 23.3.10, 24.3.7, 25.3.5, and 26.3.1)
Vulnerabilities (CVEs)
copy:
| CVE | Product | Severity | Description |
|---|---|---|---|
| National Instruments LabVIEW | Memory corruption vulnerabilities exist in NI LabVIEW, including an integer conversion resulting in an out-of-bounds read and an integer overflow resulting in an out-of-bounds write. |
Attack Chain
- Reconnaissance: Attacker identifies a target environment using vulnerable versions of National Instruments LabVIEW.
- Exploitation: Attacker sends crafted input to trigger an integer overflow or integer conversion vulnerability, causing an out-of-bounds write or read.
- Impact: Successful exploitation results in memory corruption, potentially leading to application crashes or remote code execution.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules are provided in the advisory.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The advisory describes memory corruption vulnerabilities in an ICS/engineering application. EDR visibility into the exploitation of these specific flaws is likely limited without application-specific crash or behavioral monitoring. |
| Network Visibility | Medium | If the vulnerable application communicates over a network, anomalous traffic or crafted payloads could be detected, though specifics are not provided in the advisory. |
| Detection Difficulty | Hard | Detecting memory corruption exploitation typically requires application-specific telemetry, crash analysis, or deep packet inspection of protocol traffic, which is not detailed in this advisory. |
Required Log Sources
- Application logs for NI LabVIEW
- Endpoint process execution logs
- Network traffic logs for systems running LabVIEW
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for unexpected crashes or abnormal process termination in systems running National Instruments LabVIEW, which could indicate exploitation attempts of memory corruption vulnerabilities. | Endpoint Detection and Response (EDR) process crash reports, Windows Event Logs (Application Error events) | Exploitation | Medium - Software crashes can occur due to benign bugs or user error, requiring correlation with network activity or other suspicious indicators. |
Control Gaps
- Application-level crash detection and memory corruption alerting
- Deep packet inspection for proprietary ICS protocols used by LabVIEW
Key Behavioral Indicators
- Unexpected termination of LabVIEW executable processes
- LabVIEW processes spawning unexpected child processes (indicating potential code execution following memory corruption)
False Positive Assessment
Low
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Identify all instances of National Instruments LabVIEW in your environment and prioritize patching systems running versions prior to 23.0.0, 23.3.10, 24.3.7, 25.3.5, and 26.3.1.
- If patching is not immediately possible, consider isolating systems running vulnerable versions of LabVIEW from untrusted networks, if supported by your network architecture.
Infrastructure Hardening
- Evaluate whether network segmentation can be applied to restrict access to systems running LabVIEW, particularly those exposed to operational technology (OT) or engineering networks.
- Consider implementing application allowlisting to prevent unauthorized code execution if a memory corruption vulnerability is successfully exploited.
User Protection
- Ensure that engineering and operational technology teams are aware of the advisory and apply updates provided by National Instruments as they become available.
Security Awareness
- Consider incorporating ICS/OT vulnerability management into existing security awareness programs, emphasizing the importance of timely patching for engineering software.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping1 technique
Tactic
Privilege Escalation
Related
Stay currentSubscribe via RSS
