Raise3D Pro2 Security: Disable Developer Mode to Mitigate CVE-2025-10653

Raise3D’s Pro2 Series 3D printers were flagged in a federal industrial-control-systems advisory for an authentication bypass that can be triggered when the device’s developer mode is enabled — an unauthenticated debug/API path exposes the printer’s filesystem and sensitive functions, and the advisory assigns the issue CVE‑2025‑10653 with a high severity rating (CVSS v4 base score reported at 8.8). Successful exploitation, the advisory warns, could let a remote attacker exfiltrate files, tamper with firmware or print jobs, and achieve persistent control of the device. This is an actionable, high‑impact alert for anyone using Pro2 Series hardware in labs, production floors, or offices where the printers are networked. The vendor has acknowledged the flaw for developer mode and is working on a firmware patch; meanwhile the primary immediate mitigations are to disable developer mode and block network exposure of printer management interfaces. The presence of an unauthenticated debug/API path on an industrially‑deployed peripheral is a classic failure of secure defaults: powerful diagnostic features were shipped in production firmware without adequate access controls. The result is a high-risk remote attack surface that must be removed or isolated until a vendor patch is installed.

Background / Overview​

Raise3D’s Pro2 Series is a widely used, dual‑extrusion FFF 3D printer family used in prototyping, tooling, and low‑volume production. Recent RaiseTouch releases added a Developer Mode and a Remote Access API intended to let integrators and advanced users automate and extend printer control via a documented web API and local services. The vendor documentation explicitly shows how to enable Developer Mode through the touchscreen and how the remote API is exposed for developer workflows.
CISA’s advisory (published as an ICS advisory) states that enabling developer mode on Pro2 Series units makes an unauthenticated debug port / API reachable that allows an attacker to read the device filesystem and bypass normal authentication checks. The advisory reports assigned identifier CVE‑2025‑10653 and provides high CVSS ratings (a CVSS v3 base of 8.6 and a CVSS v4 base of 8.8). At the time of this writing, Raise3D has confirmed the vulnerability affects Pro2 Series devices when developer mode is enabled and is preparing firmware fixes; the vendor’s interim recommendation is to disable Developer Mode when not intentionally used. The advisory also repeats standard CISA ICS guidance: remove network exposure, isolate ICS devices behind segmented networks and firewalls, and use secure remote access techniques when needed. (Attempts to fetch the CISA advisory directly encountered an access error during retrieval, but the advisory text has been publicly distributed in coordination channels.) ([]())

---

Why this matters: immediate risk to prints, networks and safety​

3D printers are not “innocent” peripherals in modern environments. When they run production prints or hold intellectual property (part designs, slicing profiles, process recipes), a compromised printer becomes a direct vector for:

• Data exfiltration: G‑code files, STL files, calibration profiles, and logs can contain IP or operational secrets that attackers can steal.
• Tampering with physical output: Malicious modification of G‑code or temperature/speed settings can weaken parts, create structural failures, or produce defective production components — a safety and quality risk.
• Firmware compromise and persistence: An unauthenticated debug path can allow writes to device storage or firmware images, enabling backdoors or persistent implants that survive reboots.
• Lateral movement into IT systems: Printers often communicate with Windows workstations (slicing stations, print servers) and shared storage. Past incidents show printers can become pivot points for credential collection or protocol abuse that leads to Windows domain compromise.

The advisory specifically identifies “unauthenticated debug port” and “access to the device file system” as the root technical issue. That combination — no authentication + filesystem access — dramatically lowers the attacker’s work factor and makes rapid exploitation feasible in many environments.

---

Technical recap: what the advisory says (concise)​

• Affected product: Raise3D Pro2 Series (the advisory lists all versions of Pro2 Series as affected so long as Developer Mode is enabled).
• Root cause: An unauthenticated debug/API path exposed when Developer Mode is enabled that bypasses authentication controls and provides filesystem and privileged function access.
• Assigned CVE: CVE‑2025‑10653 (advisory text lists this identifier).
• Severity: High; CISA reports CVSS v3 ≈ 8.6 and CVSS v4 ≈ 8.8 for this issue.
• Vendor status: Raise3D confirmed the issue is real in developer mode, is developing a firmware patch, and recommends disabling Developer Mode as an immediate mitigation. Raise3D’s own documentation shows the Developer Mode and Remote Access API features added in RaiseTouch releases.

Note on verification: the advisory text, CVE and CVSS values were reported in the CISA brief; attempts to fetch the CISA advisory directly during preparation of this article met an access error, and the CVE registry/NVD search did not return an authoritative public CVE entry for CVE‑2025‑10653 at the time of writing. That makes the advisory the primary authoritative source for the claim; where possible, readers should confirm the CVE/CISA entry and vendor patch notices directly after publication. ([]())

