Urgent Patch: AADvance SIS Workstation CVE-2024-48510

Rockwell Automation’s AADvance‑Trusted SIS Workstation contains a high‑severity path‑traversal flaw inherited from the DotNetZip library that can lead to arbitrary code execution when a user opens a crafted archive — operators must update to AADvance Workstation v2.01.00 or later and apply immediate defense‑in‑depth controls while rollouts are scheduled.

Background / Overview​

Rockwell Automation’s AADvance‑Trusted SIS Workstation is a safety instrumented systems (SIS) engineering suite used to design, configure, and manage safety logic for Trusted® Series 8000 and AADvance® Series 9000 controllers. On disclosure, the vendor and national vulnerability repositories identified a directory‑traversal weakness in the DotNetZip third‑party component embedded in the product’s archive/extraction code. The vulnerability has been assigned CVE‑2024‑48510 and is rooted in the ZipEntry.Extract.cs extraction logic used by DotNetZip versions up to and including 1.16.0. Rockwell lists affected AADvance Workstation builds as versions 2.00.00 through 2.00.04, and states the issue is corrected in v2.01.00 and later. Two scoring systems have been published for the underlying DotNetZip defect: a high CVSS v3.1 score and a CVSS v4 score reflecting significant confidentiality, integrity, and availability impact if the flaw is exploited. Independent repositories reproduce similar severity ratings and technical summaries confirming the root cause in DotNetZip’s extraction path handling.

---

The technical fault: how DotNetZip’s extraction becomes a weapon​

What is the bug?​

At its core, CVE‑2024‑48510 is a path traversal (CWE‑22) in DotNetZip’s extraction routine. When the library extracts files from an archive, it attempts to sanitize and constrain destination paths to the intended base directory. The reported flaw allows specially crafted zip entries to bypass or subvert that sanitization, causing files to be written outside the expected destination (commonly known as “ZipSlip”). Through this behavior an attacker can:

• overwrite or create files in arbitrary locations,
• place executable payloads where they will be executed by the victim system,
• or place configuration/credential files that lead to subsequent compromise.

This extraction bug is specifically traced to handling in src/Zip.Shared/ZipEntry.Extract.cs in DotNetZip. The vulnerability can be triggered when a user opens or imports a malicious archive.

Exploit model and preconditions​

The realistic exploitation chain for the AADvance Workstation includes:

• an attacker crafts a malicious zip archive with filenames containing traversal sequences or mutated path components;
• the archive is delivered to an engineer or operator (email attachment, shared project archive, USB, or compromised repository);
• the user opens the archive within AADvance Workstation or the product processes the archive as part of a project import/restore operation;
• the extraction logic writes files to unintended locations (for example, system folders, application binary directories, or user profile paths), enabling arbitrary code execution or persistence.

Crucially, the attack requires user interaction — opening the malicious file — and the presence of the vulnerable DotNetZip component in the product stack. That interaction vector does not make the flaw trivial, but in industrial settings opening third‑party project/backup files is routine and therefore a credible attack surface.

Severity and scoring​

Published scores vary slightly by source, but the consensus is high severity:

• Rockwell reports a CVSS v3.1 base score of 8.8 and a CVSS v4 score of 8.6 for the issue as it impacts the AADvance package.
• National repositories and vulnerability trackers list the DotNetZip defect as critical (common CVSS v3.1 values reported in the 9.x range for the library itself), reflecting network‑accessible exploitation potential of affected products that accept untrusted archive input.

Those high ratings are driven by the combination of remote attack vector (the archive can be received over networked channels), low attack complexity (no advanced cryptography or privilege required beyond tricking a user to open a file), and the potential for complete system compromise if code execution is achieved.

---

Vendor and registry verification​

To avoid single‑source reliance, the advisory and technical facts were cross‑checked:

• Rockwell’s advisory page for this issue (Advisory SD1761) lists the affected product, versions (2.00.00–2.00.04) and the corrective release (2.01.00+). Rockwell describes the root cause as a directory traversal in DotNetZip and gives the CVSS values cited above.
• The NVD/CVE registry lists CVE‑2024‑48510 and confirms it is a DotNetZip directory traversal affecting versions up to 1.16.0, with links to the vulnerable source lines in public mirrors of the library. NVD’s record gives publication details and references that corroborate the vendor’s account.
• Multiple security vendors and trackers (Snyk, Wiz, SOCRadar, CVE Details) provide technical analysis and reproduce the path traversal root cause and the affected DotNetZip versions. These independent write‑ups mirror the library‑level findings and provide cross‑validation of the vulnerability mechanics.

