Siemens has released an urgent security update for NX after researchers discovered a cluster of high‑severity file‑parsing vulnerabilities in the way the product reads CGM (Computer Graphics Metafile) files; the flaws—tracked as CVE‑2026‑22923, CVE‑2026‑22924 and CVE‑2026‑22925—can cause application crashes and, in the worst case,
allow arbitrary code execution when a user opens a malicious CGM file. Siemens has published a fixed build (update to
NX V2512 or later) and is urging customers to apply the update immediately. This advisory affects engineering workstations and isolated design environments worldwide and should be treated as a high operational priority for teams that handle CAD/CAM assets, vendor files, and shared product data.
Background / Overview
NX is Siemens’ flagship CAD/CAM/CAE suite used across product engineering, simulation, and manufacturing pipelines. It is widely deployed in critical manufacturing, aerospace, automotive, and industrial design environments where design fidelity and toolchain continuity are essential. Because NX routinely exchanges files with partners, suppliers and vendors—often in a variety of legacy and industry formats such as CGM—any parsing bug that can be triggered by crafted files poses a direct threat to both intellectual property and operational resilience.
The newly disclosed defects center on
CGM file parsing—an old, moderately complex vector/graphics format still used in some engineering interchange workflows. Siemens’ advisory makes clear that the affected NX releases prior to
V2512 are vulnerable. The three CVEs cover a stack‑based buffer overflow (CWE‑121) and two out‑of‑bounds read conditions (CWE‑125), each assigned a CVSS v3.1 base score of
7.8 (High). Siemens credits an external reporter for coordinated disclosure and has published remediation guidance along with the fixed release.
What the vulnerabilities are (technical summary)
- CVE‑2026‑22923 — Stack‑based buffer overflow in NX’s CGM parsing code. A malicious CGM can overrun a stack buffer during parsing, enabling an attacker to alter the control flow of the NX process and potentially execute arbitrary code in the context of the logged‑in user running NX.
- CVE‑2026‑22924 — Out‑of‑bounds read while parsing CGM content. An attacker can craft fields inside a CGM file that cause the parser to read memory beyond intended bounds; that condition can be manipulated to crash the application or, depending on the memory layout and subsequent operations, be leveraged for code execution.
- CVE‑2026‑22925 — Another out‑of‑bounds read triggered by different malformed CGM constructs. Like the previous one, it can lead to crashes or escalate into an execution primitive when combined with other memory errors.
Common characteristics across the trio:
- Trigger: Opening or importing a specially crafted CGM file in NX.
- Attack surface: Local user action—an attacker must convince a user to open or import a malicious file, or insert such a file into a shared storage location that a user will naturally load.
- Impact: Crash (availability) or arbitrary code execution under the privileges of the NX process (confidentiality and integrity risks).
- Difficulty: Requires user interaction or placement of a malicious file in an environment where a user will open it, but no special authentication is required beyond normal access to the workstation or file share.
These are classic parsing bugs that arise when binary or structured file input is processed by code written in memory‑unsafe languages (typically C/C++) without sufficient bounds checks and robust sanitization.
Why CGM parsing remains a recurring hazard
CGM is a decades‑old graphics interchange format used in some engineering and technical graphics workflows. Two factors make it a persistent risk:
- Format complexity and legacy parsers: CGM supports multiple encodings, element types, and optional features. Legacy parsers often include code paths written for backward compatibility; those paths can hide subtle assumptions about sizes, element lengths, or nested constructs—perfect targets for memory boundary violations.
- Trust model for engineering files: Engineering teams routinely exchange design artifacts from partners, contractors and suppliers. That trust model—open and collaborative—means malicious files can cross organizational boundaries through email, project repositories, or external media. Unlike common office formats, specialized CAD viewers and plugins are sometimes not as aggressively scanned, and many security products treat CAD files as low‑risk by default.
The combination of these two realities makes
file parsing a high‑value attack vector for threat actors aiming to infiltrate engineering networks or exfiltrate sensitive IP.
Realistic attack scenarios and risk to organizations
- Targeted spearphishing against engineers: An adversary crafts an ostensibly legitimate CGM (for example, a vendor part drawing) and sends it to an engineer by email or places it in a shared project folder. When the engineer opens the file in NX, the exploit triggers, giving the attacker code execution on that workstation.
- Supply‑chain poisoning: A supplier’s CAD archive or a widely used partner dataset is compromised and seeded with malicious CGM files. Downstream consumers who trust and import the packages into NX may inadvertently execute malicious payloads.
- Lateral movement inside segmented networks: Once an attacker gains a foothold on a design workstation, they can pivot—abusing engineering access, build servers, or manufacturing planning systems that are sometimes weakly segmented from OT assets.
- Persistence and IP theft: Code execution enables installation of backdoors, exfiltration of design files (CAD models, BOMs), and tampering with simulation or manufacturing outputs—potentially causing defective parts or revealing trade secrets.
Although the CVSS vector indicates the vulnerability is
local (AV:L), the reality in enterprise and industrial deployments is that many systems are reachable through VPNs, remote maintenance connections, or file shares. That effectively raises the operational risk and urgency.
Timeline and vendor coordination
- Discovery and disclosure: The issues were reported to Siemens ProductCERT via coordinated disclosure (the advisory lists the researcher acknowledged for reporting).
- Vendor response: Siemens published a security advisory addressing the issues and released updates that fix the vulnerabilities in NX V2512 and later builds. Siemens’ advisory also provides mitigations and recommendations for customers who cannot immediately patch.
- Public dissemination: National authorities and third‑party vulnerability trackers have mirrored the vendor advisory and catalogued the CVEs, giving organizations multiple channels to learn about the issue.
The coordinated disclosure and timely vendor response are positive signs: the vendor produced a patch and communicated remediation guidance. At the same time, the availability of advisories on public feeds means defenders should assume exploits may appear in the wild quickly, and they must prioritize patching and mitigations accordingly.
Practical remediation: immediate actions (what you should do now)
- Update: Plan and deploy NX V2512 or later across your environment as soon as your change control/testing process allows. Prioritize systems that:
- Are internet‑reachable or reachable over VPN.
- Receive files from third parties or external suppliers.
- Perform downstream manufacturing processes or feed OT networks.
- If you cannot patch immediately, use temporary compensations:
- Do not open untrusted CGM files. Enforce a policy: treat all incoming CGM files as untrusted until scanned/validated.
- Block CGM file attachments at mail gateways and cloud file ingestion points, or route them for manual, sandboxed inspection.
- Disable or restrict any automatic preview handlers that render CGM contents inside mail clients, file managers, or collaboration platforms.
- Restrict write/drop permissions to shared engineering folders—minimize the set of users/services that can write files into central project repos.
- Enforce application allow‑listing and least privilege on engineer workstations: NX should run with the minimum privileges necessary.
- Network segmentation and access controls:
- Isolate engineering workstations from the corporate/business network and, critically, from direct access to OT networks.
- Limit vendor and remote maintenance channels to jump hosts and hardened bastion servers with MFA and just‑in‑time access.
- Detection and monitoring:
- Add detection rules that flag unexpected NX process crashes, repeated crashes after opening files, or suspicious child processes spawned by NX.
- Collect and centralize application logs from engineering workstations and analyze for anomalous behavior after file imports (unusual network connections, elevated process activity, or new persistence mechanisms).
- If using Endpoint Detection & Response (EDR), deploy coverage rules that can detect attempts to exploit memory corruption and suspicious memory protections being disabled.
- Incident response prep:
- Prepare playbooks for suspected NX compromise: isolate the host, collect memory and disk images, preserve the potentially malicious CGM file, and report the incident to internal CERT and vendor ProductCERT channels.
- Notify supplier and partner security teams if a shared dataset may have been the distribution vector.
Patch management and release testing recommendations
Applying updates to engineering tools requires care—compatibility with custom toolchains, plugins, and automation scripts must be verified. Follow these steps:
- Test the update in a representative lab with real project data and third‑party plugins to detect regressions early.
- Validate that NX V2512 integrates cleanly with downstream simulation and CAM systems and that output jobs (postprocessors, NC code) remain unchanged.
- Stage the rollout: pilot group → extended pilot → full production.
- Maintain a rollback plan with backups of critical project files and an instrumented environment where you can quickly detect issues.
- Communicate change windows and risk to engineering teams—encourage reporting of anomalies during and after patch windows.
Detection and hunting guidance for SOCs
- Look for new NX process crashes correlated with user file open events. Frequent crashes tied to CGM imports are a red flag.
- Monitor for suspicious child processes spawned by NX—in particular, unexpected command interpreters, network utilities or cryptominers launched shortly after a crash.
- Search EDR telemetry for previously unseen persistence mechanisms created by users who opened CGM files.
- On endpoint forensics, collect crash dumps from the NX process; memory analysis can reveal exploit chains or payloads loaded during the parsing stage.
- Hunt for lateral movement signatures from engineering workstations, such as abnormal SMB activity, PowerShell remote execution, RDP sessions to other critical hosts, or unusual account usage.
Why organizations should prioritize engineering tooling like NX
Engineering tools are not just productivity software; they are repositories of proprietary designs, simulation models, and manufacturing instructions. Compromise of a CAD/CAE workstation can lead to:
- Theft of intellectual property (design specifications, CAD models).
- Insertion of subtle design changes that break parts in production.
- Delays and cost overruns while investigations and rebuilds occur.
- Loss of customer and regulatory trust in industries bound by safety and traceability.
Given these stakes, engineering tooling should be treated like any other critical enterprise application in terms of patch cadence, logging, network isolation, and vulnerability management.
Vendor response: strengths and open questions
Strengths:
- Siemens produced a patch (NX V2512) and published advisory guidance quickly after coordinated disclosure.
- The advisory includes CVE identifiers, vulnerability classifications (CWE), and recommended mitigations—helpful for triage and risk scoring.
Open or concerning points:
- The attack vector is local file opening, which is often thought of as lower priority than remote, network‑facing bugs—but in practice the risks are magnified by collaboration workflows and remote access channels.
- Organizations may need more prescriptive detection signatures or YARA rules for known malicious CGM patterns; defenders should press vendors for sample indicators or test artifacts in a controlled manner.
- Some engineering environments require extended validation cycles; vendors should provide backport or long‑term support builds for customers who cannot immediately move to the latest major release.
Overall, Siemens’ handling is positive, but defenders must remember that a vendor patch is only the first step—organizational controls and rapid patch deployment are required to close the operational window of exposure.
Longer‑term strategic recommendations
- Minimize attack surface around file parsing:
- Implement safe previewing and sandboxing for any untrusted CAD/CAM files. Move file rendering into isolated virtual machines or containers with strict microsegmentation.
- Use content disarm and reconstruction (CDR) for CAD assets where feasible—strip nonessential embedded content and reconstitute sanitized versions for review.
- Move towards memory‑safe components where possible:
- Encourage vendors and third‑party library maintainers to adopt memory‑safe parsing libraries or languages for file handling code paths (e.g., Rust for new implementations or well‑audited C libraries with hardened checks).
- Supply‑chain hygiene:
- Treat incoming CAD packages as high‑impact artifacts. Use signed archives, validate digital signatures on third‑party tool outputs, and maintain provenance metadata for supplier assets.
- Enforce stricter access controls on shared project repositories and use checksums/digests to detect unauthorized changes.
- Improve telemetry and cooperation:
- Vendors should provide exploit indicators, sanitized sample files for testing, and detection guidance to help SOCs tune detection rules.
- Industry groups should coordinate to publish common IOCs and defensive playbooks for CAD/CAE attack vectors.
Practical hardening checklist (prioritized)
- Apply NX V2512 across production and pilot groups as a priority.
- Block or quarantine incoming CGM attachments until scanned and validated.
- Disable automatic file previews in mail clients and file browsers on engineering workstations.
- Enable EDR policies that flag and block exploit‑like behavior from NX processes.
- Segment engineering networks from business and OT networks; restrict jump hosts and vendor VPNs.
- Instrument crash‑dump collection for NX to speed incident triage.
- Implement least‑privilege execution for user accounts running NX.
- Test patches thoroughly in a lab environment with real toolchains and plugins.
- Review supplier file transfer policies and require digital signing where possible.
- Prepare an incident response playbook specifically for CAD/CAE tool compromise.
Closing assessment
The NX CGM parsing vulnerabilities are a reminder that even specialized engineering tools and legacy file formats remain attractive targets for attackers. The technical severity—stack overflows and out‑of‑bounds reads—carries real exploitation potential when combined with social engineering or supply‑chain distribution. Siemens’ release of
NX V2512 provides a concrete remediation path; organizations must now move quickly to patch, harden workflows, and monitor engineering endpoints for suspicious behavior.
Treat this advisory as a high, actionable priority: patch where possible, apply compensating controls where immediate patching is impractical, and update detection capabilities to spot exploitation attempts. Engineering workstations are gateways to valuable intellectual property and sometimes to downstream manufacturing systems—protecting them requires the same diligence and operational discipline we apply to any other critical enterprise asset.
Source: CISA
Siemens NX | CISA