---

How the vulnerability fits common failure patterns​

This class of vulnerability maps to the well‑known weakness “Authentication Bypass Using an Alternate Path or Channel” (CWE‑288). It commonly appears when diagnostic, maintenance or developer interfaces are left enabled in production firmware, and when those interfaces are either undocumented or not protected by the same authentication mechanisms as the primary management UI.

• Developer tools are powerful for debugging but dangerous if activated on networked devices without strict access control.
• Shipping a production device with an active developer interface is a secure‑defaults failure: features that expand functionality were not gated by a secure configuration option that is off by default.
• Because the Pro2 Series device has a web/Touch UI and supports a Remote API, enabling developer mode effectively opens additional network services (for example the RaiseTouch Remote Access API endpoint on a local port) that are reachable if the printer sits on a network reachable by attackers. Raise3D’s release notes document the presence of an API and how Developer Mode is enabled.

---

Attack scenarios administrators should prioritize​

• Automated scanning and opportunistic compromise
• An internet‑exposed or poorly segmented printer with Developer Mode enabled can be discovered by internet scanners and probed for debug endpoints, allowing immediate unauthenticated access.
• Targeted IP theft and sabotage
• A threat actor targeting a manufacturer or R&D lab can use filesystem access to steal part files and replace them with defective designs that later cause product failure.
• Lateral movement into Windows networks
• Printers commonly connect to Windows slicing workstations or shared SMB locations. Compromise of printer firmware or stored credentials can be leveraged to access those Windows resources and escalate privileges. Historical ICS and office printer incidents show this bridging risk is real.
• Persistence for long campaigns
• Because printers are often less monitored and patched than servers, attackers can hide in firmware or scheduled print jobs and maintain access for months.

---

Vendor response and current state​

Raise3D has acknowledged the security impact of enabling Developer Mode on affected Pro2 Series devices and is preparing a firmware fix. In the interim Raise3D’s release notes and support documentation describe Developer Mode and the API location; CISA’s advisory lists vendor confirmation and recommends disabling Developer Mode when not required. Administrators should treat “disabled developer mode” as the minimum immediate action and await the vendor firmware release for a permanent fix.
Important operability note: some shops have legitimate workflows that use the Developer API for automation. In those cases, operators must balance operational needs against risk and apply strict network controls (jump hosts, allow‑lists, VLAN isolation) until a patched firmware is available.

---

Practical, prioritized mitigation checklist (start immediately)​

Follow these steps in order — the first items are low‑cost/high‑impact compensations you can do now without waiting for vendor patches.

• Inventory & triage
• Identify every Raise3D Pro2 Series device on your network and record IP addresses, RaiseTouch firmware version, motion controller firmware, and whether Developer Mode is enabled. Raise3D release notes explain where Developer Mode appears in settings.
• Mark any printer that is reachable from non‑trusted networks (corporate network, remote vendor maintenance networks, Internet).
• Disable Developer Mode (immediate)
• On each Pro2, go to Settings → More Settings → Developer and turn Developer Mode off unless you explicitly require it. Raise3D’s documentation shows this path.
• Remove internet exposure (within hours)
• Block inbound access to printers from untrusted networks at your edge firewall and NAT rules. Do not rely on obscurity; block required ports explicitly.
• Network segmentation (within 24–72 hours)
• Move printers onto a dedicated OT/print VLAN with strict access control lists. Only allow management hosts (specific admin subnets or jump hosts) to reach the printers.
• Deny lateral traffic from the printer VLAN to sensitive Windows AD infrastructure unless explicitly required and monitored.
• Harden remote management (if remote access is required)
• Use a hardened jump host / bastion with MFA and client posture verification; avoid direct VPN or port forwarding to printers.
• If VPN is used, limit which endpoints can connect and enforce endpoint security checks. CISA’s ICS guidance reiterates this approach.
• Block or monitor management ports
• At a minimum, block the RaiseTouch remote API port (documented API port in older firmware appears on local HTTP port 10800 for remote API). Where possible, firewall the host to only allow traffic from designated management hosts.
• Logging, detection and monitoring
• Enable detailed logging on management jump hosts and printers (where supported). Send logs to a central collector and generate alerts for unexpected file reads or firmware write attempts.
• Add IDS/IPS rules to detect calls to debug endpoints and unusual GET/POST patterns targeting the printer’s API endpoints; watch for large file downloads (exfiltration) from the printer.
• Change operational passwords & secrets
• If Developer Mode was enabled in the past, assume secrets may be exposed; rotate any passwords, API tokens, or keys stored on or used by the printer and related services.
• Plan patch deployment
• When Raise3D publishes a patched firmware, validate the vendor release notes and checksums, test in a lab, and schedule staged rollouts. Keep backups and rollback plans ready.
• Formal incident response (if compromise suspected)
• If you detect suspicious activity or unauthorized file access, isolate the device, preserve logs and forensic images where possible, and follow internal IR procedures; consider reporting to the relevant national CSIRT/CERT or law enforcement if IP theft or sabotage is suspected.

