3D Printing / Security

Qidi Plus 4 — Out-of-the-Box Security Teardown

The Qidi Plus 4 is a genuinely good-value CoreXY printer: enclosed, actively heated chamber, high-speed Klipper motion, and an open ecosystem instead of a walled garden. That openness is also the story here. Before this machine ever printed a benchmark, I logged into the little computer bolted to the side of it to see what it actually runs — and what it leaves wide open by default.

The QIDI Plus 4 3D printer, front view, showing the
enclosed heated chamber and the touchscreen control panel. — The QIDI Plus 4 — an enclosed CoreXY machine that's also a small networked Linux computer. Product image: QIDI Technology.

What this is, and isn't: this is a review of the Plus 4's software and network posture as it ships — the stuff nobody puts on the spec sheet — not a print-quality shootout. No long-term reliability verdict, no filament-tuning opinions, no dimensional-accuracy charts here. This is the "what is this thing doing on my network, and is that okay" review. Everything below is the stock factory image; none of it requires modding the printer, just SSH access it hands out by default.

What's actually inside

Under the hood the Plus 4 is a small single-board Linux computer (a Rockchip-based board in the MKS-PI family) driving the printer's real-time controller. The software stack is the mainstream open-source one that most modern fast printers converged on:

Klipper for motion, running the actual G-code and talking to the microcontroller.
Moonraker, the HTTP/WebSocket API that everything else talks to.
Fluidd as the web interface you reach in a browser.
An mjpg-streamer webcam feed for watching prints.

This is a good thing. It means the printer isn't a locked appliance — you own it, you can automate it, you can back it up, you can fix it. The flip side is that it's a real networked Linux host with all the responsibilities that implies, and Qidi ships it configured for "works instantly on any home network," not "safe on any home network." Those aren't the same setting.

The operating system is already end-of-life

The base OS is Debian 10 "buster". Debian 10 reached the end of even its extended LTS support in mid-2024 — meaning it stopped receiving security patches well over a year ago. On the unit I looked at, the last package-list update baked into the image was from 2024, and there's no automatic-update mechanism configured, so it simply sits there. Every kernel, OpenSSL, and web-server vulnerability disclosed since then is unpatched and will stay that way unless Qidi ships a new firmware image or you update it yourself.

This is common across the whole category — vendors freeze an old vendored Linux image and rarely refresh the base OS — but "everybody does it" doesn't make an EOL OS on your LAN fine. It's the single biggest structural issue, and the one an owner can do the least about without vendor cooperation.

The default login is a published, unchanged password. The printer runs an SSH server, and the login is the well-known factory default for this class of board — a username and password that are documented publicly and identical across units. Nothing on the touchscreen prompts you to change it, and the account can escalate to root. Anyone who can reach the printer over the network and knows that default (i.e. anyone who has used one of these before, or can search for thirty seconds) can get a root shell. This is the first thing to fix, and it's fixable in two minutes.

Open by default on the network

A quick look at what the printer is listening for, and to whom, tells the rest of the story. As shipped:

SSH accepts passwords and allows direct root login. Combined with a known default password, that's a remotely usable login, not a theoretical one. It also offers some dated, weak connection ciphers/MACs that modern hardening guidance flags.
The Moonraker API trusts your entire local network. The factory config marks the whole private-address range as "trusted," which means any device on your LAN can drive the printer's API with no login at all — upload and start G-code, run macros, change settings. On a flat home network, that's every phone, laptop, TV, and IoT gadget you own.
The webcam stream has no authentication. The raw MJPEG feed is served openly, so anything on the network can watch your camera directly, without going through the web UI's login.
There's no host firewall. The printer does nothing itself to limit who connects; it relies entirely on your network to do that.

None of this is exotic or a "vulnerability" in the CVE sense — it's default configuration. But the defaults all lean the same direction: maximum convenience, zero segmentation, trust everything. That's a reasonable choice for a printer that assumes it lives on a trusted network of one. It's a bad assumption for a real household network full of other devices.

Why this matters more than "it's just a printer"

A compromised printer isn't only a privacy problem (though the open camera is exactly that). It's a full Linux foothold on your internal network — a always-on box that can scan, pivot, and phone out, running an OS that no longer gets patched. And on the physical side, unauthenticated control of a machine with a 350°C hotend and a heated chamber is not a risk to wave off. The realistic threat model for a home isn't a targeted attacker; it's a worm or a compromised IoT neighbor finding an easy, unpatched, default-credential host sitting right there. This printer is a textbook version of that host.

What to actually do about it

The good news is that the same openness that creates these issues also lets you fix nearly all of them yourself in an afternoon. In rough priority order:

Change the default password immediately, and set up an SSH key. If you're key-only, turn off SSH password authentication entirely and disable direct root login.
Put the printer on its own VLAN or an isolated/IoT network, and firewall it off from the rest of your devices. This is the highest-leverage move: it contains everything else on this list. Poke a hole only for the one machine you print from.
Tighten Moonraker's trusted_clients to just the host(s) you actually use, instead of the whole private range, so the API requires a login from everything else.
Don't port-forward it to the internet. If you need remote access, use a VPN or an authenticated tunnel — never expose the web UI or the camera directly.
Update what you can. Apply Qidi's firmware updates when they ship, and consider enabling automatic security updates on the underlying OS if you're comfortable at the command line — accepting that the EOL base only goes so far.

Verdict

As a printer, the Plus 4 earns its reputation — the hardware is a lot of capable machine for the money, and the open Klipper stack is a feature, not a bug. As a network citizen, it ships about how you'd expect for the category and price: an end-of-life OS, a published default password, and a trust-everything default posture, none of it flagged to the buyer. That's not a reason to avoid the printer. It is a reason to spend fifteen minutes locking it down before it joins your network, and ideally to give it a segment of its own. Treat it like the small, unpatched Linux server it actually is — because that's exactly what it is — and it's a great machine. Plug it into a flat network and forget about it, and you've added the easiest target in the house.

Print-quality and long-term reliability impressions are a separate review, once this thing has some real hours on it. This one was about the part that ships switched to "off."