CVE-2026-64196

Executive Summary

CVE-2026-64196 is an out-of-bounds write (CWE-787) vulnerability in Ni (National Instruments) DASYLab, a data acquisition and analysis application that operates on .DSB project/document files. The flaw stems from improper validation of user-supplied data, causing data to be written past the end of an allocated heap buffer, which can corrupt memory and potentially enable arbitrary code execution in the context of the application. All versions before 2026.0.0 are affected, and exploitation requires user interaction — specifically, convincing a user to open a specially crafted .DSB file. With a CVSS score of 7.8 (High), no known public exploit, and a minimal EPSS score indicating low current exploitation likelihood, this is primarily a targeted-attack and secure-development concern rather than a widespread opportunistic threat.

Technical Analysis

The vulnerability resides in DASYLab's processing of .DSB files. .DSB files are project/document containers used by DASYLab to store worksheet configurations, data acquisition setups, and analysis parameters. When DASYLab parses a .DSB file, it reads structured fields defined within the document and allocates heap memory to hold the deserialized content. The improper validation of user-supplied data within this parsing path allows a crafted file to specify values (such as lengths, field sizes, or counts) that are not checked against the size of the destination allocation. Because validation is missing or insufficient, the application writes past the end of the heap buffer, a classic CWE-787 out-of-bounds write.

The root cause class — improper validation of user-supplied data leading to heap overflow — is well understood. The parser trusts length or size fields embedded in the file without verifying them against the actually allocated buffer size. When a value exceeds the true capacity of the destination, the write operation corrupts adjacent heap metadata or objects. Heap corruption of this kind is frequently convertible to control-flow hijacking on platforms without robust memory protection, and can be leveraged for arbitrary code execution or at minimum for denial of service (crash) when modern mitigations like ASLR/DEP are present. On Windows (the primary DASYLab deployment platform), heap metadata corruption can also be abused through techniques such as heap spraying and heap feng shui to influence allocation layout and steer corrupted metadata toward attacker-controlled data.

The attack surface is local file processing: the application opens a user-supplied file from the filesystem. There is no network-listening component invoked by this CVE, which is consistent with the CVSS vector's AV:L and UI:R components (local access, user must open the file). The AC:L rating reflects that no special conditions beyond file opening are needed, and PR:N reflects that no privileges are required before exploitation to trigger the flaw — the memory corruption occurs in the user's process context. The C/I/A impact is High across all three metrics, consistent with potential arbitrary code execution in the user's context, which can read/modify/delete data and disrupt application availability.

Because the NVD description does not specify the exact offset, field, or function responsible, no specific internal identifiers (function names, class names, parse routines, or struct fields) can be attributed. Analysis must remain at the vulnerability-class level: user-controlled sizes in a file format are trusted, causing a heap buffer overflow during document deserialization.

Exploitation Scenarios

1. Reconnaissance/target identification: An attacker identifies an environment where DASYLab is deployed — typically engineering labs, test and measurement teams, R&D groups, industrial monitoring stations, or academic research facilities. Since the file format is .DSB, the attacker does not need network access to the victim; the target must be induced to open a crafted file. Reconnaissance therefore centers on identifying users who routinely open .DSB files (engineers, lab technicians, technicians in test environments).

2. Triggering the flaw: The attacker crafts a .DSB file whose embedded data causes the parser to compute or accept an out-of-bounds write. The attacker must determine which fields within the .DSB format influence allocation and copy lengths; this is done through format analysis and fuzzing. Upon opening the file, DASYLab deserializes it and writes data past the end of the allocated heap buffer. No network interaction is required; the trigger is the file-open action.

3. Payload/execution method: At the vulnerability-class level, heap corruption can be used to overwrite adjacent heap objects or heap metadata. Depending on the platform's mitigations, an attacker may craft the file so that corrupted data leads to a controlled write primitive. If successful, this can redirect execution flow to attacker-supplied data or corrupt a pointer later used by the application. The attacker must arrange memory layout (spraying/arranging allocations) to make the corruption deterministic, which is a known challenge class for heap overflows. No public proof-of-concept exists, so any execution chain is inferred, not demonstrated.

4. Post-exploitation: A successful exploit executes code in the context of the DASYLab process (the logged-in user). This permits access to the user's files and credentials available to that account, installation of persistence, lateral movement within the same network segment, and manipulation or exfiltration of measurement data. In an OT/lab context, code execution on an engineering workstation has elevated significance because these systems frequently hold configuration data, credentials, and access to measurement networks. Where exploitation is not reliable, the fallback impact is application crash/denial of service and potential loss of unsaved measurement data.

Because no PoC, Nuclei template, or exploit code is publicly available, no specific exploitation reliability or weaponization claims can be made. The chain is inferred strictly from the vulnerability class and CVSS vector.

Impact Assessment

CVSS 7.8 (High) with vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. The local attack vector limits reach but not severity: once a user opens the file, no privileges or special conditions are required to trigger the flaw. The scope is unchanged (S:U), meaning the compromised component — the DASYLab process — remains the security authority affected; but the user-context code execution implies full compromise of the user's data and privileges within that context (C:H/I:H/A:H). The requirement for user interaction (UI:R) is the principal control that mitigates mass exploitation, and EPSS of 0.00158 (4.2% percentile) indicates low near-term exploitation probability. There is no CISA KEV listing and no known threat actor campaign.

Blast radius: The vulnerability is confined to systems where DASYLab is installed and where a user opens an untrusted .DSB file. However, the business impact can be disproportionate for organizations that run DASYLab on engineering workstations with access to internal networks, proprietary test data, or OT/serial instrumentation. Compromise of such a workstation can expose credential material and measurement data, threaten the integrity of test results, and offer a foothold for lateral movement from a position that is often less monitored than standard IT endpoints. Confidentiality, integrity, and availability are all rated High.

