Prusa patches 14 Buddy firmware flaws after researcher chains Connect bug into RCE

A security researcher has disclosed 14 vulnerabilities in Prusa's 3D printer firmware, including a flaw in the Prusa Connect integration that permits remote code execution on the printer's main controller. The release was coordinated with Prusa, which published its own security advisories at the same time as the researcher's write-up and, according to that write-up on the blog dixken.de (which surfaced on the Hacker News front page), has fixed every reported finding in Buddy firmware above version 7.0.0.

One week of testing, 14 findings

The author, a freelancer in platform engineering and SRE who describes security research as a side pursuit, spent a week in August attacking a personally owned MK4S running the then-current firmware 6.5.7 (build 6.5.7+12836). The effort yielded 14 findings covering roughly 23 individual defects, spread across G-code parsing, Prusa Connect, the USB and FAT storage paths, transfer-recovery code, the MMU and EEPROM handling. The most serious result was a chain that ended with the controller executing code delivered over the network. CVE identifiers have been requested for all findings but were not yet assigned when the post was published.

The headline bug: PFB-008

The centerpiece, tracked as PFB-008 with a preliminary CVSS score of 8.1 (High) and reproduced on physical hardware, sits in the handling of Prusa Connect, the cloud or self-hosted service used to manage printers and dispatch print jobs. When Connect issues a SEND_FILE_INFO command, the firmware copies the command's path into a shared 512-byte buffer, then writes the filename into that same buffer, locating it by scanning past the end of the path string. That layout is only safe while paths stay under 104 bytes, and the sole enforcement is an assert() that release builds compile away.

According to the write-up, a 463-byte path pushes the filename write past the end of the buffer and onto an adjacent pointer that the Connect command planner uses to dispatch calls to the printer, so the next virtual call jumps through an attacker-controlled pointer. The referenced file does not even need to exist, because the bytes are copied before anything is opened. The payload is self-contained: the path itself carries a fake object, a dispatch table and the code, without heap spraying or a second delivery stage. The firmware also ships with no stack canary and no _FORTIFY_SOURCE, which the author says is what converted a bounds-check slip into control of the program counter rather than a simple crash.

The precondition is that the attacker must control or intercept the Connect endpoint the printer communicates with — a category that includes a compromised Connect backend or anyone positioned in the path of that traffic.

Method: a fuzzer, an emulator and an AI model

The researcher started where user-supplied input enters the system — G-code parsing and Prusa Connect — working with the Opus 4.8 AI model and a fuzzer. The method combined compiling the firmware's own parser code under AddressSanitizer, building a small Cortex-M emulator to run the genuine signed image with a matching memory map, throwing millions of mutated G-code inputs and HTTP requests at PrusaLink and Connect, and extensive reverse engineering plus parallel source audits. The hardest step, the author notes, was finding a usable control-flow primitive: of a pile of candidate dispatch sites, exactly one worked for the exploit. Notably, the researcher had never written Cortex-M assembly before this project.

Split disclosure, fixes already shipping

Findings went to Prusa in two packages, deliberately separated by confidence level so the vendor would neither over-trust the weaker reports nor under-trust the stronger ones. The first package held four findings, three of them confirmed on the actual printer through its own crash dumps and a complete takeover of the controller, plus one MMU off-by-one verified only in source. The second held ten findings confirmed under AddressSanitizer or by source review alone. Every report included a full write-up and proof-of-concept code where applicable, and the author handed over the entire research worktree — scripts and methods included — so Prusa's developers could repeat the process. With the advisories now public, the researcher is releasing all of the write-ups and urges owners of the printers listed in the post to update immediately.

Why it matters

This is a concrete security event that printer owners must act on: details and proof-of-concept code are now public, so anyone running an affected Prusa model on older firmware should move to Buddy firmware above 7.0.0. It also illustrates how common embedded-firmware practices — an assert() as the only bounds check, no stack canaries, no compiler hardening — can turn a small validation error into full device takeover. And it underlines that a cloud-connected printer inherits the security of its control endpoint: trust in the Connect service becomes trust in the firmware itself. On the positive side, the episode is a clean example of coordinated disclosure, with vendor fixes, official advisories and an independent, reproducible write-up landing together.