Where public trackers diverge (for example, slight differences in computed CVSS values at the library vs. the product level), operators should treat vendor advisory versioning and the product fix target as the authoritative remediation route.

---

Impact on industrial environments and Windows engineering hosts​

Why SIS workstations matter​

A SIS engineering workstation contains safety logic projects, configuration files, and sometimes credentials or signing material used to deploy changes to controllers. Compromise of such a workstation — especially on a Windows engineering host — can allow:

• unauthorized modification of safety logic,
• unauthorized uploads to controllers or HMIs,
• exfiltration of design documents and credential material,
• and persistent footholds in critical networks.

Because engineering workstations often bridge IT and OT networks, a compromised AADvance host can serve as a pivot point to reach controllers or HMIs. Even if the SIS Workstation itself runs only intermittent engineering tasks, its trust relationship in the maintenance chain elevates the operational seriousness of any compromise.

Realistic attack scenarios​

1. Targeted social engineering: an attacker sends a project archive labeled as a vendor patch or configuration change; an engineer opens it on a Windows engineering workstation; files are extracted to program folders and a scheduled task or lateral loader runs the payload.
2. Supply‑chain trojan: a build server or shared repository is compromised and begins distributing crafted archives to multiple engineering hosts — the ZipSlip bug lets the attack scale across an organization that trusts shared projects.
3. Removable media: contractors or field technicians bring USB media containing what appear to be benign project backups; a user opens the backup and the extraction installs persistence.

All scenarios are plausible in operational settings where engineers routinely exchange project archives, restore backups, or accept contractor files.

---

Mitigation and remediation — what to do now​

Rockwell’s definitive remediation for customers running AADvance‑Trusted SIS Workstation is to upgrade to v2.01.00 or later. For organizations that cannot yet deploy the update, Rockwell and CISA style guidance recommend immediate compensating controls and best practices. The recommended actions fall into three tiers: urgent operational controls, medium‑term remediation planning, and long‑term hardening.

Immediate (0–72 hours) — urgent stopgap measures​

• Patch and upgrade where possible: plan and test deployment of AADvance v2.01.00 across engineering hosts and lab environments first. Rockwell lists the corrected release as the fix; upgrading is the only complete remediation.
• Block sources of untrusted archives: temporarily disallow opening of project/backup archives from external/unverified sources on engineering workstations. Enforce stricter file acceptance policies.
• Inventory and isolate: compile a list of all hosts running AADvance Workstation and ensure they reside in an isolated OT engineering VLAN not directly reachable from the business network or the Internet.
• Email and web filtering: tighten filtering to strip or quarantine zip attachments originating from outside the organization and require additional validation before engineers can open archived files.
• Endpoint protections: ensure up‑to‑date EDR/AV is enabled, application control (e.g., AppLocker) is in place, and execution policies prevent arbitrary binaries from running from untrusted directories.

Short–medium term (72 hours – 2 weeks) — controlled remediation​

1. Test and deploy v2.01.00 in a non‑production lab to validate compatibility with controllers and existing project artifacts.
2. Roll out the update in stages with roll‑back plans and backups of project databases.
3. Harden engineering workstation policies:
   • enforce least privilege: remove local admin rights where possible;
   • enable controlled (whitelisted) file paths for project imports;
   • use signed project repositories and verify signatures prior to import.
4. Restrict removable media usage or enforce scanned and validated transfer workflows for USB drives and contractor media.

Long term (weeks – months) — systemic defenses​

• Secure software supply chain: ensure third‑party libraries used across the OT/engineering estate are tracked, updated, and replaced when unmaintained (DotNetZip is legacy — consider migration to maintained alternatives).
• Defense‑in‑depth: maintain strict segmentation between IT and OT, use jump hosts for remote vendor access, require multi‑factor authentication for remote engineering sessions, and monitor for anomalous outbound connections from engineering hosts.
• Application whitelisting: adopt strong application control policies on engineering workstations to prevent unauthorized binaries or scripts from running even if files are written to disk.
• Incident playbooks and detection: add detections for unexpected file writes outside project directories, monitor process creation events and persistence artifacts, and retain forensic captures to speed incident response.