Detection Guidance

Detection of this vulnerability is challenging because the trigger is a local file open, not network traffic. Defensive coverage should emphasize file-creation telemetry, endpoint process behavior, and monitoring of DASYLab workspaces for unexpected crashes (a common side effect of heap corruption).

Sigma Rule

title: DASYLab Crafted .DSB File Heap Overflow Attempt
id: 6f4a1b2c-3d5e-4f6a-8b9c-0d1e2f3a4b5c
status: experimental
description: Detects user-space execution context where a DASYLab process opens a .DSB file from a non-standard/untrusted location, consistent with CVE-2026-64196 file-open exploitation vector.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-64196
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1203
  - cve.2026.64196
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\dasylab.exe'
      - '\DASYLab.exe'
  selection_cmd:
    CommandLine|contains:
      - '.dsb'
      - '.DSB'
  selection_path:
    CommandLine|contains:
      - '\Downloads\'
      - '\Temp\'
      - '\AppData\Local\Temp\'
      - '\Users\Public\'
  condition: selection_img and selection_cmd and selection_path
falsepositives:
  - Legitimate engineering workflows opening .DSB from Downloads or Temp
level: medium

YARA Rule

rule CVE_2026_64196_DASYLab_DSB_HeapOverflow
{
    meta:
        description = "Heuristic detection of suspicious .DSB documents potentially crafted for CVE-2026-64196 (DASYLab out-of-bounds write)"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-64196"
        cve = "CVE-2026-64196"

    strings:
        $magic1 = "DASYLab" ascii wide nocase
        $magic2 = ".DSB" ascii wide nocase
        // Embedded oversized length/size fields preceding large data streams.
        // Heuristic: 32-bit little-endian values >= 0x7FFFFFF0 within the document.
        $oversize = { F0 FF FF 7F }
        $oversize2 = { F8 FF FF 7F }

    condition:
        filesize < 64MB and
        ($magic1 or $magic2) and
        any of ($oversize*)
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2026-64196 Potential DASYLab .DSB File Transfer (Exploit Delivery)"; flow:established,to_server; content:".dsb"; nocase; http.header; sid:2026064196; rev:1; classtype:attempted-user; reference:cve,2026-64196; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-64196; metadata:service http, file-transfer;)

Elastic Detection

process where process.name in ("DASYLab.exe", "dasylab.exe") and
  process.command_line like~ "*.dsb*" and
  process.command_line like~ ("*\\Downloads\\*", "*\\Temp\\*", "*\\AppData\\Local\\Temp\\*", "*\\Users\\Public\\*")

Splunk SPL Query

index=endpoint sourcetype=WinEventLog:Security OR sourcetype=Sysmon:ProcessCreation
| eval proc=lower(process_name)
| where proc IN ("dasylab.exe")
| search command_line="*.dsb*"
| search (command_line="*\\Temp\\*" OR command_line="*\\Downloads\\*" OR command_line="*\\Users\\Public\\*" OR command_line="*AppData\\Local\\Temp*")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by host, user, process_name, command_line
| where count >= 1
| sort - last_seen

Wazuh OSSEC Rule

<group name="windows,dasylab,cve-2026-64196,">
  <rule id="100196" level="10">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.image">DASYLab\.exe$</field>
    <field name="win.eventdata.commandLine">\.dsb</field>
    <field name="win.eventdata.commandLine">(\\Temp\\|\\Downloads\\|\\Users\\Public\\)</field>
    <description>CVE-2026-64196: DASYLab opened a .DSB file from an untrusted location - possible crafted-file exploitation attempt.</description>
    <mitre>
      <id>T1203</id>
    </mitre>
    <group>cve_2026_64196,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch (not independently confirmed)).

1. Immediate mitigations (before upgrading): Restrict which users and systems can open .DSB files from untrusted sources. Implement email and web gateway rules to block or quarantine inbound .DSB attachments and downloads. Where feasible, inspect incoming .DSB files in a sandbox before distribution. Block or alert on execution of DASYLab when the command line references .DSB files outside expected project directories. Because the vulnerable behavior is triggered by user file-open action, user awareness training against opening unsolicited project files provides a meaningful control.

2. Patch/upgrade steps: NVD states the issue affects all versions before 2026.0.0, implying an upgrade to 2026.0.0 resolves it. Because the vendor fix is listed as N/A and patch confidence is only CLAIMED by a single source, verify the fix against the vendor's official release notes and download channel before relying on it. Confirm the installed build by checking the DASYLab "About" dialog or the installed binary version. After upgrading, validate that previously crafted test files no longer crash the application in a controlled QA environment.

3. Long-term hardening: Apply standard endpoint protection — DEP/ASLR enabled, exploit protection policies, and modern anti-malware with behavioral detection. Disable unnecessary file format handler associations. Limit local administrator rights on engineering workstations so that post-exploitation code executes with least privilege. Segment test/lab workstations from general IT networks and monitor them with the detection content above.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-64196
• MITRE CWE-787 (Out-of-bounds Write): https://cwe.mitre.org/data/definitions/787.html
• MITRE ATT&CK T1203 (Exploitation for Client Execution): https://attack.mitre.org/techniques/T1203/
• Vendor advisory: no Ni/National Instruments advisory URL provided in the source data; check the official DASYLab product/download page for version 2026.0.0 release notes and confirm patch status
• CISA KEV: not listed — no in-the-wild exploitation documented at time of writing; no known threat actor campaigns associated with this CVE