CVE-2025-48879: OctoPrint DOS Vulnerability

CVE-2025-48879 Overview

CVE-2025-48879 is a denial-of-service vulnerability in OctoPrint, a widely deployed web interface for 3D printers. Versions up to and including 1.11.1 are affected. An unauthenticated attacker on an adjacent network can send a malformed multipart/form-data request that lacks a final boundary. The request handler enters an endless busy loop waiting for data that never arrives. Because Tornado is single-threaded, the entire web server becomes unresponsive. The flaw is categorized under [CWE-140: Improper Neutralization of Delimiters]. OctoPrint version 1.11.2 contains the fix.

Critical Impact
A single crafted request can freeze the OctoPrint web server, blocking legitimate users from monitoring or controlling attached 3D printers.

Affected Products

OctoPrint 1.11.1 and all prior versions
Any endpoint served by the octoprint.server.util.tornado.UploadStorageFallbackHandler request handler
Deployments exposing OctoPrint on local or adjacent networks

Discovery Timeline

2025-06-10 - CVE-2025-48879 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-48879

Vulnerability Analysis

OctoPrint uses the Tornado asynchronous web framework to serve its HTTP API. The UploadStorageFallbackHandler class processes multipart/form-data uploads by iteratively draining its internal buffer as new bytes arrive. The parser expects a terminating boundary marker to signal the end of the multipart body.

When a client submits a multipart request that omits the final boundary, the handler continues polling its buffer for more data. The loop never advances and never exits. Tornado's single-threaded event loop is monopolized by this stalled coroutine, preventing all other requests from being processed. Any unauthenticated adjacent-network attacker can trigger the condition against a public upload endpoint.

Root Cause

The root cause is missing termination logic in the multipart buffer processing loop inside src/octoprint/server/util/tornado.py. The pre-patch code executed while len(self._buffer): without checking whether progress was being made between iterations. A malformed request that produces no parseable part leaves the buffer length unchanged forever.

Attack Vector

An attacker with network reachability to the OctoPrint interface issues an HTTP request to any endpoint backed by UploadStorageFallbackHandler. The request declares a multipart/form-data content type with a boundary parameter but sends body bytes that never include the closing --boundary-- marker. The server accepts the payload and the request handler enters the infinite loop. Authentication is not required.

python

         body = b""
         if self.is_multipart():
             # make sure we really processed all data in the buffer
-            while len(self._buffer):
+            buffer_len = len(self._buffer)
+            while buffer_len:
+                self._logger.debug("waiting for buffer to empty...")
                 self._process_multipart_data(self._buffer)
 
+                if len(self._buffer) == buffer_len:
+                    # no change between iterations, something fishy is going on, abort, abort!
+                    raise tornado.web.HTTPError(
+                        400,
+                        log_message="Invalid multipart/form-data: no final boundary found",
+                    )
+                buffer_len = len(self._buffer)
+
             # use rewritten body
             body = self._new_body

Source: OctoPrint patch commit c9c35c1. The fix records the buffer length before each iteration and raises HTTP 400 when a full pass produces no progress.

Detection Methods for CVE-2025-48879

Indicators of Compromise

OctoPrint web interface becomes unresponsive to all HTTP requests while the process remains running
Elevated single-core CPU usage attributed to the OctoPrint Python process without corresponding print activity
Access logs showing multipart/form-data POST requests immediately preceding service unavailability

Detection Strategies

Inspect HTTP request logs for multipart/form-data uploads with abnormally small or truncated bodies relative to the declared Content-Length
Alert on OctoPrint process CPU utilization sustained above baseline without matching print job activity
Monitor for repeated client connections to upload endpoints followed by request timeouts

Monitoring Recommendations

Enable reverse proxy access logging in front of OctoPrint to capture request headers and byte counts
Track availability of the OctoPrint HTTP endpoint with an external health check that alerts on hang conditions
Correlate network telemetry against the OctoPrint version banner to identify unpatched instances

How to Mitigate CVE-2025-48879

Immediate Actions Required

Upgrade OctoPrint to version 1.11.2 or later on every host
Restrict network access to the OctoPrint web interface to trusted management networks and VPN clients
Place OctoPrint behind a reverse proxy that enforces request size limits and body read timeouts

Patch Information

The vulnerability is remediated in OctoPrint 1.11.2. The fix is published in the GitHub Security Advisory GHSA-9wj4-8h85-pgrw and applied in commit c9c35c1. The patch aborts multipart processing with an HTTP 400 response when no progress is made between buffer iterations.

Workarounds

Terminate multipart/form-data uploads at an upstream proxy such as nginx or HAProxy with strict client_body_timeout and client_max_body_size values
Isolate OctoPrint on a dedicated VLAN and require authenticated VPN access before any HTTP request can reach the service
Configure network access control lists to allow only known workstation IP addresses to reach the OctoPrint port

bash

# nginx reverse proxy example enforcing upload timeouts
server {
    listen 443 ssl;
    server_name octoprint.internal;

    client_body_timeout 10s;
    client_header_timeout 10s;
    client_max_body_size 200m;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_read_timeout 30s;
        proxy_request_buffering on;
    }
}