Jan 27, 2026·5 min read·37 visits
OctoPrint versions up to 1.11.5 used standard string comparison for API keys. This optimization leaks information about how much of the key is correct based on response time. An attacker on the LAN can exploit this to brute-force the API key and take full control of the printer.
A classic timing side-channel vulnerability in OctoPrint allows attackers on the local network to guess API keys character-by-character by measuring how long the server takes to say 'no'.
In the world of physical security, the quintessential image of a safecracker is a shadowy figure pressing a stethoscope against a cold steel door, listening for the faint click of a tumbler falling into place. In the digital world, we don't listen for clicks; we watch the clock.
OctoPrint, the beloved brain behind thousands of consumer 3D printers, recently found itself playing the role of that safe. CVE-2026-23892 isn't a buffer overflow or a SQL injection. It's a timing side-channel—a vulnerability that exists not because the logic is wrong, but because the code is too efficient for its own good.
By measuring the infinitesimal delay between sending a request and receiving a 403 Forbidden response, an attacker can reconstruct a valid API key one byte at a time. It’s the digital equivalent of guessing a password and having the guard hesitate slightly longer when you get the first letter right.
The root cause here is a fundamental concept in computer science: optimization. When you compare two strings in most high-level languages (like Python), the runtime wants to give you an answer as fast as possible. This is called fail-fast or short-circuit logic.
Here is how a standard string comparison (==) works under the hood:
False immediately.False immediately.False immediately.Do you see the problem? If the correct API key is SECRET, and I guess AAAAAA, the system checks S vs A, sees a mismatch, and rejects me instantly.
But if I guess SAAAAA, the system checks S vs S (match), moves to the next character, checks E vs A (mismatch), and then rejects me. That second check takes a few nanoseconds longer. In the vulnerable OctoPrint versions, this tiny discrepancy was measurable over a low-latency network (LAN).
The vulnerability lived in src/octoprint/access/users.py. The developers were using Python's standard equality operator to validate sensitive credentials. It looked something like this:
# The Vulnerable Logic
if apikey == user._apikey:
return userIt looks innocent, right? That's why these bugs are insidious. To fix it, you have to stop thinking like a developer optimizing for speed and start thinking like a cryptographer optimizing for constant time.
In patch 249fd80ab01bc4b7dabedff768230a0fb5d01a8c, the OctoPrint team switched to hmac.compare_digest. This function is designed to take the exact same amount of time to return False, regardless of whether the mismatch happens at the first character or the last.
# The Fix
import hmac
# ... inside the validation loop
if hmac.compare_digest(apikey, user._apikey):
return user> [!NOTE]
> Comedy of Errors: The initial fix actually introduced a regression. hmac.compare_digest throws a fit if you feed it None. Since some users might not have generated an API key yet (user._apikey is None), the server started crashing. They had to push a follow-up commit (0bd35ddcf316668f9ba5335afbb4c07b4b2ad408) to handle null checks explicitly before the timing-safe comparison.
Exploiting this isn't as simple as firing up a script and waiting 5 seconds. We are dealing with nanoseconds here. Network jitter, OS context switching, and background noise on the Raspberry Pi running OctoPrint will all drown out the signal.
To exploit this, we need statistics.
A..., 1,000 with B..., and so on.O... has a statistically significant higher average response time than the rest, we know O is the first character.OA..., OB..., OC....This is why the CVSS complexity is High (AC:H). You can't do this easily over the public internet (WAN) because the variance in internet routing latency is massive compared to the tiny CPU difference we are trying to measure. But on a quiet home network? It's open season.
So you spent hours brute-forcing an API key. What do you get?
Total Administrative Control.
With a valid API key, you bypass the login screen entirely. You can:
It transforms a helpful IoT device into a spy cam and a potential arsonist.
If you are running OctoPrint, update to 1.11.6 immediately. This version implements hmac.compare_digest() across the board for API key validation.
For Developers: Take note. Never use == for secrets, tokens, or hashes. If the value is sensitive, use a constant-time comparison function. In Python, that's hmac.compare_digest(). In PHP, it's hash_equals(). In Go, subtle.ConstantTimeCompare().
For Users: Treat your 3D printer like a server. Don't expose it to the internet without a VPN or a reverse proxy like Authelia. Even if the code is perfect, you don't want the entire internet knocking on your printer's front door.
CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N| Product | Affected Versions | Fixed Version |
|---|---|---|
OctoPrint OctoPrint | <= 1.11.5 | 1.11.6 |
| Attribute | Detail |
|---|---|
| CWE | CWE-208 (Observable Timing Discrepancy) |
| CVSS v4.0 | 6.0 (Medium) |
| Attack Vector | Adjacent (LAN) |
| Attack Complexity | High (Requires statistical analysis) |
| Impact | High (API Key Extraction) |
| Exploit Status | Theoretical / PoC Feasible |
The product performs a comparison that takes a variable amount of time depending on how many characters match, allowing an attacker to guess the value via timing discrepancies.
A path traversal vulnerability (CWE-22) in Contao CMS allows unauthenticated remote attackers to bypass directory boundary restrictions in ImagesController and access files within the project directory.
Contao Open Source CMS versions 4.0.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 contain a Cross-Site Request Forgery (CSRF) vulnerability in backend parameter handling. The `RequestTokenListener` component validates anti-CSRF tokens solely for HTTP POST requests, while GET-based declarative guards run only when an `act` parameter is present in the query string. Consequently, custom backend actions dispatched via alternative parameters such as `key=` can execute without CSRF token verification when triggered by an authenticated user.
Contao CMS versions 4.1.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 fail to validate form submission tokens and enforce rate limiting when processing activation email resend requests via HTTP POST, enabling resource exhaustion and account state enumeration.
An information disclosure vulnerability in Contao CMS allows unauthenticated site visitors to view protected page titles, URLs, and text excerpts through search queries when protected page indexing is disabled after previously being enabled.
In Vikunja prior to version 2.6.0, relation creation via the CalDAV endpoint fails to invoke the TaskRelation.CanCreate authorization check. This missing access control allows an authenticated user to establish unauthorized relationships and perform write operations against any task, provided its unique identifier (UID) is known.
A cross-project information disclosure vulnerability in Vikunja allows authenticated users with read access to one project to view private task details from unauthorized projects via subtask expansion parameters.