Delta Electronics’ CNCSoft‑G2 has a newly disclosed file‑parsing vulnerability that allows a maliciously crafted project file to trigger an
out‑of‑bounds write in the DPAX parser — a flaw that can lead to remote code execution in the context of the running process if a user opens the file. Operators should treat this as an urgent remediation item: Delta has released an update to
CNCSoft‑G2 v2.1.0.39 to address the issue, and multiple independent vulnerability trackers have assigned the problem the identifier
CVE‑2026‑3094 and a CVSS v3.1 score of
7.8 (High).
Background
CNCSoft‑G2 is Delta Electronics’ Windows‑based engineering and HMI software used to design and operate CNC and industrial automation systems. Historically, the product family has been the subject of multiple coordinated disclosures addressing file‑parsing and buffer‑validation issues in the DPAX and DOPSoft components, and vendors and national authorities (including CISA) have republished advisories for prior CVEs in this product line. Those past disclosures set the stage for the current finding: file formats used by engineering/automation tools are a recurring attack surface in industrial environments because they are often exchanged informally between engineering teams, vendors, and system integrators.
The newly publicized flaw, tracked as CVE‑2026‑3094 by vulnerability databases, is described as an
out‑of‑bounds write triggered while parsing DPAX files. The practical consequence of such a memory corruption bug is that an attacker who can get an engineer or operator to open a crafted DPAX file could corrupt program memory in a way that leads to arbitrary code execution under the privileges of the running CNCSoft‑G2 process. The vulnerability requires user interaction — specifically, opening a file — but does not require elevated privileges beyond the process context.
What the advisory says (high‑level)
- The vulnerability is an Out‑of‑Bounds Write in the DPAX file parser inside the DOPSoft component of CNCSoft‑G2.
- Affected CNCSoft‑G2 builds are those prior to v2.1.0.39; the vendor recommends upgrading to v2.1.0.39 which Delta lists as the fix.
- The flaw is assigned CVE‑2026‑3094 and carries a CVSS v3.1 base score of 7.8, with the CVSS vector indicating local attack complexity, low attack complexity, user interaction required, and high confidentiality/integrity impact if exploited.
- The vulnerability was reported to vendors and national authorities under coordinated disclosure channels; multiple vulnerability databases and trackers reflect the public disclosure.
Technical analysis — what the vulnerability is and why it matters
How out‑of‑bounds writes in file parsers lead to code execution
File‑parsing code frequently performs byte‑level operations: reading lengths, indexing arrays, copying blocks of data into fixed buffers, and interpreting nested structures. When such code
fails to validate length fields or index values, a malformed or malicious file can cause memory writes outside the intended buffer bounds — a classic
CWE‑787 (Out‑of‑bounds write) condition.
An out‑of‑bounds write can:
- Overwrite adjacent heap or stack metadata, corrupting allocation structures and enabling manipulation of memory management routines.
- Overwrite function pointers, vtable entries, or other control‑flow data, allowing an attacker to redirect execution to attacker‑controlled memory.
- Cause predictable crashes that can be used to probe memory layout for an exploit chain.
When an HMI or engineering tool running on Windows processes a malicious DPAX file, those writes can be weaponized into a local remote‑code‑execution scenario — local because user interaction (opening the file) is required, but still
remote to the operational technology (OT) environment because supply‑chain or email vectors often deliver the malicious artifact. The CVSS vector for CVE‑2026‑3094 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) reflects this attack model.
Where the attack surface lives in real environments
- Engineering laptops and workstations that run CNCSoft‑G2 to author or preview DPAX project files.
- Shared file servers or network drives where project files are exchanged.
- USB drives and removable media used to migrate projects to production HMI/PLC hosts.
- Email and collaboration platforms used by engineers and integrators.
In most manufacturing environments, engineering workstations are not intentionally internet‑facing, but the real world shows ample opportunity for malicious files to traverse from corporate email, contractor submissions, or external partners into the OT engineering zone. A single opened file on a single engineering workstation can be enough to trigger an exploit. The historical pattern of file‑parsing bugs in CNCSoft‑G2 underlines the need for careful handling of exchanged project files.
Who reported it — attribution and verification
Public vulnerability trackers list CVE‑2026‑3094 and link to Delta’s advisory materials. Past disclosures in the CNCSoft‑G2 family were credited to researchers working with Trend Micro’s Zero Day Initiative (ZDI), with Natnael Samson (@NattiSamson) appearing as a credited reporter in earlier related advisories. ZDI advisories historically show Natnael Samson as a contributor to multiple DPAX/DOPSoft parsing findings, which provides context about researcher involvement in the product line. That historical attribution is archived across ZDI advisories and CISA republished advisories, although direct, explicit credit fublicly queryable sources is currently limited; therefore attribution specifics for
this CVE should be taken from official advisories where present and treated cautiously until vendor advisories confirm credit.
Note: When public materials disagree or lack explicit researcher credit for a given CVE, rely on the vendor advisory or CISA/certified advisory republishing for authoritative attribution. The Delta advisory (product cybersecurity advisory) that accompanies this disclosure is the authoritative vendor perspective and is referenced by multiple third‑party trackers.
Immediate risk assessment for operators
- Exploitability: The vulnerability requires user interaction (opening a crafted file). There are no public, verified reports of in‑the‑wild exploitation targeting CVE‑2026‑3094 at the time of this advisory’s republication, but that does not mean exploitation is impossible or unlikely — many file‑parsing flaws rapidly attract exploit development. Public trackers rate the vulnerability High (CVSS v3.1 = 7.8) due to the potential for arbitrary code execution.
- Impact scope: Any CNCSoft‑G2 instance used in critical manufacturing or energy sectors is high‑value. Successful exploitation can result in full process compromise of the software and potentially lateral movement if the compromised host has network access to engineering servers, file shares, or update mechanisms.
- Likelihood: Attackers commonly weaponize file formats that cross trust boundaries — for example, vendor‑supplied project files, contractor submissions, or emailed attachments. That common pattern increases the likelihood that an organization that routinely exchanges DPAX files could be targeted.
- Operational risk: Unpatched engineering workstations are likely to be physically present in both enterprise IT and OT contexts. A compromised engineering machine used to publish HMI projects could be used to manipulate production parameters or to push malicious project code into controllers.
In short: the vulnerability is high‑impact when triggered and relatively straightforward in attack model, making prompt remediation a priority for organizations running CNCSoft‑G2 inside critical manufacturing environments.
Delta’s fix and vendor guidance
Delta Electronics’ published response indicates that
v2.1.0.39 contains the remediation for the DPAX file parser out‑of‑bounds write. Delta recommends users update to that version to close CVE‑2026‑3094. Several vulnerability trackers and aggregated CVE pages list the vendor advisory PDF as the canonical fix document for this CVE. Operators should obtain the vendor update via Delta’s official download channel and follow Delta’s upgrade instructions and change logs when applying the patch to avoid introducing operational regressions.
Practical notes on vendor updates:
- Always apply the vendor‑supplied update to a representative test workstation in your engineering environment first. Validate that previously used DPAX projects still load and that automation workflows are not broken by the patch.
- Where vendor updates require service restarts or require re‑registration/activation, schedule the update during maintenance windows to avoid production disruption.
- Keep backups of current projects and system configurations prior to applying the vendor update.
If organizations cannot apply the vendor update immediately, Delta and national authorities recommend mitigations that reduce exposure until patching is possible. These mitigations should be treated as temporary compensating controls.
Recommended mitigations and hardening (short‑term and long‑term)
The standard defense‑in‑depth approach applies here; prioritize full patching, then add compensating controls and detection improvements.
Short‑term (urgent, immediate):
- Update CNCSoft‑G2 to v2.1.0.39 as soon as feasible. Validate the update in a test environment before mass deployment.
- Block external/untrusted DPAX files from reaching engineering machines:
- Restrict file shares and apply strict ACLs.
- Disable automatic opening/previewing of DPAX/DOPSoft project files within email clients and file explorers.
- Enforce the principle of least privilege on engineering workstations: run CNCSoft‑G2 under non‑admin accounts where possible, and limit local write access to application folders.
- Use endpoint protection with behavioral detection to monitor for anomalous process behavior from CNCSoft‑G2 (unexpected network connections, child‑process creation, or suspicious memory activity).
Medium‑term (operational controls):
- Segment engineering networks from business and internet‑connected networks. Place engineering workstations behind an OT‑facing firewall and apply strict egress filtering.
- W formats and sources for engineering tools via content‑filtering gateways or secure file transfer appliances.
- Require signed verification for third‑party project files or vendor updates where feasible.
Long‑term (strategic):
- Implement controlled, documented inbound file‑exchange processes for project files (e.g., secure vendor portals, file integrity scanning, quarantine workflows).
- Adopt application control/allowlisting on critical engineering endpoints.
- Run periodic fuzzing and code audits on in‑house engineering file processors if you operate a development pipeline that creates or transforms DPAX files.
- Track and centralize vulnerability and patch management for OT software stacks (not just Windows and mainstream server software).
CISA’s general ICS recommendations — network segmentation, minimizing internet exposure, and using secure remote access (VPN with up‑to‑date systems) — are relevant and should be applied for CNCSoft‑G2 installations. Those guidance patterns complement the vendor fix.
Detection and incident response guidance
Detection is difficult for zero‑day memory corruption exploitation, but the following indicators and monitoring steps can improve situational awareness:
- Monitor CNCSoft‑G2 process behavior:
- Unexpected child processes spawned by the CNCSoft‑G2 process.
- Unusual DLL loads or new modules loaded into the process at runtime.
- Process crashes or repeated application exceptions following file open events.
- File‑system monitoring:
- Unusual DPAX files appearing on engineering workstations or shared repositories, especially from new or external accounts.
- Changes to critical project files or mass‑file modifications outside change control windows.
- Network logs:
- Outbound connections from engineering hosts to unknown or suspicious destinations.
- Transfers of DPAX files to external endpoints.
If you suspect exploitation:
- Isolate the suspected host from the network (preserve evidence).
- Collect full memory and disk images for forensic analysis (preserve chain of custody).
- Review recent DPAX files opened on the machine and scan them with updated vendor scanning tools and generic file‑inspection tools.
- Apply the Delta patch to a clean host and replicate the suspected file open in a controlled sandbox for analysis.
- Report confirmed incidents through your internal incident response procedures and to national CERT/CISA as appropriate.
Because file‑parsing exploitation can be subtle and may not leave overt telemetry, organizations with high assurance needs should consider external forensic support when a compromise is suspected.
Operational impact scenarios — realistic attack chains
Below are three plausible, realistic scenarios that illustrate how CVE‑2026‑3094 could be leveraged in an adversary campaign:
- Scenario A: Vendor compromise delivery — An adversary compromises a vendor’s project repository and places a crafted DPAX file that, when opened by a downstream integrator, executes code that implants a persistent backdoor on an engineering workstation. From there, the adversary harvests credentials and pushes manipulated HMI projects to production controllers.
- Scenario B: Targeted spear‑phishing — A tailored spear‑phishing email to an engineer includes a seemingly legitimate project file. The engineer opens the file to review changes; the exploit executes and the attacker gains a foothold in the engineering network, then moves laterally to PLC management systems.
- Scenario C: Supply chain tampering — A malicious update package traded between subcontractors includes a DPAX file as part of a test harness. The file triggers the out‑of‑bounds write when imported, giving the adversary code execution in the context of CNCSoft‑G2 and allowing manipulation of project artifacts.
All three emphasize the
cross‑domain nature of risk: attackers use non‑network vectors (files) to cross trust boundaries between enterprise IT, vendor ecosystems, and OT engineering workstations. The mitigation strategy must thus span people, process, and technology.
Why this matters to Windows administrators and OT security teams
- CNCSoft‑G2 runs on Windows hosts that are often treated as special‑purpose, trusted engineering assets; Windows administrators must therefore ensure their asset inventories and patching processes include these OT‑adjacent applications.
- Traditional Windows patch programs that focus on servers and desktops frequently leave engineering tools on ad‑hoc update schedules; this vulnerability is a reminder to integrate OT application patching into centralized change management and EDR monitoring.
- Attackers who gain code execution on an engineering workstation can pivot to systems that control production, making this an enterprise‑level risk even though exploitation starts at a single Windows application.
For Windows‑focused IT teams, the practical actions are straightforwt‑G2 installations, validate version numbers, test the v2.1.0.39 update, and deploy according to change-control. For OT teams, coordinate with IT to ensure segmentation and file handling controls are in place.
Validation and verification: what we cross‑checked
To ensure the technical claims in this article are accurate, we cross‑referenced multiple independent sources:
- CVE aggregators and vulnerability pages list CVE‑2026‑3094 with a CVSS v3.1 score of 7.8, and reference Delta’s advisory materials for remediation.
- Public feeds and vulnerability trackers mirror the CVE details and advise patching to the vendor’s fixed version v2.1.0.39.
- Historical ZDI advisories and vendor advisories show a pattern of DPAX/DOPSoft file‑parsing vulnerabilities in CNCSoft‑G2 and list credited researchers (for prior CVEs), which helped confirm the recurring nature of this class of bug in the product family. Researcher credit for this CVE should be confirmed via the vendor advisory or CISA advisory when available.
Where public sources did not explicitly confirm a specific attribution or the presence of active exploitation in the wild, the article flags those items as
not verified rather than stating them as fact.
Practical checklist — action items for administrators (immediately and next 7 days)
- Inventory: Find all machines running CNCSoft‑G2 and record current versions.
- Test: Download the vendor update (v2.1.0.39) into a controlled test lab and validate project file compatibility.
- Patch: Roll out v2.1.0.39 on production engineering systems during approved maintenance windows.
- Block: Restrict external DPAX file ingestion channels and disable file preview for incoming DPAX files.
- Monitor: Add detection rules for suspicious CNCSoft‑G2 process behavior and enable memory/process monitoring.
- Educate: Remind engineers to treat project files from external parties as untrusted; require validation and scanning before opening.
- Report: If anomalous behavior or suspected exploitation is observed, follow incident response playbooks and notify national CERT/CISA per organizational procedures.
Broader lessons for industrial software security
- File formats are hazardous. Any component that parses external files is a potential injection point for memory corruption; vendors and customers must treat file parsers as first‑class security concerns.
- Coordinate patching across IT and OT. Patching windows, testing procedures, and rollback plans are essential when critical engineering tools are involved.
- Reduce implicit trust. Engineering workflows often assume files from vendors or pt trust must be augmented with integrity checks, quarantines, and verification processes.
- Treat researcher reports as operational signals. Multiple independent disclosures in CNCSoft‑G2 show that the product family has had recurring parser‑related flaws. This pattern matters when deciding how aggressively to enforce compensating controls or to accelerate migration away from legacy components.
Conclusion
CVE‑2026‑3094 is a high‑impact, high‑urgency vulnerability in a widely used industrial engineering product. While the attack requires user interaction, ordinary engineering workflows make that
practical for real adversaries. Delta’s update to
CNCSoft‑G2 v2.1.0.39 is the authoritative remediation; organizations should prioritize patch testing and deployment, apply layered mitigations to limit file exposure, and harden engineering endpoints with detection and segmentation. The recurring nature of file‑parsing flaws in this product family also underscores the need for sustained operational changes: stricter file handling policies, centralized patch governance for OT applications, and increased collaboration between IT and OT security teams. Treat this disclosure as a timely reminder that
trusted engineering artifacts can be weaponized, and that robust, cross‑domain defenses are the best guardrails for modern industrial operations.
Source: CISA
Delta Electronics CNCSoft-G2 | CISA