---

Strengths and gaps in the vendor/registry response​

Strengths​

• Rockwell identified the dependency issue and published a corrective product release and advisory that enumerates affected versions and the target remediation (v2.01.00). That gives operators a clear upgrade target.
• Public registries (NVD/CVE) and multiple security vendors reproduced the technical details, enabling defenders to cross‑verify the root cause and affected library lines.

Gaps and practical friction​

• Legacy third‑party dependency: DotNetZip is effectively EOL in many ecosystems; no single upstream maintainer patch may exist for all downstream uses. This increases the long‑term remediation burden for vendors (they must either remove or replace the component). Several trackers explicitly recommend migration to maintained compression libraries.
• Operational cost of patching: SIS engineering suites are highly sensitive to compatibility with controller runtimes and safety processes — rolling out updates requires testing windows and careful coordination with safety/OT teams, which slows deployment.
• Detection limitations: CISA/vendor advisories commonly note that “no known public exploitation” was observed at the time of disclosure; however, defenders should not treat absence of public exploit code as absence of risk. The lack of in‑the‑wild reports does not eliminate the real operational urgency.

Where advisories or trackers claim “exploitation observed in the wild,” those claims must be treated carefully and validated against telemetry from trusted incident response sources before being accepted as fact — public reporting timelines and detection windows can lag.

---

Practical checklist for Windows‑centric engineering teams​

• 1. Inventory: list every engineering workstation, server, and build system that runs AADvance Workstation (include exact version strings).
• 2. Isolate: ensure these systems are in an OT engineering segment with strict ACLs; block inbound access from general corporate networks.
• 3. Patch: test and schedule the upgrade to AADvance v2.01.00; apply to test rigs first.
• 4. Block and monitor: disallow opening zip/project files from untrusted sources and instrument file system monitoring to alert on extractions outside project folders.
• 5. Harden endpoints: apply application control, remove local admin privileges, enable EDR with behavior rules focused on process creation and persistence.
• 6. Vendor coordination: contact Rockwell TechConnect/PSIRT if you need migration guidance, compatibility help, or further clarifications on the advisory.

---

Longer‑term lessons for ICS and enterprise defenders​

• Track third‑party components as first‑class inventory items. Many ICS vulnerabilities arise from legacy libraries that are reused across products. Establish a bill‑of‑materials (SBOM) for engineering tools and treat EOL/legacy components as high‑priority migration tasks.
• Assume user interaction will be abused. In OT environments, routine tasks (opening a vendor archive, restoring backups) are legitimate and frequent; threat models must design controls around that reality.
• Make engineering workstations resilient. Hardened imaging, immutability for critical directories, and strict file import workflows materially reduce the attack surface even when applications contain parsing bugs.
• Invest in OT‑aware detection. Endpoint telemetry augmented with network NDR tuned for OT protocols gives defenders earlier visibility into attacker activity that often precedes controller impacts.

---

Caveats and unverifiable claims​

• Multiple third‑party trackers have suggested the DotNetZip defect has been weaponized in targeted incidents; those specific “in‑the‑wild” assertions require corroboration from incident responders who observed the exact CVE exploitation artifacts. Until such telemetry is published by trusted CSIRTs or vendors, treat “observed exploitation” claims with caution and verify against your organization’s logs.
• CVSS values can differ depending on whether an aggregator scores the bare library (DotNetZip) or the product (AADvance Workstation). Use Rockwell’s advisory and the product‑level fixes as the authoritative operational reference for remediation planning.

---

Conclusion​

CVE‑2024‑48510 is a textbook example of how an unmaintained or legacy third‑party library can create a severe operational risk in industrial software. For Rockwell AADvance‑Trusted SIS Workstation users, the path forward is straightforward but operationally demanding: test and deploy AADvance v2.01.00 or later as the primary remediation, and in parallel implement containment, endpoint hardening, and stricter archive handling policies to mitigate the exploitation window.
The broader lesson for Windows system and OT engineers is to treat engineering workstations as high‑value targets: they must be patched, segmented, and hardened with the same urgency used for production servers. The vendor advisory and public vulnerability records provide a clear technical diagnosis and remediation path; operators who act quickly will reduce the risk of lateral compromise and preserve safety and availability in their facilities.

---

---

Source: CISA Rockwell Automation AADvance-Trusted SIS Workstation | CISA