PrusaSlicer 2.6.1 - Arbitrary code execution
# Exploit Title: PrusaSlicer 2.6.1 - Arbitrary code execution on g-code export
# Date: 16/01/2024
# Exploit Author: Kamil Breński
# Vendor Homepage: https://www.prusa3d.com
# Software Link: https://github.com/prusa3d/PrusaSlicer
# Version: PrusaSlicer up to and including version 2.6.1
# Tested on: Windows and Linux
# CVE: CVE-2023-47268
==========================================================================================
1.) 3mf Metadata extension
==========================================================================================
PrusaSlicer 3mf project (zip) archives contain the 'Metadata/Slic3r_PE.config' file which describe various project settings, this is an extension to the regular 3mf file. PrusaSlicer parses this additional file to read various project settings. One of the settings (post_process) is the post-processing script (https://help.prusa3d.com/article/post-processing-scripts_283913) this feature has great potential for abuse as it allows a malicious user to create an evil 3mf project that will execute arbitrary code when the targeted user exports g-code from the malicious project. A project file needs to be modified with a prost process script setting in order to execute arbitrary code, this is demonstrated on both a Windows and Linux host in the following way.
==========================================================================================
2.) PoC
==========================================================================================
For the linux PoC, this CLI command is enough to execute the payload contained in the project. './prusa-slicer -s code-exec-linux.3mf'. After slicing, a new file '/tmp/hax' will be created. This particular PoC contains this 'post_process' entry in the 'Slic3r_PE.config' file:
```
; post_process = "/usr/bin/id > /tmp/hax #\necho 'Here I am, executing arbitrary code on this host. Thanks for slicing (x_x)'>> /tmp/hax #"
```
Just slicing the 3mf using the `-s` flag is enough to start executing potentially malicious code.
For the windows PoC with GUI, the malicious 3mf file needs to be opened as a project file (or the settings imported). After exporting, a pop-up executed by the payload will appear. The windows PoC contains this entry:
```
; post_process = "C:\\Windows\\System32\\cmd.exe /c msg %username% Here I am, executing arbitrary code on this host. Thanks for slicing (x_x) "
``` PrusaSlicer 2.6.1 — Arbitrary code execution via 3MF metadata (CVE-2023-47268)
This article explains a critical post-processing vulnerability discovered in PrusaSlicer up to and including version 2.6.1 (CVE-2023-47268). The flaw lets malicious 3MF project files embed a post-processing command in the project metadata that can be executed when the user slices or exports g-code. The goal here is to describe the vulnerability, impact, detection, mitigation and safe remediation strategies for administrators, developers, and end users.
Key points
- Vulnerability: malicious "post_process" entries in the 3MF project's Metadata/Slic3r_PE.config allow arbitrary command execution during slicing/export.
- Affected software: PrusaSlicer versions up to and including 2.6.1.
- CVE identifier: CVE-2023-47268.
- Exposure vectors: opening an untrusted .3mf project in PrusaSlicer or importing project settings from an untrusted file; automatic execution can occur during export or using CLI slice operations.
- Mitigation: update to a patched version, sanitize project files, disable or restrict post-processing scripts, and use least-privilege/sandboxing for slicing.
Technical background
3MF files are ZIP-based archives that may contain model geometry and extra metadata. PrusaSlicer extends 3MF with a Metadata/Slic3r_PE.config file that stores project settings. One configuration option supported by PrusaSlicer is a "post_process" script: a command or script that runs after g-code is generated or when exporting.
Because project files are often shared (downloaded, emailed, or exchanged through repositories), an attacker can craft a malicious 3MF containing a Slic3r_PE.config with a post_process directive that performs arbitrary actions on the host when PrusaSlicer processes that project. In the vulnerable versions the application did not sufficiently restrict or prompt before executing this command in some workflows.
Why this is dangerous
- Arbitrary code execution: an attacker can run commands with the privileges of the user running the slicer.
- Low user interaction required: simply opening or exporting a project from an untrusted file can trigger execution.
- Wide attack surface: both GUI and CLI operations (slicing/export) can be affected depending on the workflow.
Vulnerability details (high-level)
In short: a specially crafted Slic3r_PE.config entry with a post_process key inside a 3MF archive causes PrusaSlicer to execute the supplied value as a command when exporting g-code. The attack leverages the legitimate feature intended for user-driven post-processing but abuses it to run arbitrary commands embedded inside the project archive.
To avoid enabling attackers, developers should not automatically execute commands taken directly from user-supplied files without explicit, informed user consent and strong constraints (whitelisting, sandboxing, signature checks).
Proof-of-concept behavior (description, non-exploitable)
Proof-of-concept submissions for this vulnerability typically demonstrate that a 3MF archive containing a Slic3r_PE.config with a post_process entry results in the host running the referenced command during export or when slicing via CLI. The PoC demonstrates the behavior but the exact exploit payload is not reproduced here for safety. The important defensive takeaways are:
- The post_process directive inside Metadata/Slic3r_PE.config is the control point.
- The 3MF archive is a ZIP — the metadata file is plain text and can be inspected without executing PrusaSlicer.
- Automated or script-based slicing (CLI) is also a potential vector if the slicer will execute post_process without interaction.
Impact and risk assessment
Impact varies by environment and user privileges. On a typical workstation the attacker can execute arbitrary user-level commands (exfiltrate files, download additional payloads, open dialogs, or attempt privilege escalation). In some environments this could lead to broader compromise, data theft, supply-chain issues (if a shared project repository is poisoned) or sabotage of printer operations.
Who should care
- End users who open 3MF files obtained from untrusted sources.
- Administrators managing shared PrusaSlicer installations, maker labs, schools, and fabrication facilities.
- Developers and maintainers of PrusaSlicer and derivative slicer tools.
Detection and indicators of compromise (defensive)
- Look for unexpected commands referenced in Metadata/Slic3r_PE.config entries inside 3MF archives.
- Audit logs or process monitoring tools for suspicious child processes launched by the slicer at the time of exporting/slicing.
- Search file repositories for 3MF files that contain the string "post_process" (case-insensitive).
Example: to inspect a 3MF archive manually, open it with a ZIP tool and examine Metadata/Slic3r_PE.config before loading it into PrusaSlicer. Never trust a project file without inspecting its metadata.
Mitigation and remediation
- Update: install the fixed PrusaSlicer release (upgrade to a version that patches CVE-2023-47268). Always use the vendor-released patched version.
- Disable/Restrict post-processing: until patched, disable post-processing features or configure PrusaSlicer to require explicit confirmation before running any external commands.
- Sanitize incoming 3MF files: scan and remove post_process entries before opening projects from untrusted sources.
- Sandboxing: run slicing tasks in an isolated environment or low-privilege account. For shared systems, consider a VM/container per-user or per-job.
- Policy: for organizations, prohibit opening user-submitted 3MF files on production or admin machines; use a dedicated, monitored slicing host.
Safe remediation — automated sanitization
Below is an example defensive Python script that reads a .3mf file (ZIP archive), locates the Metadata/Slic3r_PE.config file (if present), neutralizes any post_process lines by replacing them or commenting them out, and writes out a sanitized 3MF file. This code is intended to be used as a defensive pre-processing step for untrusted files before they are opened in PrusaSlicer.
import zipfile
import io
import re
import sys
def sanitize_3mf(input_path, output_path):
with zipfile.ZipFile(input_path, 'r') as src:
names = src.namelist()
buf = io.BytesIO()
with zipfile.ZipFile(buf, 'w', zipfile.ZIP_DEFLATED) as dst:
for name in names:
data = src.read(name)
# Normalize path check to lowercase to be robust
if name.lower() == 'metadata/slic3r_pe.config':
text = data.decode('utf-8', errors='ignore')
# Replace any line that assigns post_process with a harmless comment
text = re.sub(r'(?im)^[ \t;#]*post_process\s*=.*$',
';post_process removed by sanitizer for safety',
text)
data = text.encode('utf-8')
dst.writestr(name, data)
with open(output_path, 'wb') as f:
f.write(buf.getvalue())
if __name__ == '__main__':
if len(sys.argv) != 3:
print("Usage: sanitize_3mf.py input.3mf output.3mf")
sys.exit(1)
sanitize_3mf(sys.argv[1], sys.argv[2])Explanation: the script opens the input .3mf as a ZIP archive, searches for Metadata/Slic3r_PE.config, and uses a regular expression to replace any lines that configure post_process with a harmless commented line. The sanitized archive is then saved. This eliminates the immediate risk from embedded post-processing commands while preserving the rest of the project.
Manual scanning
If you prefer manual checks, extract the 3MF (it's a ZIP) and open Metadata/Slic3r_PE.config in a text editor; search for "post_process" and either remove the line or comment it out before importing or opening in PrusaSlicer.
Secure design recommendations for developers
- Do not auto-execute commands from untrusted files. If using user-supplied script paths, require an explicit, clear confirmation and show the exact command to be executed.
- Whitelisting: allow only whitelisted scripts or internal macros rather than arbitrary system commands.
- Sandbox: execute post-processing in a restricted environment (containerized or with minimal privileges) to reduce blast radius.
- Sign and verify project metadata: support signatures for trusted project templates or settings bundles, and require verification before executing anything embedded.
- Auditing and logging: log all post-processing executions with sufficient detail for incident response.
Recommended immediate actions for users and administrators
- Update PrusaSlicer to the patched version released after CVE-2023-47268 was disclosed.
- Until updated, avoid opening 3MF files from untrusted sources or sanitize them first (see script above).
- Disable or restrict automatic post-processing in application settings where possible.
- Run slicing tasks on a dedicated, isolated host or VM if you regularly accept third-party project files.
- Audit shared project repositories for 3MF files containing "post_process" and sanitize or remove them.
References and attribution
| Item | Reference |
|---|---|
| Vendor | Prusa3D — https://www.prusa3d.com |
| Project source | PrusaSlicer (GitHub) — https://github.com/prusa3d/PrusaSlicer |
| CVE | CVE-2023-47268 |
| Disclosure | Public vulnerability reports and advisory details from the researcher and vendor |
Summary
CVE-2023-47268 demonstrates how a convenient feature (post-processing scripts embedded in project metadata) can be abused when user-supplied files are trusted without validation. The proper response is to update software promptly, sanitize incoming project files, apply least-privilege and sandboxing principles, and for developers to avoid executing untrusted content automatically. Use the defensive measures and sanitizer examples above to reduce risk immediately while applying vendor patches.