9.8

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-25505

CVE-2026-25505: Bambuddy Uses Hardcoded Secret Key + Many API Endpoints do not Require Authentication

Bambuddy is a self-hosted print archive and management system for Bambu Lab 3D printers. Prior to version 0.1.7, a hardcoded secret key used for signing JWTs is checked into source code and ManyAPI routes do not check authentication. This issue has been patched in version 0.1.7.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-25505

CVE-2026-25505:

9.8

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
bambuddy	pip	< 0.1.7	0.1.7

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability consists of two main issues: a hardcoded JWT secret key and a widespread lack of authentication on API endpoints. The provided patch, commit a82f9278d2d587b7042a0858aab79fd8b6e3add9, addresses the second issue by adding authentication and permission checks to over 200 API endpoints.

The root cause of the missing authentication vulnerability was that numerous FastAPI route handlers were defined without any dependency to enforce authentication. For example, the create_api_key function in backend/app/api/routes/api_keys.py allowed unauthenticated users to create new API keys. An attacker could exploit this by sending a simple POST request to the /api/v1/api-keys/ endpoint, as demonstrated in the vulnerability report.

The fix involves adding a new dependency, RequirePermissionIfAuthEnabled, to each vulnerable endpoint. This function, when used as a FastAPI dependency, ensures that if authentication is enabled in the application's configuration, the request must have a valid JWT, and the user associated with the token must have the required permissions to access the endpoint.

The functions listed as vulnerable are representative examples of the many endpoints that were missing this check. During exploitation, these are the function names that would appear in a runtime profile or stack trace when an unauthenticated request is made to the corresponding API endpoint.

It is important to note that the provided patch does not address the hardcoded JWT secret key issue. This would need to be fixed separately by removing the hardcoded key and loading it from a secure configuration source.

Vulnerable functions

create_api_key

backend/app/api/routes/api_keys.py

This function was vulnerable because it lacked any authentication or authorization checks, allowing an unauthenticated attacker to create a new API key with arbitrary permissions by sending a POST request to the `/api/v1/api-keys/` endpoint.

get_system_info

backend/app/api/routes/system.py

This function was vulnerable as it did not require authentication, exposing sensitive system information, including application and database statistics, to any unauthenticated user making a GET request to the `/api/v1/system/info` endpoint.

list_filaments

backend/app/api/routes/filaments.py

This function was vulnerable due to a lack of authentication, allowing an unauthenticated attacker to retrieve a list of all configured filaments via a GET request to the `/api/v1/filaments/` endpoint.

get_settings

backend/app/api/routes/settings.py

This function was vulnerable because it did not enforce authentication, permitting an unauthenticated attacker to fetch all application settings by making a GET request to the `/api/v1/settings` endpoint.

list_projects

backend/app/api/routes/projects.py

This function was vulnerable as it lacked authentication checks, enabling an unauthenticated attacker to list all projects and their statistics by sending a GET request to the `/api/v1/projects` endpoint.

create_access_token

backend/app/core/auth.py

The vulnerability report indicates a hardcoded secret key is used for signing JWTs. While the provided patch does not modify this, the function `create_access_token` and any function that verifies the token would be using this hardcoded key, allowing an attacker to forge valid JWT tokens for any user. The provided patch does not fix this specific issue.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.