CVE-2026-25505
Hardcoded JWT Key and Auth Bypass in Bambuddy Before
Publication date: 2026-02-04
Last updated on: 2026-02-27
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bambuddy | bambuddy | to 0.1.7 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-306 | The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. |
| CWE-321 | The product uses a hard-coded, unchangeable cryptographic key. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability can have severe impacts including unauthorized access to sensitive system, user, printer, archive, and configuration data. Attackers can bypass authentication entirely by forging JWT tokens using the hardcoded secret key.
With this access, attackers can impersonate any user, including administrators, potentially gaining full control over the Bambuddy instance. This can lead to data breaches, unauthorized modifications, and disruption of printing and archival services.
Can you explain this vulnerability to me?
CVE-2026-25505 is a critical security vulnerability in Bambuddy, a self-hosted print archive and management system for Bambu Lab 3D printers. Prior to version 0.1.7, the application used a hardcoded secret key to sign JSON Web Tokens (JWTs), which was publicly accessible in the source code. This allowed attackers to forge JWT tokens and impersonate any user, including administrators.
Additionally, many API endpoints in Bambuddy did not enforce authentication, allowing unauthorized users to access sensitive data and functionality without any credentials. Over 200 API endpoints were affected, with 77 accessible without authentication and others accessible with forged tokens.
The vulnerability was patched in version 0.1.7 by removing the hardcoded secret key and enforcing permission checks on all protected API routes, ensuring that users must have appropriate permissions to access or modify resources.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing the accessibility of Bambuddy API endpoints without authentication and by attempting to forge JWT tokens using the known hardcoded secret key.'}, {'type': 'paragraph', 'content': 'A practical approach involves running a script that sends GET requests to various API endpoints both with and without an Authorization header containing a forged JWT token signed with the hardcoded secret key "bambuddy-secret-key-change-in-production".'}, {'type': 'paragraph', 'content': 'For example, you can forge a JWT token with payload {"sub": "admin"} and a far future expiration date using the hardcoded secret, then use curl or similar tools to test endpoints:'}, {'type': 'list_item', 'content': 'Forge JWT token using the hardcoded secret key.'}, {'type': 'list_item', 'content': 'Use curl to access an API endpoint without authentication: curl -X GET http://<bambuddy-host>/api/<endpoint>'}, {'type': 'list_item', 'content': 'Use curl to access the same endpoint with the forged JWT token: curl -H "Authorization: Bearer <forged_jwt_token>" -X GET http://<bambuddy-host>/api/<endpoint>'}, {'type': 'paragraph', 'content': 'Endpoints that return sensitive data without authentication or accept forged tokens indicate the presence of the vulnerability.'}] [3]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade Bambuddy to version 0.1.7 or later, where the vulnerability has been patched.
This patch removes the hardcoded JWT secret key and enforces authentication and permission checks on over 200 previously unprotected API endpoints.
If upgrading immediately is not possible, consider restricting network access to the Bambuddy instance to trusted users only, and monitor API usage closely for unauthorized access attempts.
Additionally, review and rotate any JWT secrets used in your environment to ensure no tokens signed with the hardcoded key remain valid.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know