QIDI Studio is the slicer for QiDi's printers. Free, actively developed, and the software you would actually run day to day. This is not a slicing-quality review. It asks the same "what is this thing doing on my network, and what is inside it" question already asked of the Qidi Plus 4 printer itself, aimed at the desktop app instead. Two things, both verified rather than assumed. Exactly what it contacts on the internet at every launch, caught with a packet capture scoped to its own process ID. And a scan of what is bundled inside the install, which turned up a real, currently unpatched CVE.
ss -tnp's process-owner field against the
capture. Connections are attributed to QIDI Studio here because the kernel reports its PID as the socket
owner, not because the timing looked suspicious.
Fresh install, no account signed in, printer configuration untouched. Within the first few seconds of opening the app, before I touched anything in the UI, its own process opens three outbound connections. Confirmed by PID, not a browser tab:
api.qidimaker.com, Cloudflare-fronted. QIDI's own model-sharing and
community platform, QIDIMaker. Almost certainly populating whatever "community models" or "recommended"
content shows on the home screen.shops.myshopify.com. Most likely a shop or promotional widget rather than anything
printer-functional, though I did not inspect the exact content.api.qiditech.com. This one is interesting for a different reason. It
returns NXDomain. The app tries to reach a subdomain of its own vendor's main domain that
does not currently resolve. A dead or retired endpoint on QIDI's own infrastructure, not a problem on the
user's end.None of this happened behind a consent prompt, an opt-in toggle, or any disclosure in the UI at first launch. It is default behavior the moment the app opens. None of it is unusual for a modern desktop app with a home screen showing marketplace content. Bambu Studio and Cura both do comparable things. None of it looked like it was exfiltrating anything printer-specific or project-specific in this test. Still, "silently reaches three external hosts before you have configured anything" is worth knowing going in. Especially on a network segment you would otherwise assume is offline by design.
Extracting the AppImage and inspecting what it ships against what it expects from the system turned up a clean split. WebKitGTK, OpenSSL and curl are not bundled. The app links against whatever the host distro provides, so those components stay current through normal OS updates instead of frozen at whatever version QIDI built against. That is a genuinely good call.
What is bundled is its own copy of FFmpeg. libavcodec,
libavutil, libswresample, libswscale. Almost certainly for the
timelapse and video-processing features. The version string embedded in the binary itself:
FFmpeg version 7.0.2ff_aac_search_for_tns in
libavcodec/aacenc_tns.c), triggerable via a crafted input file, with a public exploit already
disclosed. It affects every FFmpeg release up through 7.1 and was only fixed in 8.0. QIDI Studio's bundled
7.0.2 predates even the 7.1 branch. It has never received this fix. FFmpeg itself had moved to
9.0 by August 2026, with security-maintained branches as recent as 8.1.2 and 7.1.5. QIDI's
bundled copy was roughly two years and several major releases behind at the time of this teardown.
Be precise about what this does and does not mean. It identifies a real vulnerability present in the exact bundled binary shipping inside the current QIDI Studio release, confirmed by extracting the version string rather than assuming from a release date. It does not establish whether QIDI Studio's own code path reaches the vulnerable AAC-encoder function during normal use, as opposed to only ever using FFmpeg for decoding and playback. Answering that needs deeper reverse engineering of the app than a black-box scan can do. Both halves matter. The vulnerable code is genuinely sitting in the install, and confirming real-world reachability is a separate, harder question.
For context, one older FFmpeg CVE is already fixed in the bundled 7.0.2. CVE-2024-7055, a PNM decoder heap overflow affecting versions up to 7.0.1. Not everything here is bad news. The bundled copy just stopped getting updated somewhere after that point.
Adding a printer as a network device saves its connection details to a plaintext JSON file. Hostname, and an
API key for its Moonraker API, under ~/.config/QIDIStudio/user/default/physical_printer/. That
key grants full control of the printer to anything that can read the file. Upload, print, run macros. This is
extremely common for desktop apps in this category, and it is the same pattern OctoPrint and Klipper host
tools use. The usual caveat applies. Anything else running as your user account has that credential in the
clear, and so does a backup that is not handled carefully.
App logs are the opposite story. They are genuinely encrypted on disk, a real BEGIN_HEADER and
JSON-metadata encrypted log format, confirmed by inspection. That is a reasonable design choice for a desktop
app that might ship logs back for support.
Separately from all of the above, QIDI Studio has a well-defined segfault on Linux. It fires the moment you add a physical printer and reconnect to it. A WebKitGTK conflict QIDITECH acknowledges in their own release notes, not something specific to this test. Full diagnosis and the two-setting fix are in a separate wiki guide.
Nothing found here is a smoking gun. The network behavior is default telemetry and marketplace traffic, disclosed nowhere but not hidden either, and standard for the category. The plaintext API key storage is standard for the category too. The one finding that matters is concrete and checkable by anyone. The bundled FFmpeg is real, it is about two years stale, and it carries a specific, critical, publicly disclosed CVE the shipping release has not addressed. That is not catastrophic on its own. This app is not processing untrusted video files from strangers. But it is exactly the kind of gap a hardware company shipping desktop software as a secondary product lets slip, and exactly the kind of thing to check yourself instead of assuming a vendor's build pipeline stays current. If you run QIDI Studio, nothing here demands you stop. Keep an eye on release notes for a bundled-dependency bump. And treat the app's home-screen content the way you would treat any other software that quietly reaches the internet by default.