QIDI Studio is the slicer for QiDi's printers — free, actively developed, and the software you'd actually run day to day. This isn't a slicing-quality review; it's the same "what is this thing doing on my network, and what's 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 on every launch, caught with a packet capture scoped precisely to its own process ID, and a scan of what's bundled inside the install that turned up a real, currently unpatched CVE.
ss -tnp's
process-owner field against the capture — connections are only attributed to QIDI Studio here because the
kernel itself 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 touching anything in the UI, its own process (not a browser tab, confirmed by PID) opens three outbound connections:
api.qidimaker.com (Cloudflare-fronted) — QIDI's own model-sharing/community
platform, QIDIMaker. Almost certainly populating whatever "community models" or "recommended" content
shows on the home screen.shops.myshopify.com.
Most likely a "shop"/promotional widget rather than anything printer-functional, though the exact content
wasn't inspected.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
doesn't currently resolve to anything — a dead or since-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's just default behavior the moment the app opens. None of it is unusual for a modern desktop app with a "home screen" showing marketplace/community content (Bambu Studio and Cura both do comparable things), and none of it looked like it was exfiltrating anything printer- or project-specific in this test — but "silently reaches three external hosts before you've configured anything" is worth knowing going in, especially on a network segment you'd otherwise assume is offline by design.
Extracting the AppImage and inspecting what it ships versus 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, which means those specific components stay current through normal OS updates rather than being frozen at whatever version QIDI built against. That's a genuinely good call.
What is bundled is its own copy of FFmpeg — libavcodec,
libavutil, libswresample, libswscale — almost certainly for the
timelapse/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 has since moved to 9.0 (released this month) with
security-maintained branches as recent as 8.1.2 and 7.1.5 — QIDI's bundled copy is roughly two years and
several major releases behind current.
To be precise about what this does and doesn't mean: this identifies a real vulnerability present in the exact bundled binary shipping inside the current QIDI Studio release, confirmed by extracting the version string directly rather than assuming from a release date. What it doesn't establish is whether QIDI Studio's own code path actually reaches the vulnerable AAC-encoder function during normal use (versus only ever using FFmpeg for decoding/playback) — that would need deeper reverse engineering of the app itself than a black-box scan can answer. Worth being clear-eyed about both halves: the vulnerable code is genuinely sitting in the install, and confirming real-world reachability is a separate, harder question.
For context, one older, previously-disclosed FFmpeg CVE (CVE-2024-7055, a PNM decoder heap overflow affecting versions up to 7.0.1) is already fixed in the bundled 7.0.2 — 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 — hostname, and an API key/access token
for its Moonraker API — to a plaintext JSON file under
~/.config/QIDIStudio/user/default/physical_printer/. That key grants full control of the
printer (upload, print, run macros) to anything that can read the file. This is extremely common for
desktop apps in this category — it's the same pattern OctoPrint/Klipper host tools generally use — but it
means the usual caveat applies: anything else running as your user account, or a backup that isn't handled
carefully, has access to that credential in the clear.
App logs are the opposite story — genuinely encrypted on disk (a real BEGIN_HEADER/JSON-metadata
encrypted log format, confirmed by inspection), which is a reasonable design choice for a desktop app that
might ship logs back for support purposes.
Separately from anything above, QIDI Studio has a well-defined segfault on Linux 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 disclosed-nowhere-but-not-hidden-either default telemetry/marketplace traffic that's standard for the category; the plaintext API key storage is standard for the category too. The one finding that actually matters is concrete and checkable by anyone: the bundled FFmpeg is real, it's about two years stale, and it carries a specific, critical, publicly-disclosed CVE that the currently-shipping release hasn't addressed. That's not catastrophic on its own — this app isn't processing untrusted video files from strangers — but it's exactly the kind of gap that's easy for a hardware company shipping desktop software as a secondary product to let slip, and exactly the kind of thing worth checking yourself rather than assuming a vendor's build pipeline stays current. If you're running QIDI Studio: nothing here demands you stop, but it's a reasonable prompt to keep an eye on release notes for a bundled-dependency bump, and to treat the app's home-screen content the same way you'd treat any other software that quietly reaches the internet by default.