---

Technical detection suggestions for SOC/IR teams​

• Create specific alerts for any HTTP(S) traffic to printer management ports from new, unexpected source IPs.
• Alert on downloads of large files from /localstorage, /gcode or equivalent endpoints if the printer exposes raw paths.
• Watch for anomalous firmware update attempts (signed vs unsigned images) and unexpected restarts.
• Correlate printer events with Windows workstation behavior (e.g., immediately following a large download from a printer, is an engineering workstation making unusual outbound connections?).

---

Strengths, trade‑offs and vendor choices (analysis)​

• Strengths in the product: Raise3D’s Developer Mode and Remote API are useful for automation and integration. For advanced users, the ability to script device behavior and export logs or time‑lapse captures is a significant productivity boost. The vendor documentation and release notes provide clear enablement steps, which helps legitimate developers.
• The trade‑off / design failure: developer features must be gated by secure defaults. The presence of an unauthenticated debug path when Developer Mode is active is a classic feature vs. security mistake. In modern networked devices the safer default is to ship developer interfaces disabled and to require both local physical presence and explicit authentication to enable advanced interfaces.
• Operational trade‑offs for defenders: Disabling developer mode may break legitimate automation or monitoring workflows. Where automation is required, the compensating controls (segmentation, jump hosts, allow‑lists and MFA) must be implemented carefully and tested to avoid blocking necessary business functions.
• Potential systemic risk: Printers are often treated as low‑value devices by ops teams, so they may be left unpatched or poorly monitored. That creates an attractive target for attackers who seek long‑lived footholds in enterprise environments.

---

What to expect next and recommended posture​

• Expect a vendor patch release window: Raise3D has stated it is preparing a firmware update to correct the issue in Developer Mode; once released, operators must validate and deploy. Until the patch is available, disabling Developer Mode and isolating printers are the correct defensive posture.
• Expect increased scanning activity: Once a vulnerability advisory is public, opportunistic attackers and scanning bots often probe the internet for exposed devices. Prioritize devices that had Developer Mode enabled and those with public reachability.
• Confirm CVE/NVD entries and vendor patch bulletins: The advisory references CVE‑2025‑10653 and CVSS values; defenders should confirm the CVE record in public vulnerability databases and track the vendor’s firmware release notes and checksums. Attempts to fetch the CISA advisory URL during article preparation encountered a retrieval error; readers should validate the advisory and CVE via official vendor and government sources before relying on any third‑party summaries. ([]())

---

Broader lessons for IT and Windows administrators​

• Treat networked printers and OT‑adjacent devices as first‑class security assets. They can host IP, interact with Windows workstations and servers, and become pivot points if compromised. Past printer incidents show credential theft and lateral movement into Windows environments is practical and damaging.
• Enforce least privilege and secure default posture on all devices: development/debug features must be off by default in production builds or require physical presence plus strong authentication to enable.
• Ensure asset inventories include embedded, legacy and lab devices. One unnoticed Pro2 with Developer Mode active and internet visibility is enough to create a large risk.

---

Conclusion​

The Raise3D Pro2 Series advisory underscores a recurring failure mode across connected devices: powerful maintenance and developer features shipped without secure defaults and adequate authentication. The immediate risk is clear — unauthenticated debug access to the filesystem on a network‑connected 3D printer opens a realistic path to data theft, supply‑chain tampering of printed parts, and persistent compromise. The short‑term operational remedy is simple and immediate: disable Developer Mode on every Pro2 Series unit unless its use is strictly required, remove any internet exposure, and isolate printers on segmented, monitored networks. Longer term, apply the vendor firmware patch when it is released, verify checksums, and harden remote access through jump hosts and multi‑factor controls.
Action checklist (short form)

• Inventory all Pro2 Series printers and verify Developer Mode state.
• Disable Developer Mode immediately if enabled.
• Remove internet exposure, place printers behind restricted VLANs and firewalls.
• Monitor logs, deploy IDS rules for API/debug endpoints, and prepare to deploy vendor firmware when available.
• If suspicious activity is observed, isolate the device and follow incident response procedures.

This advisory is a reminder: any network‑connected device that touches IP or production processes must be protected with the same rigor applied to servers — secure defaults, minimal exposure, and monitoring — because the consequences of a compromised peripheral can be severe and surprisingly broad.

---

Source: CISA Raise3D Pro2 Series 3D Printers | CISA