Moonraker trusts local clients by default, and that boundary can travel
Moonraker is the web API server for Klipper-based 3D printers. It exposes printer status, file management, job control, updates, and configuration features to clients such as Mainsail and Fluidd. A local tool that makes printing convenient becomes a control plane when the same service is reachable from a wider network.
A bounded ZoomEye SDK probe on 2026-11-12 between 00:49:27 and 00:49:30 UTC used sub_type=all, page 1, and a page size of one. The application query app="Moonraker" returned 0. The exact title query title="Moonraker" returned 360, and http.body="Moonraker" returned 12,978. The title result is the candidate set. The body count includes documentation and client references and should not be described as confirmed printers.
Review trusted clients and user mode
Moonraker's authorization documentation describes trusted clients, JWT authentication, and API keys. A trusted client receives broad access. A fresh installation can start with a local client in the trusted set. The configuration documentation states that once users are created, force_logins can require credentials even for clients that would otherwise be trusted.
Inventory which addresses or networks are trusted. A broad LAN range that includes guest devices or a public reverse proxy can turn a printer control plane into a shared administrative interface. If remote access is required, use a VPN or identity-aware proxy rather than exposing the raw API. Confirm that the proxy cannot make every request look like a trusted local client.
Review the API key and user database. The API key is created when the authorization component is first configured. Retrieve it only from a trusted client and store it in a secret manager. Do not place it in a public client configuration, a shared document, or a screenshot. Rotate it after an exposure and verify that old clients fail.
Treat file roots as code paths
Moonraker's file manager exposes configured roots for configuration, logs, G-code, and other data. File uploads and downloads are available through the HTTP API. Each root has a different consequence. A G-code upload can start a print job, while a configuration change can alter printer behavior or execute a configured macro.
Review the roots and the permissions attached to each. Remove access to files that a client does not need. Check whether a client can move a file between roots or overwrite a configuration file. A trusted client warning in the documentation notes that an unattended client can be reconfigured to send secret material through notification or MQTT features. That is a useful reminder that the browser client is part of the trust path.
Test a low-privilege user separately from a trusted client. Confirm that the user cannot access an administrative extension or an unapproved root. Check what happens after the user is deleted or a password changes. Existing JWT sessions and API keys should follow the configured revocation behavior.
Confirm the physical and network owner
A public Moonraker candidate may be a personal printer, a print farm, a demonstration, or a stale page. Confirm the owner and the physical device behind the service. Record the printer model, Klipper and Moonraker versions, trusted network, client list, exposed roots, notification integrations, and update process.
Review the network path from the printer to the internet. A router port-forward can expose the API without any application fingerprint. Check the reverse proxy and its authentication policy. If a webcam or dashboard is also published, verify that it does not provide a separate route to the same control plane.
ZoomEye helps find candidate printer services and compare their visible population. It cannot see whether a trusted client is present or whether a file root is writable. The security decision comes from the owner's network design and the authorization tests on the actual device.
Top comments (0)