Prusa's newest firmware has a short section that matters more than any of the new features. The Buddy firmware v7.0.0 release notes, published on November 3, include a block titled "Security and robustness fixes (PSA-2026-002)". It credits independent researcher Yannick Dixken, who reported a set of issues in August 2026. Dixken's own write-up, "Never Gonna Print You Up", came out alongside Prusa's advisories. It lists 14 findings covering about 23 separate defects. The chain ends in code execution on the printer's main controller, reachable over the network.
The fixes cover 15 printer models: the CORE One L+, CORE One L, CORE One+ (Gen 2) INDX, CORE One INDX, CORE One+ (Gen 2), CORE One, XL+, XL, MK4S, MK4, MK3.9S, MK3.9, MK3.5S, MK3.5, and the MINI. If your Prusa runs Buddy firmware, this release applies to you.
How Did One Researcher Find So Much in a Week?
Dixken started with his own MK4S running firmware 6.5.7 and spent about a week attacking it. He worked with an AI model, Opus 4.8, and a fuzzer. The work had two main parts. First, he compiled the firmware's own parser code to run on an ordinary computer under AddressSanitizer, so that any crash sat in Prusa's shipped code. Second, he stood up a small Cortex-M emulator that executes the real, signed firmware image. He then ran millions of mutated iterations against the G-code path and millions of mutated HTTP requests against PrusaLink and Prusa Connect.
That combination is what makes the work notable. Fuzzing parsers on a desktop machine is fast but only tests pieces of the code. Emulating the shipped binary tests the firmware owners actually run. He confirmed his worst finding on a physical MK4S rather than stopping at an emulator crash.
What Was the Worst Bug?
The most serious flaw (PFB-008, which Dixken scores a preliminary CVSS 8.1 High) is in how the printer handles a SEND_FILE_INFO command from Prusa Connect. The firmware expects the file path in that message to be no longer than 104 bytes. That limit is enforced only by an assert(), a check that release builds compile out. Hackaday's This Week in Security column explained the same point. With the assert gone, nothing stops a long path. Dixken found that a 463-byte path overflows a shared 512-byte buffer and overwrites the planner's printer pointer. That gave him control of the main controller.
A debug-only check became the only safeguard, and it disappears from production builds. Dixken also notes the firmware carries no stack canary, which is what turned this bounds slip into real control of the program counter instead of a simple crash.
The attack has a real limit. To deliver the oversized message, an attacker has to control or intercept the Connect endpoint the printer talks to. Dixken ran his tests with TLS turned off in the printer's local configuration, so against the official cloud-based Prusa Connect a real attack would first need to defeat or downgrade TLS. Prusa's release notes are more emphatic: the most serious finding needs a printer pointed at the attacker's own Connect server, or at one without TLS, and intercepting traffic to the official Prusa Connect was not enough because the encrypted connection held. Prusa also says none of the issues can be used to attack a printer directly from the internet.
What Else Turned Up?
The other findings span much of the firmware. Dixken reports bugs in the USB and FAT file system code, in transfer recovery, in MMU handling, and in EEPROM handling. A crafted USB file name overflowed a path buffer and let him take control of the program counter (PFB-007, CVSS 6.4 Medium), although he notes it did not give him code execution of his own and needs physical USB access with the stick present at power-on. Prusa's notes also list a flaw (PFB-012) where a host on the network could hold all receive buffers and stall PrusaLink, Connect and mDNS. Encrypted downloads from Connect had no integrity check on print files; Prusa says that old download path was unused since Connect switched to websockets, and 7.0.0 no longer includes it.
Dixken is clear about how strong each finding is. His first disclosure package had four findings, and he confirmed three of them on the physical printer. His second package had ten findings, confirmed under AddressSanitizer or by source review rather than exploits on real hardware. The MMU off-by-one in the first package was verified from source only. Not all 23 defects are proven exploits, but enough were confirmed on a real printer to take the set seriously. Prusa's own assessment is that for most printers the practical risk was low.
How Did Prusa Handle It?
By Dixken's account, Prusa replied exactly 24 hours after his first message, and Hackaday reports that Prusa reproduced the bugs and coordinated the disclosure. Dixken published at the same time as Prusa's advisories. According to the release notes, the researcher has requested CVE identifiers, and they will be added to the PSA-2026-002 bulletin once assigned.
One part of the response has caused controversy. Prusa held back the 7.0.0 source code until the disclosure date, to give owners time to update. Hackaday reports that this started a heated GitHub discussion (issue 5525) about the GPL obligations of firmware derived from Marlin, and Dixken himself points to that discussion. Security embargoes protect users while patches spread, while the GPL exists so that anyone who receives the binary can also get the source. The two goals pull against each other here.
What Else Is in 7.0.0?
The release also adds features. It supports the new HT hotend with automatic detection on the CORE One and CORE One L, and with it installed the nozzle can reach 400 °C for materials such as PPS or PPA. It adds PVA and BVOH filament presets, tool mapping presets, and automatic Z-axis alignment on an uneven bed for the CORE One, CORE One L and INDX machines. There is a new Runout Reaction setting that controls how quickly the printer reacts to a filament runout, and Prusa has introduced a new versioning policy, which is why the number jumps to 7.
Bottom Line for Makers
Update to Buddy 7.0.0 or later. Prusa says all findings are fixed in 7.0.0 and later, with one caveat: a low-severity EEPROM defect that needs physical access is only partly fixed and is still under review. If you have a farm of mixed machines, check each one: all 15 supported models are in scope.
Treat connected printers as network devices. A printer running PrusaLink or Prusa Connect is a computer on your network that parses untrusted input. Put it on a separate network segment if you can, and don't expose it directly to the internet.
Be careful with USB sticks. Several of the findings involve crafted files or file names on USB media, so printers that never touch a network are not out of scope. Until you have updated, don't plug in media you didn't prepare yourself.
There is also a broader lesson. One researcher, working with an AI model and a fuzzer, found about two dozen defects in widely used printer firmware in a week, and he credits the tools with making that kind of thoroughness cheap. Prusa now has a public patch.
