Ashlar‑Vellum’s Cobalt family and related products were disclosed as containing multiple high‑impact memory‑safety vulnerabilities that can lead to information disclosure and arbitrary code execution; operators must treat these defects as urgent and update to vendor‑supplied builds or apply strong compensating controls immediately.
Ashlar‑Vellum’s 3D and CAD product line — notably Cobalt, Xenon, Argon, Lithium, and Cobalt Share — parses a variety of proprietary file formats (CO, XE, AR, VC6, LI and similar). Multiple coordinated advisories published in 2025 document memory‑corruption bugs in these parsers: out‑of‑bounds write, out‑of‑bounds read, and heap‑based buffer overflow conditions that arise when crafted files are processed. These flaws carry high severity and were assigned multiple CVE identifiers by trackers and national databases; vendors and ICS authorities have published mitigation guidance. The immediate takeaways:
The coordinated advisory and the vendor updates create a clear remediation path; nonetheless, defenders must act deliberately: verify installed build strings, test vendor patches in lab images that reflect operational add‑ins, and apply layered mitigations during windows where patching cannot be immediately completed.
Source: CISA Ashlar-Vellum Cobalt, Xenon, Argon, Lithium, Cobalt Share | CISA
Background / Overview
Ashlar‑Vellum’s 3D and CAD product line — notably Cobalt, Xenon, Argon, Lithium, and Cobalt Share — parses a variety of proprietary file formats (CO, XE, AR, VC6, LI and similar). Multiple coordinated advisories published in 2025 document memory‑corruption bugs in these parsers: out‑of‑bounds write, out‑of‑bounds read, and heap‑based buffer overflow conditions that arise when crafted files are processed. These flaws carry high severity and were assigned multiple CVE identifiers by trackers and national databases; vendors and ICS authorities have published mitigation guidance. The immediate takeaways:- The vulnerabilities are local in attack vector but have low attack complexity and high impact scores, meaning a crafted file opened by a user or processed by an exposed system can yield code execution or data leakage.
- CISA and major CVE aggregators recommend updating affected products to the version line identified as fixed by Ashlar‑Vellum and to follow ICS/OT defensive best practices.
What’s affected and how severe it is
Affected products and versions
- Affected: Cobalt, Xenon, Argon, Lithium, Cobalt Share (multiple builds prior to the fixed build identified by the vendor). Vendor and CISA mapping identify versions prior to the vendor’s fixed 12.6.1204.204 release as vulnerable; vendors recommend upgrading to the patched 12.6.1204.204 or later.
Vulnerability classes and CVE scoring
- Primary bug types disclosed:
- Out‑of‑bounds write (CWE‑787) — can corrupt memory and lead to code execution.
- Out‑of‑bounds read (CWE‑125) — can leak memory contents (sensitive information).
- Heap‑based buffer overflow (CWE‑122) — classic memory‑corruption vector that often enables reliable code execution when exploited.
- Scores reported by CISA and CVE trackers:
- CVSS v3.1 base scores ≈ 7.8 (High).
- CVSS v4 base scores ≈ 8.4 (High).
These derive from the combination of local attack vector (AV:L), low complexity (AC:L), user interaction required (UI:R), and high confidentiality/integrity/availability impact.
Exploitability and current status
- The public advisories characterise the attack vector as local and requiring some user interaction (for example, opening a malicious file or a preview), which reduces wormability but does not eliminate real‑world risk because engineering and design workstations commonly exchange files with contractors, suppliers, and customers.
- At time of public disclosure, CISA reported no known public exploitation specifically targeting these vulnerabilities — but the advisory stresses that absence of observed exploitation is not a reason to delay mitigation.
Technical breakdown: how these bugs work (engineers’ view)
File parsing and memory safety
Ashlar‑Vellum’s software ingests complex binary/project file formats that contain nested records, length fields and compressed/packed data structures. The disclosed defects arise where the parsing code fails to validate lengths or buffer boundaries before copying or indexing data. The result is predictable memory corruption patterns:- Out‑of‑bounds reads occur when the parser reads past an allocated buffer, exposing memory contents to an attacker-controlled processing path and enabling information disclosure.
- Out‑of‑bounds writes and heap overflows occur when the parser writes beyond allocated buffers (stack or heap), corrupting adjacent memory structures, heap metadata or control data — a classic path to hijacking execution flow and achieving arbitrary code execution in the context of the process that performed parsing.
Preconditions and exploitation model
- User interaction required: A victim must typically open or import a crafted CO/XE/AR/VC6/LI file or preview it in a vulnerable context. This makes social‑engineering and file distribution (email, shared drives, toolchain imports) the primary delivery paths.
- Local vector, high impact: Even though the attack is local (AV:L), engineering and CAD workstations are high‑value targets: successful code execution on such hosts often yields credentials, project IP, or privileged connections to control systems. Attackers can leverage compromised workstations to pivot into OT/PLC environments or to exfiltrate sensitive designs.
- Variable reliability across environments: Modern Windows exploit mitigations (ASLR, DEP/CFG, stack‑canaries) can make reliable exploitation harder — but many industrial environments run long‑lived images or unpatched OS/toolchains where exploitability is easier.
Who should care most — practical exposure mapping
- Engineering CAD stations and HPC/CAE hosts that install or open Ashlar‑Vellum project files.
- Shared repositories and intake servers (file servers, web apps, mail servers, document preview services) that accept or process these file types — server‑side processing can transform a “local” bug into an escalation with broader reach if the server parses files without sandboxing.
- Contractor‑heavy workflows where unvetted files flow between third parties and internal engineering teams.
- Mixed IT/OT environments where engineering workstations have direct or poorly segmented access to OT controllers, HMIs or configuration push mechanisms.
Vendor and authority guidance (what to apply right now)
Official remediation
- Apply the vendor update: Ashlar‑Vellum and CISA map the fixed release for the reported issues to builds in the 12.6.1204.204+ line (vendors instruct users to update to that build or later via Help → Check Web for Updates or the vendor download site). Always confirm the exact build string and SHA‑256 before deploying.
Immediate operational mitigations (if you cannot patch instantly)
- Stop opening untrusted files: Enforce a temporary policy that engineering workstations must not open project files from unknown or unvetted sources. Quarantine, scan and validate any inbound project files first.
- Isolate engineering hosts: Move CAD/engineering systems to an isolated VLAN with strict firewall rules and no direct internet access. Use jump servers or bastion hosts for any remote maintenance.
- Harden file processing services: If any server or service accepts user‑supplied archives or project files, sandbox parsing, drop privileges, and scan inputs with multiple engines. Consider offline or staged ingestion workflows.
- Endpoint controls: Enforce application allow‑listing for engineering stations, enable EDR with memory‑protection detections, and tune alerts for anomalous process actions (unexpected child processes, in‑memory code injection patterns).
Step‑by‑step remediation checklist for Windows admins (prioritized)
- Inventory: Identify all endpoints with Ashlar‑Vellum installations (Cobalt, Xenon, Argon, Lithium, Cobalt Share). Capture version strings and build numbers.
- Validate vendor guidance: Verify the exact patched build that the vendor lists (12.6.1204.204+ per the advisory) before scheduling updates.
- Test the patch: Install the vendor update on a test image (including third‑party add‑ins) and confirm functionality and compatibility.
- Schedule roll‑out with change control: Apply the update in your production maintenance windows, and retain rollback images.
- Implement compensating controls prior to patching: isolate hosts, block file type attachments via mail gateway, and route file transfers through a document sanitization pipeline.
- Monitor and hunt: Deploy EDR detections and SIEM rules for indicators of compromise (unexpected process launches from CAD apps, network connections from engineering hosts to unknown endpoints).
- Train staff: Reiterate phishing and file‑handling policies to engineers and contractors who exchange project files frequently.
Recommended technical mitigations (detailed)
- Application allow‑listing: Prevent unsigned or unauthorised binaries and scripts from running on engineering hosts.
- Least privilege: Ensure users run CAD tools with non‑administrative accounts. Remove local admin rights from routine engineering users where possible.
- Network segmentation: Enforce strict segmentation between engineering VLANs, corporate IT, and OT, with monitored jump boxes for necessary cross‑segment management.
- File handling hygiene:
- Block or quarantine CO/XE/AR/VC6/LI file types at mail gateways and entry points.
- Route file uploads to an isolated analysis host before exposing them to production engineering stations.
- Endpoint protections: Use EDR tools with memory‑corruption heuristics and enable OS protections like Control Flow Guard (CFG) and Data Execution Prevention (DEP).
- Backups and change control: Maintain offline backups of engineering projects and ensure processes for signing and validating supplier files.
Risk analysis and operational impact
Strengths of the disclosure and vendor response
- The advisory is coordinated and documented by CISA and multiple vulnerability trackers, giving defenders an authoritative picture of affected builds and the remediation path. This reduces guesswork for patch managers and provides consistent scoring and impact framing.
Notable risks and caveats
- Although the attack vector is classified as local and requiring user action, the routine workflows in engineering environments (file sharing, vendor exchanges, contractor submissions) make successful delivery plausible and frequent. A single compromised engineer endpoint can be an effective pivot into OT assets.
- Public exploit code often appears quickly following disclosure of memory‑corruption bugs; the initial absence of known exploitation does not guarantee safety. Treat “no observed exploitation” as time‑sensitive intelligence, not a comfort.
- Vendor and third‑party advisories have occasionally used differing CVE numbers or fixed‑build identifiers across different disclosure waves; defenders must rely on the vendor’s current published build string and the official CISA advisory for authoritative direction. Where your internal inventory reports a different build number than the advisory, verify directly with vendor support before patching at scale.
Cross‑verification and sources used for this analysis
Key public references used to cross‑check technical details, versioning and remediation guidance include:- The official CISA ICS advisory for Ashlar‑Vellum, which lists the affected products, the vulnerability classes, CVSS metrics and the fixed version guidance.
- Industry CVE trackers and vulnerability databases (Tenable, CVE aggregators, OpenCVE / CIRCL) that mirror CISA’s mapping and provide vendor‑level remediation details including build numbers and recommended update procedures.
Practical example: a hardened remediation playbook (concise)
- Run a query across your asset database for installed Ashlar‑Vellum products and record build strings.
- If any host reports a build < 12.6.1204.204, mark it as high priority for patch testing.
- Block inbound mail attachments with CO/XE/AR/VC6/LI extensions; require all such file deliveries to use a vetted repository.
- Set a 72‑hour emergency maintenance window to deploy and validate the vendor patch on representative engineering hosts.
- After patching, perform focused EDR hunts for pre‑disclosure indicators (suspicious document opens, anomalous child processes launched by CAD apps).
- Document and enforce new file‑handling controls for contractor exchanges (quarantine + scanning + explicit approval).
Final assessment and recommended priorities
- Priority 1 (Immediate): Confirm exposure — inventory and isolate vulnerable hosts. If you cannot patch within 72 hours, apply network/operational compensations (isolate, quarantine file intake, block attachments).
- Priority 2 (Short term): Test and deploy vendor‑supplied update (12.6.1204.204 or later as identified in the vendor/CISA advisory) across engineering workstations and servers that process design files.
- Priority 3 (Medium term): Harden file‑ingestion pipelines, enforce least privilege, and add detection recipes to EDR/SIEM for memory‑corruption indicators and post‑exploit behaviors.
The coordinated advisory and the vendor updates create a clear remediation path; nonetheless, defenders must act deliberately: verify installed build strings, test vendor patches in lab images that reflect operational add‑ins, and apply layered mitigations during windows where patching cannot be immediately completed.
Source: CISA Ashlar-Vellum Cobalt, Xenon, Argon, Lithium, Cobalt Share | CISA
