OctoPrint's long road to 2.0.0 has one more stop. On 7 October 2026, maintainer Gina Häußge published the sixth release candidate, 2.0.0rc6, a build that is mostly about cleaning up regressions found during the release candidate phase. The most notable item on the list is a fix for a wrong check in local storage that, in the project's own words, "under very limited circumstances could lead to a limited path traversal vulnerability on the download API endpoint." The release also restores a function signature that third-party plugins depend on, and it arrives about five weeks after Häußge publicly urged plugin authors to finish migrating to the new major version.

The release was, by the maintainer's account, slightly delayed by "the first cold of the season." It is tagged as 2.0.0rc6 on GitHub, where the release page is dated the same day and marked as a pre-release.

The Path-Traversal Fix, in Context

Any phrase involving "path traversal" and a download endpoint deserves attention on software that sits on a home network with direct control over a heated, moving machine. But the wording here is carefully hedged, and it is worth reading closely. The issue, tracked as #5454, is flagged as a regression: something that worked correctly before and broke at some point along the way. The blog post describes it as a wrong check inside local storage, the component that manages files on the OctoPrint host, and limits both the conditions ("very limited circumstances") and the scope ("a limited path traversal") of what could go wrong.

The post does not describe an exploitation scenario, a severity score or any reports of the bug being abused, and FilamentFeed has no further detail beyond what the project published. It also does not say which versions carry the flaw, so readers should not assume that any particular install is or is not affected. The practical advice for anyone already running the release candidate channel is simple: update to rc6.

The changelog also thanks contributor @jacopotediosi for their pull requests. That name turns up elsewhere in the 2.0.0 story, as discussed below.

The Rest of the Changelog

Beyond the security-relevant fix, rc6 is a grab bag of correctness work, much of it around file metadata. Highlights from the release notes:

  • Gcode Viewer compatibility. The bundled Gcode Viewer plugin once again supports the old loadFile signature on its view model. Third-party plugins such as UICustomizer are cited as using that signature, so this is a direct fix for plugin breakage rather than a new feature.
  • NaN and Inf rejected in metadata. Saving file metadata now refuses NaN and Inf values (PR#5450), the kind of garbage that can quietly poison later calculations.
  • Metadata refresh on upload (#5466). Another regression: a cache was not being emptied correctly, so metadata did not refresh properly when a file was uploaded.
  • Sanitising broken metadata. Broken analysis, statistics and history metadata on files is now handled, with data sanitised where possible and completely invalid data removed, instead of the whole file being ignored in the file list.
  • PrintFailed payload race. A race condition caused the PrintFailed event to be sent with the wrong payload, which matters to anyone whose notification or automation plugins key off that event.
  • Progress for unset jobs. Progress reporting is now handled properly for the case where no job is set.
  • Python housekeeping. The deprecated inspect.getargspec has been replaced, a change backported from PR#5464.
  • Health Check thresholds. The Health Check plugin's storage thresholds are available again through the settings API.
  • Serial Connector. When the printer reports an unknown file as selected for printing, the Serial Connector now handles it gracefully. A wrong seek signature for streaming opened file handles was also fixed.
  • Docs. The FileDestinations.SDCARD notes in the migration guide have been corrected (PR#5449).

Taken together, the list reads like a project in the late, unglamorous phase of a major release: fewer new features, more edge cases, and a steady focus on not breaking the ecosystem that has grown up around the software.

Four Months of Release Candidates

That ecosystem is the real story of 2.0.0. On 1 September, with the release then on its fifth release candidate after four months in the RC phase, Häußge published an open letter to OctoPrint's plugin authors. Its message was blunt. Authors had been told back in April to go through the Migration Guide and check whether their plugin was affected. Tooling exists to help: the octoscanner tool provided by Jacopo Tediosi, made available around that time, can help identify issues, and several pull requests had been sent to the more popular plugins to help get them migrated.

The letter was not all stick. Häußge thanked the many authors who had responded, migrated their plugins and released new, compatible versions. But for the hold-outs, including those ignoring migration pull requests, the instruction was to take care of it now. Authors who no longer want to maintain a plugin were asked to give it up for adoption so a solution can be found for its users. And if the call keeps being ignored, the letter warned, "at some point we might have to force-adopt your plugin for the sake of OctoPrint's users, which we'd rather not."

Read against that backdrop, the Gcode Viewer change in rc6 is telling. Restoring an old signature so that plugins such as UICustomizer keep working is the core team absorbing some compatibility cost itself, even as it asks plugin authors to do their part.

What It Means for Makers

If you run a stable OctoPrint install, nothing changes today. The release candidates are opt-in, delivered through a separate "Release Candidates" release channel, and the project is explicit about the risk: do not install an RC if you expect a fully stable version. Severe bugs may occur, and they can be bad enough to make a manual downgrade to an earlier version necessary, possibly from the command line, which is not the kind of thing anyone wants to discover halfway through a long print.

If you are already on the 2.0.0 RC channel, rc6 is a straightforward update. The local storage fix alone is reason enough, and the metadata and PrintFailed fixes address the kinds of quiet errors that can mislead monitoring and automation setups.

If you depend on particular plugins, this is the time to check their status. The open letter makes clear that unmigrated plugins may be put up for adoption or even force-adopted, so some may change hands. Makers who rely on a plugin that has gone quiet can help by flagging it to its author, or by watching for an adoption notice.

And if you write plugins, the message from the maintainer could hardly be clearer. The Migration Guide has been available since April, octoscanner exists to find the problems, and the release candidate count is now at six. A final release has not been dated in the sources FilamentFeed reviewed, but the letter's tone suggests the window for a comfortable migration is closing.

Sources